Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Implementing SOA in the Real World: Insights from the Trenches : Page 2

What are the key elements to successfully implement SOA? What are the obstacles and how can they be overcome? Providing insights from major SOA implementations at Fortune 500 companies, the author looks under the covers to provide first-hand insights on meeting SOA’s challenges.


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



As Senior Technical Architect in the Corporate Office of Technology of Guardian Life, Jonathan Mack guides the architecture of major re-engineering projects implementing state-of-the-art SOA and BPM. Prior to Guardian, as chief architect at 1-800-Flowers.com, Jonathan led efforts to make its multi-brand, multi-channel initiatives service-oriented. Through his career on the cutting edge of technological change, Jonathan has garnered valuable insight into the opportunities and risks involved in transforming enterprises from siloed, legacy environments to agile service-oriented architectures.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap