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