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.

The set of Web services mimics the manual process that has been in place in the business for any number of years. But then there's a problem. Let's say that some time in the future, the business changes this particular practice. There are now alternative methods of shipping, and the user must select a shipping method in order to complete the transaction. Yet the existing Web services don't easily support that change in business practice. At a minimum, it's clear that the second service would have to be called independently by the application, rather than by the first service. In the worst case, both services may have to be partially or completely rewritten in order to support a single change in the business practice.

This particular example is somewhat artificial and simplistic. Any real-life analogy will be more complex and difficult to resolve, and it's likely that an obvious and effective solution won't exist. In other words, this is an example of the easiest problem you will have with a poorly architected SOA.

It represents a cautionary tale of anyone embarking on an SOA strategy. Building services, even computationally efficient services, is not a guarantee of success—at least not success in terms of improving the current and future business prospects. And that is really the key. There is no reason to pursue an SOA strategy to improve operations in the present. The importance of an SOA lies in its ability to prepare you for the future.

Steps to a Flexible SOA
How, then, can you architect an SOA to achieve business as well as technical objectives? It's difficult, because business and technical objectives may have points of conflict. For example, the business today may depend upon a technology such as Electronic Data Interchange (EDI), the quarter-century old process of exchanging formatted text data between companies in the same industry. EDI is difficult and time-consuming to maintain, yet moving the business to an SOA also requires substantial resources. When present realities intrude upon future plans, all too often those future plans take the back seat. Resources get expended on maintaining the existing EDI technology, rather than building the architecture that will serve the business well into the future.

That investment in EDI may make you reluctant to orchestrate the transition to an SOA, even though it is the right business solution moving forward. The problem is that the EDI solution is proven in years of practice, while the SOA represents a leap of faith.

You can take several steps to make it more likely that your SOA will serve both present and future needs effectively. There aren't hard and fast rules, and the strategy can take as much as several years to play out, but it's better than building individual services and hoping that an SOA establishes itself in the process.

First, understand the technology behind Web services and the SOA. This is important because you'll inevitably have to make tradeoffs between what is possible and what is practical. Knowing the fundamentals of the technologies behind the SOA, and how they can be applied within the context of your infrastructure, is essential to assuring that any design can be successfully implemented.

But it's more important to understand the business. This means not only having an abstract picture of what the organization does and how it does it, but also direct experience with specific business practices. Direct experience with business practices provides you with the picture of the discrete parts of those practices and how applications support them. By understanding the details, you have the information necessary to design the services at the level of granularity that readily supports those practices.

If you have these experiences, you're in a good position to design an SOA, but it's still no guarantee of success. You have to be able to bridge the gap between current business practices and where they might migrate in the future. A crystal ball would help here, but unfortunately no reliable ones are available. Instead, it makes better sense to ease into the SOA gradually, building a service at a time. Although this might seem to go against the concept of an architecture, it enables you to take corrective action over time if results indicate that the original plan was flawed.

Therefore, the next step is to implement one or two high-value services that both fill critical immediate needs and projected future architectural requirements. Here is where the nuts and bolts of the technology come into play, as the technical and business success of these initial services will do much to drive progress toward the overall SOA.

After completing one or two services and putting them into production, collect data on how well they are serving existing needs. At the same time, examine requirements for applications about to be built that could make use of these services. If these services can be used within the context of those applications, without modification, then it's likely that your SOA is on track.

If those services can't be used in the applications that are committed to be built in the near future, then that's an indication it's time to rethink your SOA architecture. You may be defining your Web services too granular to support new applications, or you make assumptions that rely on how specific applications work today. In either case, your SOA is unlikely to be useful in rapidly building new applications.

You may argue that it is unfair to judge the value of those initial Web services in terms of how they support future applications, especially those that are in line to be built immediately. The services might not be appropriate for those applications, or the services are limited by infrastructure considerations that preclude their immediate reuse. I sympathize with those arguments, but the bottom line is that you've built the wrong services in some way.

These services have been designed and implemented with today's applications and limitations in mind. It's true that by chance one or two initial services may not immediately support future applications, but a well-architected SOA should enable multiple services to be used in just about any application, present and future. There are few valid excuses if you can't make immediate use of new services.

Once you have validated your approach to the SOA, or taken corrective action based on feedback from your initial services, you can begin filling out the architecture by building the remaining services. The process will likely happen over a period of several years, but it should be clear by this time what services are necessary to support the business practices.

Combining SOA with Strategic Planning
Why is the SOA approach to application design so difficult to get right? It requires building a set of components that not only model business practices today, but also are versatile enough to provide support for future unknown business practices. In fact, a well-designed SOA might just make the creation of those future processes obvious when the time comes to make that change.

Being able to assess what business practices will look like in several years is key to creating a successful SOA. Clearly a part of it is a guess, so the trick is to base your guess on knowledge of the business. Among the things you have to consider are scenarios in which the product or service mix that constitutes the core of the business may change, the number and types of competitors may be significantly different, or the entire business model may change.

This focus on the future means that the architecting of the SOA has to be done in conjunction with enterprise strategic planning. As the strategic planning process outlines scenarios for the future, the business and technology architects project processes that will support those scenarios. Then you have to map application components that support existing business processes into those future processes. That's where the SOA components should fall out of the mix. Then you're ready to go forward with the architecture. Following this approach gives you the best shot at building services that deliver flexibility and the ability to support new applications while providing the critical pieces that deliver value to future applications.

Alternatively, simply taking applications supporting existing processes and encapsulating them into Web services may look good on paper, and may win kudos for creating successful Web services, but you haven't built an architecture that will serve the organization well into the future.

Either approach delivers an enterprise SOA. The latter leads to a proliferation of services that deliver marginal or no value going forward, and requires the development and maintenance of an increasing number of services to support new applications. Tying an SOA with the enterprise strategy, however, means writing and maintaining fewer services over time. It may be a more difficult challenge initially, but it pays off increasingly in the future.

About the Author
Peter Varhol is a senior member of the technology staff at Compuware Corporation. Contact Peter at peter@mv.mv.com.