As organizations bravely venture into the world of Web services, they grapple with the age-old question - where do we begin? The main challenge that I have seen with key stakeholders looking to move towards the agile enterprise is solving the dilemma of which approach to take, top down or bottom up.

Some key business drivers for considering Web services, which in turn are perpetuated by a desire to add agility to the organization, are reduction of complexity, faster response to change, and reduction in overall cost. This in turn drives the need for reuse. As we all know, the path to reuse eventually leads to services, although unlike Rome, all roads that attempt to get there don't necessarily make it. Since the need for services is driven by business, the understanding of what the service is also comes from the business perspective. The Web service is defined in business terms - it could be a status request on a purchase order, or a request for card activation. The main point here is that the Web services paradigm is meant to be understood by business owners. Service-oriented architecture is meant to bridge the gap between business and IT. The realization and implementation of the service makes its way down the business architecture tiers to the technical architecture tiers to the actual creation of the code that implements the service. The business services are consumed by business components.

However, the gap between IT and business also causes organizations to look at the bottom-up approach. In several cases, the organization may not have all of the pieces in place to translate the requirement of a business service to technical terms. And the problem of integration and interoperability at the IT level is more "real," in these environments. In such cases, the approach is to take a look at what is in place in terms of technology, products, and the implemented architecture, and how it can be simplified, abstracted, and made more usable. The definition of a Web service starts from the back-end technical tiers, driving integration and interoperability between disparate environments and products. This again puts forth the requirement for reusable services that are to be consumed by technical components. The resulting abstraction makes its way up the tiers to be used by the business functions in order to expose the functionality of the application.

So we have two orthogonal paths to reuse, and they should (must) meet in the middle. The problem is that the approach on how to make them meet is not always that intuitive. Successful definition and implementation of the appropriate architectures (business and technical) requires a well thought through strategy for adopting the change throughout the organization. Typically enterprises choose one of the two approaches (top down and bottom up), cross their fingers, and hope that the realization will make it all the way to the other side. Fortunately, there are developments in the areas of WSM (another term in the world of overloaded three-letter acronyms that refers to the management side of Web services), and business process orchestration, which can aid organizations in achieving their objectives. Nevertheless, the challenges are still there.

In the meantime, one of the main risks of adopting Web services faster than they can be consumed by the organization is the creation of several poorly defined, redundant, too fine-grained, or isolated services that will be produced, but will prove hard to consume.

So, as we define a plethora of services as offerings from our individual applications, we need to make sure that the services jumping into the Internet are defined, controlled, and managed properly. After all, I'm sure you all know what happened to each monkey who jumped on the bed. And in this decentralized world of Web services, there may be no doctor to call.