or most enterprise architects, the value proposition of service-oriented architecture (SOA) is clear: SOA enables flexibility, agility and re-use benefits that are broadly recognized throughout the software development community. You might be surprised, however, to find that SOA adoption is not nearly as ubiquitous as many of the analyst organizations and webinar publishers would suggest. There?s a simple reason for this: Despite all that?s been written about SOA, despite all the success stories that proliferate, SOA is far more challenging to implement successfully than its promoters would have you believe.

I began designing systems that implement service-oriented patterns nearly 10 years ago. I?ve been involved in projects that ranged from implementing simple system interactions as services to highly complex interactions that involved the full range of service-oriented patterns. Nearly every one of these projects encountered challenges that were not fully anticipated at their outset. In this article, I?ll describe a few key challenges and I?ll make some suggestions about the most effective way to overcome them.

Challenge #1: Dealing with the Pre-SOA Architecture
Few SOA initiatives are greenfield. Transforming an existing matrix of complex interactions into an SOA is vastly more complex than building a service-oriented architecture from the ground up. The laws of nature operate here: Over time, corporate systems become increasingly complex. Paradoxically, as system-to-system interactions become more and more complicated?the more they need SOA?the more difficult they are to untangle successfully.

Vendors and analysts often speak of wrapping legacy applications in a service layer. While this makes logical and architectural sense, it?s far more challenging than is usually acknowledged. Legacy systems are built as fragments of batch and online steps that must be combined in a specific sequence to produce meaningful business functionality.

On the surface, this sounds like a common SOA pattern: combining granular/atomic services to create composite services that fulfill business functions. The problem is that the granular units of legacy systems are not all the same thing as the atomic services of SOA. The legacy steps were designed to meet pragmatic needs, often driven by practicalities of the development process, rather than mapping to discrete functions. Each individual step lacks coherence and meaning from a service perspective. Two other critical elements of a service are lacking:

1. A true service must have a first-class interface?for example, an interface that does not depend on other interfaces to perform useful work and
2. A service?even a granular service?needs to be meaningful in functional terms. In the vast majority of legacy systems, only the complete sequence of steps has such meaning.

What I?ve seen in practice is that deploying services based on legacy systems requires significant new development of legacy code. This is a labor-intensive effort. I?ve seen the analysis itself absorb much greater resources than expected. While there?s no simple solution to this problem, I can make some suggestions:

1. Recognize that full service-enablement of all legacy interactions is rarely a viable option. There?s no way to rationalize the expense of transforming currently functional interactions into services simply for the sake of architectural purity. In fact, there?s no good reason to do so. There?s nothing wrong with a hybrid architecture.
2. Build a thin service tier to be the on-ramp/off-ramp to the services you will build. The key to SOA adoption is lowering the barriers to entry as much as possible. Create the components that will enable legacy programmers to do what they?ve always done?i.e., to design programs with clearly defined inputs and outputs?that will very easily plug into your service layer.
3. Incorporate monitoring and exception-handling hooks into the service tier from the start. One of the most important benefits of SOA is the ability to accurately monitor application activity. Don?t add metrics as an afterthought; bake them into your service layer from the beginning.
4. Build specific services where there is a clear advantage to a service over a point-to-point interaction. Define and publish clear criteria for building a new component as a service. The primary criterion is the existence of multiple clients for the service.
5. Don?t go overboard with Centers of Excellence. As often as not, these become islands disconnected from the core work of the enterprise. Do have a small team specifically selected for their ability to work with other developers in your environment. Work collaboratively from the beginning to build the common services that will be the foundation of your service layer. Doing so simplifies building services that satisfy existing business requirements.
6. Wherever possible, build atomic services to interact directly with the mainframe, and build composite services using ESB software. Keep the atomic service layer and composite service layers separate.

Challenge #2: Selling SOA to the Business
Selling SOA to the business is a significant challenge. I?ve found business decision-makers to be far more skeptical than a wide-eyed architect might imagine. They?ve heard stories of amazing increases in productivity, agility, cost-effectiveness, and so on, far too many times to believe them just because their IT experts say so. Component re-use is one of the most oversold concepts in software. How many different software revolutions have promised effective re-use without delivering the goods? To convince the major stakeholders, you need to be much more specific. Drawings of how SOA untangles the rat?s nest of intertwined systems are nice, but business stakeholders want far more concrete details of how this effort will yield benefits that justify its costs. They?re also skilled at sifting soft from hard numbers in ROI estimations. Regardless of how you approach SOA, you must provide very realistic figures if you want to be taken seriously.

I advise architects not to sell SOA at all. We?re architects, not used car salesmen; it’s not our job to promote anything. Our task is to clarify the options and identify strategic and tactical directions that bring value to the enterprise, not to be advocates for any specific approach or architecture. What makes sense both strategically and tactically depends on the specific competitive context of your particular enterprise. Rather than simply appearing neutral, we have to be neutral?i.e., be concerned only with the most effective way for the enterprise to achieve its business objectives.

Challenge #3: Developing the most effective roadmap to SOA
To the extent that we, as architects, do see the value in SOA, our next problem is defining the process of achieving it. I?ve experienced many different approaches?and each has its own strengths and pitfalls.

The first approach is the most aggressive. Implement the entire SOA suite of components across the board. This is an extremely high-risk approach. Understand from the beginning that the total cost of such an effort will be several million dollars. Projects of this scale are nearly impossible to estimate accurately because you can?t anticipate the obstacles. It is rare that a massive overhaul of this sort is successful. The vision is terrific and makes your architect?s heart throb. But nearly all efforts of a mass scale to build a service-oriented architecture from top to bottom don?t take into account the time and resources required, including both resources who may be resistant to the vision, and those who are necessary to implement it. My advice is to not go for the big bang.

On the other end of the spectrum is the notion of trying to build services surreptitiously. I don?t mean that they?re kept secret, but merely that the attempt is made to build SOA by including efforts to flesh out the service layers of the architecture in the process of completing other business-driven functionality. My experience is that this doesn?t work. While it is possible to add specific services as the solution to business needs, constructing the overall framework?i.e., building the tiers and the software to govern the services?simply cannot be done by folding it into other projects. The time and expense required to build the SOA layer detracts from other business needs; that cost is simply not acceptable to the business.

The alternative is to build SOA incrementally. Most vendors have come around to recognizing that this is the most reasonable approach. Nevertheless, it?s not simple to accomplish. The key elements of an Enterprise Server Bus (ESB)?the ability to translate and transform information from one system to another and the ability to route messages?as well as the messaging infrastructure to transmit the information must be in place from the beginning. Common (shared) services such as logging, monitoring, and exception handling also should be Day 1 implementations.

The bottom line: Building an effective SOA is one of the few enterprise imperatives in the software world, yet, as necessary as it may be to maintain competitive viability, it must be taken on with a clear sense of realism and a well-researched understanding of the steps?and cost?necessary to achieve success.