A practical application of SOA

In Darwinian terms, SOA is the natural evolution of previous distributed architectural styles, such as distributed component object model (DCOM), Common Object Request Broker Architecture (CORBA), and Enterprise JavaBeans (EJB), but embraces standards, particularly those based around XML, to provide a greater degree of interoperability. There's also an explicit emphasis on business alignment, which wasn't prevalent with previous architectural incarnations. This lets SOA provide an ideal platform for business process-driven development, enabling business analysts to truly participate in the software development life cycle—one of its biggest differentiators.

However, simply adopting SOA alone doesn't guarantee a successful project (ESB does not stand for enterprise silver bullet!), and some projects should not adopt an SOA approach at all. We've heard people describe bad architectures and failed projects and say "SOA would have fixed that." But it's just as easy to misuse SOA as it is to create a clunky Java™ 2 Platform, Enterprise Edition (J2EE)-based architecture. If the early implementations of EJB failed, it was because some architects didn't really understand the limitations of the technology (those who have witnessed an application load hundreds of container-managed persistence [CMP] entity beans into memory as the result of some kind of database search know what I'm talking about). But it's just as easy to do the same with SOA. Adopting a similar carte blanche philosophy with services has led to applications that use Web services internally for every single application function call—not exactly a performant solution!

Thankfully we seem to be learning from those painful lessons of the past. For example, the knowledge gained in creating patterns and associated antipatterns that emerged from J2EE experiences has been used to construct similar best practices around SOA. IBM® has been successful in developing reusable patterns and blueprints for SOA applications and industry-specific models that aid in architectural decision making and provide methodologies for service identification.

Using such artifacts can have a dramatic impact on the costs of introducing an SOA. As with any new technology, there are associated start-up costs, and SOA can appear to be additionally front loaded. The emphasis on reuse and flexibility comes at a cost, and this can provide little motivation to evangelize SOA at a project level, where the benefits won't necessarily accrue to the project. Pattern-based accelerators and off-the-shelf assets can help reduce lead time, but ultimately there needs to be a degree of investment in an initial SOA project. Evidence does, however, suggest that organizations embarking on the SOA journey will see those costs returned in the medium term as subsequent SOA projects across the enterprise extend and reuse elements of the service catalogue, reducing their development costs.