A few days ago, we were asked the question: 'Who owns the SOA business case?' Frankly, we were a bit stumped. Our best guess is that it is not the business' job to specify an architecture per se. You cannot expect business people to ask for 'an SOA'. They have a business requirement, and IT responds. Ultimately, the job of selecting and justifying a technical architecture should be the role of technology architects.
Anyway, as analysts at ZapThink put it, SOA is an architectural practice; it is not a product or technology that you buy or install.
But somehow we do not feel that we really answered the question.
In a recently published article, Software AG/webMethods' Miko Matsumura suggested that there should be joint responsibility, using the metaphor of hiring an electrician: the electrician knows the wiring, but you own the house. Current Analysis' Brad Shimmin chimed in that the situation varies: the business owns it if it has a specific functional requirement, while IT owns it if the initiative is something like infrastructure modernisation.
We agree as far as those statements went, but something still did not jibe. The fact is, organisations embrace SOA, not to modernise software or enterprise architectures for their own sake, but to make businesses more agile. But wait a minute, have we not heard those promises before?
Enterprise apps of the '80s and '90s were supposed to make your organisation more agile because everyone would now read from the same page, or that enterprise application integration would provide the integration that your enterprise apps originally promised but never delivered. Or that web-enabling all those apps or integrations would make your enterprise move at Internet speed because everyone could access those systems on any browser.
Rubbing salt into the wound, those enterprise app projects were not simply migrations, but opportunities to re-engineer your enterprise. All too often, once organisations started re-engineering, well you know the rest of the tale.
So SOA is not the first time that we have heard the statement that business and IT are all in this together.
But there is a difference with SOA because of one core assumption: SOA is supposed to be loosely coupled. Data should no longer be tied to particular databases, and processes should not be attached at the hip to specific business applications. Using SOA, you should be able to configure new processes by composing services exposed by all those apps and data sources. The good news is this sounds a lot less traumatic than re-engineering your enterprise. The flipside, however, is that maybe SOA should not simply be as disjointed a technology architectural decision as we first thought.
In a recent blog, Interarbor Solutions' analyst Dada Gardner helped crystallise why we felt so off base. He stated that raising the question of the business value of SOA might be 'jumping the gun'. He pointed to the practical landscape in most organisations, where no single entity typically owns specific business processes. Consequently, bottom-up approaches, process by process, may be self-defeating. Similarly, top-down mandates may prove too arbitrary, failing to acknowledge the interdependencies of all the moving parts or the varying velocities at which different parts of the organisations are prepared for change.
Citing writings from Tibco's Dr Paul Brown, from a book that Gardner recently reviewed, he concluded that the business process would be the right level to assign 'ownership' of SOA. Remember, the rationale for SOA is not SOA itself, but to improve the way the business functions, which at the end of the day means improving the flexibility and responsiveness of business processes.
Ownership of SOA would therefore be the domain, preferably, of multifunctional teams choreographed by architects or evangelists whose role is to provide the big picture. In that sense, SOA would be owned from the middle, from which it would gradually spread down while gradually influencing enterprise architecture by osmosis.
Of course, multifunction teams were also supposed to be the core of re-engineering efforts that accompanied those SAP implementations. In both cases, the tactic was the same: get broad-based input, even if the ultimate strategy was different. But it does bring up one key issue: maybe the ends are different, but could the problems be the same? Just because SOA differs architecturally from ERP does not necessarily guarantee that cross-functional teams will not vastly overrun their mission.
No answer is perfect, but by process of elimination, Gardner's notions probably provide the most practical response to the question of who 'owns' the justification of SOA.