Overcoming Obstacles in Implementing SOA

Posted by Boris Lublinsky on Sep 26, 2008 08:11 AM

Community

SOA

Topics

Governance ,

Enterprise Architecture

Tags

SOA Adoption ,

Service Design

According to Jonathan Mack, SOA adoption is "not nearly as ubiquitous as many of the analyst organizations and webinar publishers would suggest" today. The reason for that is very simple: successful SOA implementation is extremely challenging. The three main challenges, outlined by Jonathan, are:

• Dealing with the Pre-SOA Architecture - incorporating existing enterprise assets into SOA implementation
• Selling SOA to the Business - convincing business stakeholders, using concrete facts (not the general statements) of how SOA will yield benefits that justify its costs.
• Developing the most effective roadmap to SOA - defining the process of achieving SOA vision.

While the majority of SOA practitioners advocate building services as a thin layer on top of the existing enterprise applications, reusing functionality already in place as much as possible, such implementation is often more challenging than usually acknowledged. As Jonathan points out:

Legacy systems are built as fragments of batch and online steps that must be combined in a specific sequence to produce meaningful business functionality... 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

The practical approach to this problem, outlined by Jonathan, includes the following:

• Build a thin service tier to be the on-ramp/off-ramp to the services you will build. 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.
• 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. 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.
• 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.

A typical SOA selling point is reusability. Unfortunately this is often more an emotional than a factual argument. There is a very little data supporting this argument. According to Jonathan:

 

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.

When it comes to the SOA roadmap, the two most popular approaches to SOA implementation have emerged lately:

• Enterprise (top-down) SOA approach, which is an extremely high - risk approach with an initial price tag of a several million dollars. In addition, based on the size and complexity, such project can virtually never be accurately estimated.
• Grassroots (bottom-up) SOA approach - implementing elements of SOA (both services and infrastructure) as parts of existing business-driven IT undertaking. This approach typically does not succeed. On one hand, the scope of resulting services is limited to the specific business problem and might not be applicable (or even wrong) for the rest of enterprise. On another hand, the time and expense required to build the SOA layer can detract from other business needs of a project.

Alternative approach, proposed by Jonathan 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.

After nearly 10 years of SOA buzz around IT industry, there is still no guaranteed solution for successful implementations due to the overall complexity. Every new SOA project "must be taken on with a clear sense of realism and a well-researched understanding of the steps - and cost - necessary to achieve success."

1. Back to top

   RE: Overcoming Obstacles in Implementing SOA

   Sep 30, 2008 6:46 AM by Robert Morschel

   On the point of needing to provide a realistic ROI, the difficulty is that organisations that are riddled with fragile legacy systems will usually not have sufficient metrics to enable a decent ROI to be proposed. In such cases, the business case will usually have to be based on industry stats showing the benefits of SOA in other companies. Robert soaprobe.blogspot.com

   Reply

2. Back to top

   ESB or not from day one!

   Oct 1, 2008 3:01 AM by João Vieira da Luz

   "Common (shared) services such as logging, monitoring, and exception handling also should be Day 1 implementations." That's really true but I think that this can be accomplish without the need of an ESB in place. SOA Governance could be accomplished without an ESB ... Themes like runtime governance...

   Reply

• Older >