As much by writing

Forrester analyst Randy Heffner, has published a report titled “SOA [Service Oriented Architecture] Is Far From Dead—But It Should Be Buried.”

Sparked by a tinderbox of economic jitters and technology backlash, a recent thread of industry discussion cries out, ‘SOA is dead!’ Although many have had fun with the discussion, it is in fact quite misguided. No prior industry initiative for IT architecture has had an impact as positive and broad-reaching as service-oriented architecture (SOA). But SOA’s impact is only part of the story: You have many more technology initiatives besides SOA. You need a bigger architectural vision that encompasses SOA, business process management, event processing, Web 2.0, and much more besides. Although SOA is far from dead, it should be buried inside a larger vision.

As someone who has attempted SOA in the past, and who is working on similar initiatives in my current position, I am happy to see the emphasis on business process management and event processing. SOA’s detractors often complain about its complexity–the integration of disparate technologies and interoperability of a variety of tools based on unique or specific protocols, specifications and standards. However the difficulty (consternation) often attributed to SOA is really a manifestation of the complexity inherent to an organization. As SOA implementations are actually derived from business processes, understanding those is fundamental to an SOA architecture. Quite honestly, many organizations simply do not understand how they operate within functional areas, let alone across units. In my experience, when a systems architect undertakes an SOA project, it is actually the business analysis that proves most hazardous to project success, rather than any technologies or architecture.

Heffner offers, “These types of misconceptions and limited strategies give SOA a bad name because their focus on technology separates business value and SOA,” He continues, “These strategies portray SOA as a technology savior rather than a tool (and a very important tool) in a business value tool box. Even worse, when the difficulties occur that are a natural part of introducing something new, a technology-focused model for SOA provides limited thought processes and models for resolving those difficulties.”

Data warehousing only works if an organization understands how data is collected, associated and accessed and service buses and messaging require an understanding of an organization’s business services, processes, actors and the events/rules that drive them.

Finally, Heffner offers a few strategies for implementing a SOA environment (note the operational, not technical slant):

1. Treating SOA as a business design concept.
2. Using lightweight strategy to guide delivery of today’s business benefits (street-level strategy).
3. Doing integrated, simultaneous design of both business and technology (concurrent business engineering).
4. Using a coherent business service portfolio management process to drive reuse.
5. Approaching all aspects of SOA maturity with an evolutionary mind-set and strategy.
6. Having a variety of strategic and tactical investment approaches for SOA.

Business analysis, in my experience, has been the greatest barrier to SOA, not the technologies.