email article printer friendly

SOA: Get it Right the First Time
Creating a services architecture that is successful in the present doesn't mean you built it correctly
by Peter Varhol

Posted May 24, 2004

Building a service-oriented architecture (SOA) is easy. Most of the standards are well defined, developers require few new skills to implement service components, and existing languages and development tools can be used. Of course, because it's a new approach, existing skills have to be adapted to how Web services are intended to be used, but this will happen over time. The technical route to achieving an SOA seems, if not entirely smooth, at least navigable.

This is good news, because the potential advantages of an enterprise SOA are pretty compelling. Services can be used by multiple applications, and may be used for future applications, accelerating the process of getting new applications into the hands of users. Services can make an enterprise more agile and more ready to respond to changes in the business or competitive climate.

But there's more to building an SOA than writing code and building software modules. In fact, there's a very good chance that most enterprises will get it wrong and fail to achieve any sort of benefit. Moreover, getting it wrong will likely result in decreased efficiency and increased cost over time, as the complexities of maintaining and enhancing those services, and the applications making use of them, take more and more resources. What you thought was a lean and flexible SOA can turn into an unwieldy morass of code that is impossible to support and enhance.

The Technology is the Easy Part
The issue is not in building the Web services themselves, but rather the architecting of the SOA in the aggregate. And unlike most architectures, it is more of a business challenge than a technical one. Most SOAs fail to achieve their desired goal because of their inability to tie to business objectives.

You might think that architecting an SOA deals primarily with fast and efficient services, minimalist service interfaces, optimized database access, and adequate network bandwidth and processing power. These are certainly among the architectural considerations that bear upon the ability of an SOA to deliver value. But these are technical issues that are well recognized and solvable. In fact, while ideally these technical issues should be planned for prior to implementing the SOA, they can be successfully addressed during the building of the architecture, or even after it is in active use. In other words, getting these right only brings you into the game; it doesn't make you a winner.

But other SOA architectural issues become a part of the infrastructure and can't be fixed after the fact. They have more to do with the definition of the services than their implementation. In other words, you can build perfect services, except they may not be the services that bring benefits to your organization.

Think of it this way: Services define the essential business practices of an organization. Applications call those services to fulfill those practices. For example, one such practice might be ordering a product. You might say that all businesses do this in the same way, but there's always something unique about how it is implemented. In this case, a visitor to the Web site selects an item, and at that point a Web service checks the inventory database to see whether or not that item is in stock. If it is in stock, that Web service calls another service that prepares pricing and shipping information. That result is sent back to the first Web service, and the availability, pricing, and shipping information is delivered to the user.