09.24.07

Who makes the business case for SOA?

Posted in SOA & Web Services at 4:04 pm by Tony Baer

A few days ago, TechTarget’s Rich Seeley posed the question, “Who owns the SOA business case?” He contacted us, and several colleagues for his article, published last Friday. Frankly, we were a bit stumped. Our best guess is that it’s not the business’s job to specify an architecture per se. You can’t 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 my colleagues at ZapThink put it, SOA is an architectural practice; it isn’t a product or technology that you buy or install.

But somehow we don’t feel that we really answered Seeley’s question.

In Seeley’s 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 modernization.

We agreed as far as those statements went, but something still didn’t jibe. The fact is, organizations embrace SOA, not to modernize software or enterprise architectures for their own sake, but to make businesses more agile. But wait a minute, haven’t we heard those promises before?

Enterprise apps of the 80s and 90s were supposed to make your organization 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 weren’t simply migrations, but opportunities to reengineer your enterprise. All too often, once organizations started reengineering, well you know the rest of the tale…

So SOA isn’t the first time that we’ve 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 heckuva lot less traumatic than reengineering your enterprise. The flipside, however, is that maybe SOA shouldn’t simply be as disjointed a technology architectural decision as we first thought.

In his ZDNet blog earlier today, Dana Gardner helped crystallize why we felt so off base. He stated that raising the question of the business value of SOA might be “jumping the gun.” He points to the practical landscape in most organizations, 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 organizations are prepared for change.

Citing writings from Dr. Paul Brown, from a book that Gardner recent reviewed, he concluded that the business process would be the right level to assign “ownership” of SOA. Remember, the rationale for SOA isn’t 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 to line organization while gradually influencing enterprise architecture by osmosis.

Of course, multifunction teams were also supposed to be the core of those reengineering 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 doesn’t necessarily guarantee that cross-functional teams won’t 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.

Permalink