The top-down strategy

This strategy is very much an "analysis first" approach that requires not only business processes to become service-oriented, but also promotes the creation (or realignment) of an organization's overall business model. This process is therefore closely tied to or derived from an organization's existing business logic.

The top-down strategy supports the creation of all three of the service layers we discussed in the previous chapter. It is common for this approach to result in the creation of numerous reusable business and application services.

10.2.1. Process

The top-down approach will typically contain some or all of the steps illustrated and described in Figure 10.2. Note that this process assumes that business requirements have already been collected and defined.

Figure 10.2. Common top-down strategy process steps.

 

Step 1: Define relevant enterprise-wide ontology

Part of what an ontology establishes is a classification of information sets processed by an organization. This results in a common vocabulary, as well as a definition of how these information sets relate to each other. Larger organizations with multiple business areas can have several ontologies, each governing a specific division of business. It is expected that these specialized ontologies all align to support an enterprise-wide ontology.

If such a business vocabulary does not yet exist for whatever information sets a solution is required to work with, then this step requires that it be defined. A significant amount of up-front information gathering and high-level business analysis effort may therefore be required.

Step 2: Align relevant business models (including entity models) with new or revised ontology

After the ontology is established, existing business models may need to be adjusted (or even created) to properly represent the vocabulary provided by the ontology in business modeling terms. Entity models in particular are of importance, as they can later be used as the basis for entity-centric business services.

Note

Although certainly analysis-related, Steps 1 and 2 are positioned here more as a prerequisite to the service-oriented analysis phase as we've defined it.

 

Step 3: Perform service-oriented analysis

A service-oriented analysis phase, such as the one described in Chapters 11 and 12, is completed.

Step 4: Perform service-oriented design

The service layers are formally defined as part of a service-oriented design process, such as the one described in Chapters 13 through 16.

Step 5: Develop the required services

Services are developed according to their respective design specifications and the service descriptions created in Step 4.

Step 6: Test the services and all service operations

The testing stage requires that all service operations undergo necessary quality assurance checks. This typically exceeds the amount of testing required for the automation logic being implemented because reusable services will likely need to be subjected to testing beyond the immediate scope of the solution.

Step 7: Deploy the services

The solution is finally deployed into production. An implementation consideration beyond those we originally identified as part of this step is the future reuse potential of the service. To facilitate multiple service requestors, highly reusable services may require extra processing power and may have special security and accessibility requirements that will need to be accommodated.

10.2.2. Pros and cons

The top-down approach to building SOA generally results in a high quality service architecture. The design and parameters around each service are thoroughly analyzed, maximizing reusability potential and opportunities for streamlined compositions. All of this lays the groundwork for a standardized and federated enterprise where services maintain a state of adaptability, while continuing to unify existing heterogeneity.

The obstacles to following a top-down approach usually are associated with time and money. Organizations are required to invest significantly in up-front analysis projects that can take a great deal of time (proportional to the size of the organization and the immediate solution), without showing any immediate results.

Case Study

The top-down approach was used by TLS when they first ventured into building services for their B2B solution. They went through the process of defining a corporate ontology and then implementing the resulting vocabulary within their business models and their service designs. The result was a set of business and application services, highly standardized and very reusable. TLS enjoyed a great deal of success with this initial collection of services, as they have been able to recompose them into different configurations to accommodate changing business requirements.

The time it took to carry through the top-down analysis, though, was significant. Now that the services have proven themselves as important members of the TLS technical environment, numerous new requirements are emerging, demanding the creation of new services and even new, entirely service-driven solutions. TLS's IT department is under a great deal of pressure to deliver. Despite the success of the top-down strategy, IT managers are hesitant to undergo this process again.

SUMMARY OF KEY POINTS

• The top-down strategy promotes the formal definition of corporate business models prior to modeling service boundaries.
• It can result in the highest quality level of SOA, but it also imposes a significant volume of up-front analysis work.