I’ve come across a nice chart in the baseline magazine that shows that cost is the biggest obstacle to SOA adoption (unfortunately, this chart is not available in the online version of the magazine). I think that this is very telling, it really shows how often SOA is either misunderstood or applied incorrectly (or both).

SOA is about reducing the cost of implementing business functions across the enterprise by leveraging existing systems instead of rewriting them. Any alternative architecture will most likely be more expensive than SOA (unless we’re dealing with some special/unusual requirements, such as real-time device management). Doing nothing, i.e., just maintaining the existing IT architecture without attempting to improve it, is also more expensive (unless the existing architecture is so great that it does not have any issues) than adopting SOA since the cost of maintaining duplicate functionality in multiple siloed systems is usually quite high.

SOA does not have to be costly. The cost of implementing a service on top of several existing systems usually is not that great. The cost of consuming a Web service in an application built using modern technologies should not be high (and if it is, then there is something wrong with the design or the technologies used by this application).

However, it is very easy to make SOA implementation costly. Following are some of the leading causes of that:

• Re-writing existing systems in order to implement services. In most instances, full rewrite is not needed; services can be implemented as wrappers.
• Trying to implement “big bang” SOA that involves deploying massive number of services at once. SOA is most effective when implemented in small increments.

• Over-architecting implementation of technical aspects of SOA, such as transformation, security, management, etc. Don’t get me wrong, security and management are very important; however, their design should depend on the types of business services that are being created as part of SOA. Attempting to implement SOA infrastructure “in general” will certainly lead to high price solution. For example, SSL/TLS-based approach with basic authentication works fine in many situations (not all, but many), however countless hours are spent on trying to put together security infrastructure using SAML, WS-Trust, WS-Security or whatever the latest and greatest set of buzzwords might be.

• Procuring and implementing expensive SOA infrastructure products (ESB, registries, Web service management, etc.) before a single service is put in place. My opinion (perhaps, somewhat extreme) is that at the initial stages of SOA many of these products are unnecessary.

To control the cost, SOA should be implemented using short iterations where each iteration results in implementing several services dealing with a specific problem or functional area. An iteration should also include implementation of service consuming applications for the newly developed services, so that the services don’t remain unused. Ideally, benefits/ROI of each iteration should be quantifiable.

In other words, “good” SOA is not costly; the high cost is an indication of mistakes made during SOA planning, design and implementation.