So you've decided to invest in Service Oriented Architecture (SOA). You've read up on it and heard the experts proclaim its potential to transform the way your business interoperates. You're excited about SOA's prospects and what it will do to improve the fitness and agility of your company. The only thing left to do is take the plunge.

It's like going on a diet. Like a diet the road to hell can be paved with good intentions and high expectations. The quest for the "perfect figure" - in this case a cost-effective, high-ROI Service Oriented Architecture - requires a lot more than will power and well-meaning thoughts. It takes real knowledge of the pitfalls you may encounter and the seemingly tasty goodies offered by some software vendors you will have to resist. It takes understanding the factors that can impede success and turn your best intentions into another fad diet failure.

Like the celebrity diet that promise results with little or no effort software vendors make just as many promises about achieving dramatic results. Unfortunately, like most things, there's no magic elixir. However, simply by understanding the factors that make a SOA more difficult and more costly to implement, you can avoid setbacks and stay on track to achieve lasting and measurable results.

Fitness Tip #1: Beware of hidden "calories," costs, and complexities.
When you start a new diet or fitness plan, it's important to understand all the components and how they contribute to your goal of a South Beach physique. Otherwise, if you're not careful, you could end up losing more muscle than fat, feeling tired, looking haggard, or even seriously damaging your health.

The same applies to starting to implement a SOA - and accounts for why so many of these implementations disappoint. Like the hidden calories in many so-called diet foods, the complexities and costs associated with the technologies underlying your SOA implementation can wreak havoc with your ROI objectives. To put this in context, we need to go back a few years and look at the evolution of enterprise integration initiatives.

During the Enterprise Application Integration (EAI) era, we learned that large-scale monolithic implementations of integration technology ultimately did not best serve the needs of the business enterprise. They were simply too complex, too proprietary, and too costly to implement, manage, and maintain. Plus, each implementation was not reusable for other purposes. No matter whether the integration project was large, small, or in-between, the implementation style and cost never varied. You always had to contend with a large stack of proprietary products that were required to make the integration software work.

This software stack was extremely complex and costly, and difficult to manage and maintain. Consequently, this approach needed bigger machines, and more operational staff, training, and maintenance, simply because of the complex software involved. As a result, typical implementations could run as high as $1 million before any useful integration was realized. At that time, there simply was no lightweight, low-cost, manageable, and reusable alternative.

SOA, as the next-generation vision of enterprise integration, now promises to improve on its predecessors as follows:
1.  Trim the amount of integration software needed.
SOA replaces complex, proprietary, and costly centralized integration software stacks with lightweight, standards-based integration software alternatives that take far less infrastructure software to implement, operate, and maintain.

2.  Utilize code, implemented as services that's not only easy to write and maintain but can be reused across applications and systems.
Say goodbye to tightly bound process orchestration code, proprietary tools, and runtime engines with little reuse potential across applications or systems. SOA takes advantage of loosely coupled integration code called services that can be implemented easily and quickly then assembled for use and reuse by any application or process that needs to do a similar function. SOA visionaries recognize that the know-how in implementing and maintaining services resided with the owners of business processes and applications, not with small groups of IT professionals who specialize in integration software tools.

Fitness Tip #2: Let the heavy baggage go.
If your SOA is falling short of expectations, it may be because most companies that supply SOA software base their service implementations on reworked EAI software, heavily dependent on an underlying application server/Message-Oriented Middleware (MOM) foundation. Coarse-grained services are implemented using tools tightly bound to the runtime environment of an integration broker that is, in turn, completely dependent on a proprietary J2EE server, MOM, and/or proprietary JMS.

Such monolithic stacks are expensive and complex to put in place and require sophisticated skills and training for IT resources. Configuration management is difficult too, especially if implemented on a large scale, which can be completely cost-prohibitive for the global business enterprise interested in large-scale, multi-location SOA deployments. That 's simply a much too complicated recipe to create and deploy a service that's reusable.

But what if a business enterprise has major investments in application infrastructure software stacks as a result of years of integration efforts?

Fitness Tip #3: Stay powerful, independent, and flexible.
SOA is based on the concept of distributed computing environments working in collaboration through shared services that aren't bound by the constraints of a specific J2EE container, method of operation, or form of transport protocol. Instead, services are developed and maintained on a distributed basis (where the business process expertise resides) and operate synchronously or asynchronously over any form or combination of transport protocols. There's no deployment or execution dependency on any proprietary J2EE stack, MOM, or specific form of service exposure (such as only deploying services as Web Services). Rather, related sets of fine-grained services aggregate into course-grained composite services at any number of logical points in the distributed architecture. These composite services may be:

• Deployed as (Unbound) Web Services
• Bound to specific synchronous or asynchronous transport protocols
• Bound across multiple forms of mixed protocol transports such as AS2, MQ Series, Tibco Rendezvous, BEA JMS, or even FTP.

Service independence enables a business enterprise to create reusable composite services on any scale easily then deploy them not simply as Web Services, but as service channels using any variety of transport protocols, including Internet protocols, proprietary messaging systems, or legacy transports. This is extremely important since most business enterprises simply can't afford to rip and replace existing investments in networking and integration software. And by fully leveraging the Java SE Platform (J2SE), SOA implementations won't drag additional, impossibly complex, and expensive prerequisite software products into the mix.

Just How Fit Is Your SOA?
Tired of all the hidden costs and complexities of your SOA implementation? Not achieving the hard ROI you were promised? Then consider putting your SOA on a new fitness program - one that's a simpler, more flexible, and more practical approach - that will deliver results for the long-term. Forget the fads and quick fixes. Select a service-independent SOA implementation with an open transport approach and your enterprise architecture will be running like a highly toned athlete in no time.

As for the diet, if it were only that simple!