The "business" (as opposed to a department or line of business) can be difficult to conceptualize. This is only complicated by tendency for many developers to see these vague nonfunctional requirements often critical to successful SOA as fluff.
Many developers are used to being so close to the problem (and to the solution) that they think about it in the context of code. When faced with an immediate requirement, like "Read in and import this file," many developers and project managers don't appreciate the larger issue. What is happening here is the crossing of an intersystem boundary. This is even more pronounced when the source of said file is an external B2B party. Ultimately, this falls under the issue of SOA governance, but that's an article for another day.
Sadly, many enterprises today find themselves playing catch-up in both areas of architecture, and they don't manage the necessary balance and tradeoffs particularly well. Here are some simple strategies for overcoming these challenges:
- Respect System Boundaries. Really. Even if the other system is an internal application or if it's developed by the same group of developers. The rate of change may be different between any two systems. You are crossing a system boundary if your application is written against a schema from this external source (even flat files have schemas); you have injected a dependency into your application from this external source. System boundaries are pretty serious, and good governance helps ensure they are respected.
- Establish a common vision. Architectural representatives from both sides (SOA and Application) should meet regularly. These meetings should cover upcoming functionality on each side. Neither should get too far ahead in developing short-term solutions for immediate needs. Frequent communication should also reduce the amount of duplication, as each team can coordinate its development efforts. The meetings should be between technical leads, ideally architects and business analysts from each team. An enterprise-wide road map can be helpful, but don't get too carried away.
- Reuse principles from each discipline. They really are complementary. Leverage design patterns at both the application and SOA level. These are the common language of each discipline and represent shorthand for concepts that make communication far easier among software professionals. Many SOA patterns are built on top of traditional architectural patterns; communication at this level can help both sides to understand the goals and expertise on each side of the fence.
To return to the Chicago analogy, this is like applying the same guidelines for planning water systems both within and between city buildings. Although they are quite different in specific implementation, they share a lot of commonality.
With a little guidance and communication, every enterprise can—and needs to—find its appropriate balance between architecture on the SOA and application levels. Only once this balance is struck can real success be achieved in an SOA. This is the inverse side of the company I highlighted earlier in which the best planning of the business needs, data flows and service requirements can be completely undermined by poor architecture of the SOA implementation themselves. Perhaps some of the confusion of SOA is that it is really a dual layered entity: the abstract business level architecture and the concrete service level architecture.
Dan Rosanova is principal consultant at Nova Enterprise Systems, a consultancy that specializes in enterprise applications and Microsoft BizTalk Server solutions. He has ten years experience delivering enterprise solutions in financial, insurance, telecommunications, and medical industries on Windows, Solaris and Linux platforms.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.