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:
- 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
- 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:
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.|
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.