Section 6.1. The Architectural Roadmap

6.1. The Architectural Roadmap

For the architectural roadmap, we have identified three expansion stages that signify different levels of maturity of an SOA. The expansion stages indicate the allocation of responsibility between the application frontends and the services (see Figure 6-1). The first stage is called fundamental SOA. In this expansion stage, much of the complexity and responsibility is still allocated at the application frontend. Although a fundamental SOA does not provide all features of a fully leveraged SOA, it is already a useful platform for an enterprise application landscape. The next expansion stage is called networked SOA. At this stage, intermediary services aggregate low-level basic services to more sophisticated services. Finally, we have process-enabled SOAs. At this stage, the application frontends delegate process control to the SOA.

Figure 6-1. The expansion stages fundamental SOA, networked SOA, and process-enabled SOA are milestones of the architectural roadmap to the service-enabled enterprise.

In Figure 6-2, we depict the typical development of an application. It shows how permanent change requests and a lack of continuously applied architectural concept diminish maintainability and how an SOA-driven refactoring can reestablish agility. In Part III of this book, we present several case studies that show how different enterprises experienced difficulties when extending their historically grown application landscapes and how a transition to a Service-Oriented Architecture helped to incrementally overcome their difficulties.

Figure 6-2. Agony versus agility.

It should be noted that the concept of expansion stages cannot be applied in a black-and-white fashion. As soon as the SOA is established, you will probably find areas of differing maturity that are at a different expansion stage within itfortunately, without any undesired impact on the SOA itself. This reveals a major benefit of Service-Oriented Architecturesthey enable enterprises to start small and evolve in small steps as required in future projects. Actually, the SOA enables both evolutionary development of technology and functionality. Furthermore, the SOA supports different developments that run in parallel or in sequence. The SOA brings all these developments together in a smooth fashion, without harming a single project or the overall SOA endeavor. However, the expansion stages differ in regard of the distribution of responsibilities between application frontends and services. With an increasing maturation of the SOA, the services gain more and more responsibilities.

Allow Different Expansion Stages

Typically, different expansion stages coexist in the same SOA. Do not fight this heterogeneity! Develop different areas of the SOA in parallel to the requirements of business-driven projects.

The definition of your SOA strategy and the required level of maturity strongly depend on the scope of the business integration you are planning to reach. Obviously, implementing an SOA strategy is always a question of budget, and the further you are planning to advance your SOA, the longer you will have to invest (see also Chapter 12, "The Organizational SOA Roadmap," for a discussion on the budget requirements of an SOA).

Identifying the required scope of the business integration is usually a good first step on the way toward the definition of the overall SOA strategy because there is a strong correlation between the integration level one is aiming for on the one hand and the required maturity level of the SOA on the other. Figure 6-3 depicts this dependency.

Figure 6-3. The maturation of the SOA with respect to the expansion stages often correlates to an enlargement of the scope of business integration.

For example, if the required scope of business integration is only the intra-departmental level, a fundamental SOA will already help achieving good levels of maintainability of the system at hand. Obviously, the limited integration scope effectively limits the amount of flexibility or agility that can be achieved because only a limited view to the overall business processes is studied. In addition, investing in a very advanced SOA (such as a process-enabled SOA) is likely to be costly because the required IT investments would not be justified by the resulting business benefits.

On the contrary, in a scenario where the scope of business integration to be achieved is broadly defined, an approach based on a networked or process-enabled SOA is much more efficient. However, an extremely complex scenario, including cross-enterprise-integration and complex processes, might not even be feasible on the basis of a fundamental SOA.

When deciding on your SOA strategy, you should always ask yourself how much agility do you really need? Also consider the learning curve in your organization. Are you fit for process-enabled services? Choose an SOA strategy that best matches your agility requirements, your integration scenario, your architectural and development skills, and (obviously) your budget constraints. Your SOA strategy should be based on an evolutionary approach, subsequently developing your SOA expansion stages, taking all of the above mentioned factors into consideration. This approach also allows you to gradually broaden your integration horizon, moving from intradepartmental integration toward cross-departmental or even cross-enterprise integration.