If you compare the technical perspective of a service-oriented architecture (SOA) and the business perspective, as discussed in Chapters 2 and 3, or technical and nontechnical views of a business process, as discussed in Chapter 5, you might come to the conclusion that these two worlds—even though sophisticated process and workflow technology exists—are hard to integrate. Indeed this is the case. In fact, this whole book is an attempt to bridge the gap between the business and technology views in SOAs.

The business is mainly driven by (often very high-level) business goals. One main task of the SOA is hence that the business goals are properly mapped to services (or processes as a special kind of services that orchestrate other services). This is difficult because, on the one hand, business goals must be broken down into requirements for services. On the other hand, we must also consider existing applications, technical resources, and off-the-shelf vendor products when designing the services. We need a clear decision on which services must be designed and implemented considering the constant evolution of services.

In the SOA context, it is rather difficult to decide which services are actually required to satisfy the business goals. Actually, it is even worse as the problem starts with the prior step: It is necessary to break down high-level strategic business goals into more fine-grained goals that must then be transformed into requirements for the services. For this reason, the problem, on one hand, is to decide on a decomposition of business goals and provide a rationale for this structure.

On the other hand, we are usually dealing with an existing IT infrastructure, and it is necessary to offer available application functionality as services. These applications imply limitations on the functionality as an application will deliver only a certain set of functions that can be offered as services. The existing functionality must also be related to the strategic business goals to have a basis for the decision on which existing functionality is ready to use. That means a priori it is not obvious whether this existing functionality is sufficient to support the business goals or whether additional functionality must be developed within single applications. It must be decided which functionality of which application must be extended and whether this is possible at all with an acceptable effort.

Please note that similar situations arise for the data of existing applications (see also the discussion in Chapter 8). The existing data might also be different from the data expected by some business goals, and often it is hard to reengineer existing applications to offer exactly the data needed to realize a new business goal.

As far as off-the-shelf vendor products are concerned, these issues consequently influence evaluation of vendor products and the decision regarding which product best suits the requirements (i.e., the selection of right products within the information technology [IT] strategy context). The best strategic decision might be to replace some of the existing applications, migrate to new versions, or leave some of the existing systems in their current state of functionality.

This major problem of aligning the business goals and service design, addressed in one way or the other by many of the patterns presented in this book, is illustrated in Figure 7.1.

The decision process to decide on the requirements of services that need to be defined is a nontrivial process that has to consider evolutionary aspects of the business. An engineering approach is required to define and break down business goals and map them to requirements of services. The approach should further allow for planning the definition and design of these services. It should also consider the evolution of the business as the business goals might change over time.

Even though we have not yet discussed our patterns in terms of an engineering process, we have already hinted at this process in the narrative sections and case studies of Chapters 5 and 6. Actually, these patterns define an approach to incrementally design service from high-level macroflows down to low-level services using both technical and domain views. Also, a clear guidance for mapping the process and service design to architectural components is given.

In the next section, we outline this general engineering approach for designing business-driven services based on the patterns from Chapters 5 and 6. We generally recommend applying this incremental and highly iterative approach when applying our pattern language for designing SOAs. The patterns in the rest of the book rather focus on detailed issues in the context of this general approach to engineering process-driven SOAs.

Our approach to design business-driven services (i.e., services that reflect both the business and technology requirements) is to design services using a convergent top-down and bottom-up engineering approach, in which high-level business goals are mapped to to-be macroflow business process models that fulfill these high-level business goals and more fine-grained business goals are mapped to activities within these processes. Those macroflow business process activities are further refined by engineered microflows that merge bottom-up and top-down engineered application services.

This approach has already been exemplified in a number of examples and case studies in Chapters 4 to 6. Here, we want to reiterate on it explicitly.

The high-level business goals defined by strategic management can be mapped to to-be models of business processes. Following the MACRO-/MICROFLOW pattern as a conceptual foundation to structure business processes, it is possible to design the to-be macroflow business processes that represent these high-level business goals.

These high-level macroflows usually only have domain views because they are used only by domain experts. Hence, they are only needed in a domain view. Activities of these high-level macroflows are realized by lower-level macroflows. These are defined at a technically refined level. At this state, they can be translated into technical views following the DOMAIN/TECHNICAL VIEW pattern.

After the technical refinement of macroflows, it is possible to derive integration services for the macroflows, for instance, following the INTEGRATION ADAPTER pattern. These activities of the macroflows are implemented using microflows. Following the DOMAIN/TECHNICAL VIEW pattern, these microflows usually only exist in a technical view as they are only used by the technical experts. The design of these microflows is done by mapping existing application functions to services as follows:

• Existing services are modified, or new services that are missing are designed to fulfill the requirements of the macroflow integration services, or

• Existing services are orchestrated in microflow models to realize a composed service that fulfills the requirements.

The result is a set of business-driven services that are invoked and orchestrated in microflows that fulfill the requirements of the macroflow integration services.

It might turn out that the implementation of the to-be macroflow business processes implies unacceptable effort or exceeds the limits of the project budget or time frame. A typical reason is that too many difficult modifications to existing services are necessary. Also, too much effort might be required for implementing new business-driven services. In such cases, it might be necessary to adapt the to-be macroflows and thus the high-level business goals to stay within acceptable limits of the project budget and time frame. Then, a migration plan needs to be developed to achieve the original business goals and evolve the originally desired to-be macroflow business processes via several stages or projects.

That means one should possibly plan for a few iterations until all interdependent elements of the various models match: the high-level business goals, the to-be macroflow business process models, the macroflow integration services, the microflows, and the business-driven services. As far as architecture management is concerned, procedures and tools are useful to manage these dependencies and the changes being initiated.

A business-driven service in a microflow might be a composed service, where the business-driven service invokes a set of more fine-grained services (which possibly invoke even more fine-grained services). This decompositional structure should be considered as rather static and not subject to regular changes. If the orchestration of the more fine-grained services needs to be configurable, the orchestration will usually be modeled as a submicroflow. Configurability is thus the design criterion to decide whether to have a static decomposition or a configurable decomposition via submicroflows.

An execution service for a microflow can be offered, possibly following the INTEGRATION ADAPTER pattern again. Figure 7.2 summarizes this interdependent and convergent top-down and bottom-up driven approach for identifying and designing business-driven services.

Applying this incremental engineering approach together with our pattern language has a number of benefits. A main advantage is that business-driven services link services of business applications to high-level business goals. Identification and design of services is guided by a traceable convergent engineering approach—the pattern implies a methodology to design the services. Decisions on configurability of services are already included in the very early phase of service identification. Limitations of project budget and timeline are considered when creating a service model by considering the efforts to realize the services. Existing application functionality is considered to be offered as services and can be related to business processes.

However, the incremental engineering approach also has the drawback that it requires several iterations that need to be planned to match the macroflow and microflow process models with the service model.