Step 6: Test the services and all service operations
The testing stage will require 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 services. 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.

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, thereby 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 are usually 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.

The Bottom-Up Strategy
This approach essentially encourages the creation of services as a means of fulfilling application-centric requirements. Web services are built on an "as need" basis, and modeled to encapsulate application logic in order to best serve the immediate requirements of the solution. Integration is the primary motivator for bottom-up designs, where the need to take advantage of the open SOAP communications framework can be met by simply appending services as wrappers to legacy systems. A typical bottom-up approach follows a process similar to the one explained in Figure 3. Note that this process assumes that business requirements have already been collected and defined.

Step 1: Model required application services
This step results in the definition of application requirements that can be fulfilled through the use of Web services. Typical requirements include the need to establish point-to-point integration channels between legacy systems or B2B solutions. Other common requirements emerge out of the desire to replace traditional remote communication technology with the SOAP messaging communications framework.

For solutions that employ the bottom-up strategy to deliver highly service-centric solutions, application services will also be modeled to include specific business logic and rules. In this case, it is likely that two application service layers will emerge, consisting of hybrid and utility services. Those services classified as reusable may act as generic application endpoints for integration purposes, or they may be composed by parent hybrid services.

Step 2: Design the required application services
Some of the application services modeled in Step 1 may be delivered by purchasing or leasing third-party wrapper services, or perhaps through the creation of autogenerated proxy services. These services may provide little opportunity for additional design. Custom application services, though, will need to undergo a design process wherein existing design standards are applied to ensure a level of consistency.

Step 3: Develop the required application services
Application services are developed according to their respective service descriptions and applicable design specifications.

Step 4: Test the services
Services, their associated solution environment, and underlying legacy logic are tested to ensure that processing requirements can be met. Performance and stress-testing measures are often used to set the processing parameters of legacy systems exposed via wrapper services. Security testing is also an important part of this stage.

Step 5: Deploy the services
The solution and its application services are deployed into production. Implementation considerations for application services frequently include performance and security requirements.

Pros and Cons
The majority of organizations that are currently building Web services apply the bottom-up approach. The primary reason behind this is that organizations simply add Web services to their existing application environments in order to leverage the Web services technology set. The architecture within which Web services are added remains unchanged, and service-orientation principles are therefore rarely considered.

As a result, the term that is used to refer to this approach - "the bottom-up strategy" - is somewhat of a misnomer. The bottom-up strategy is really not a strategy at all. Nor is it a valid approach to achieving contemporary SOA. This is a realization that will hit many organizations as they begin to take service-orientation, as an architectural model, more seriously. Although the bottom-up design allows for the efficient creation of Web services as required by applications, implementing a proper SOA at a later point can result in a great deal of retro-fitting, or even the introduction of new standardized service layers positioned on top of the non-standardized services produced by this approach.

The Agile ("Meet-in-the-Middle") Strategy
The challenge remains to find an acceptable balance between incorporating service-oriented design principles into business analysis environments without having to wait before integrating Web services technologies into technical environments. For many organizations it is therefore useful to view these two approaches as extremes, and to find a suitable middle ground.