This is possible by defining a new process that allows for the business-level analysis to occur concurrently with service design and development. Also known as the meet-in-the-middle approach, the agile strategy is more complex than the previous two, simply because it needs to fulfill two opposing sets of requirements. The process steps shown in Figure 4 demonstrate an example of how an agile strategy can be used to reach the respective goals of the top-down and bottom-up approaches.

Step 1: Begin the top-down analysis, focusing first on key parts of the ontology and related business entities
The standard top-down analysis begins but with a narrower focus. The parts of the business models directly related to the business logic being automated receive immediate priority.

Step 2: When the top-down analysis has sufficiently progressed, perform service-oriented analysis
While Step 1 is still in progress, this step initiates a service-oriented analysis phase. Depending on the magnitude of analysis required to complete Step 1, it is advisable to give that step a good head start. The further along it progresses, the more service designs will benefit.

Once the top-down analysis has sufficiently progressed, model business services to best represent the business model with whatever analysis results are available. This is a key decision point in this process. It may require an educated judgment call in order to determine whether the on-going top-down analysis is sufficiently mature to proceed with the creation of business service models. This consideration must then be weighed against the importance and urgency of pending project requirements.

Step 3: Perform service-oriented design
The chosen service layers are defined and individual services are designed as part of a service-oriented design process.

Steps 4, 5, and 6: Develop, test, and deploy the services
Develop the services and submit them to the standard testing and deployment procedures.

Step 7: As the top-down analysis continues to progress, revisit business services
Perform periodic reviews of all business services to compare their design against the current state of the business models. Make a note of discrepancies and schedule those services most out of alignment for a redesign. This will typically require an extension to an existing service in order for it to better provide the full range of required capabilities. Once redesigned, a service will need to again undergo standard development, testing, and deployment steps.

In order to preserve the integrity of services produced by this approach, the concept of immutable service contracts needs to be strictly enforced. Once a contract is published, it cannot be altered. Unless revisions to services result in extensions that impose no restrictions on an existing contract (such as the addition of new operations to a WSDL definition), Step 7 of this process will likely result in the need to publish new contract versions and the requirement for a version management system.

Pros and Cons
This strategy takes the best of both worlds and combines it into an approach for realizing SOA that meets immediate requirements without jeopardizing the integrity of an organization's business model and the service-oriented qualities of the architecture.

While it fulfills both short- and long-term needs, the net result of employing this strategy is increased effort associated with the delivery of every service. The fact that services may need to be revisited, redesigned, redeveloped, and redeployed will add up proportionally to the amount of services subjected to this retasking step.

Additionally, this approach imposes maintenance tasks that are required to ensure that existing services are actually kept in alignment with revised business models. Even with a maintenance process in place, services still run the risk of misalignment with a constantly changing business model.

Conclusion
Choosing an appropriate delivery strategy is a critical part of SOA planning. Assessing these and other approaches will confront you with some important decisions. The choice of strategy will determine the extent to which your service-oriented modeling and design efforts can realize those aspects of SOA most relevant to your organizational priorities and goals. In other words, the path you take will ultimately determine your destination.