Login | Register   
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

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

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


Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap