Normally when the Ayn Rand references start flying, I head for cover.  But since Phil Gilbert’s rant on the futility of foisting an SOA primer on naive business managers tracked back to my post on what BPM on SOA would look like, I guess I’m obligated to say something.  Phil’s nominal beef is with the mere idea of a book called SOA for Dummies, which commits the sin (in his eyes) of equating SOA with web services and ESBs.  The deeper issue, however, seems to be misappropriation by the SOA community of a value proposition that really belongs to something called Business Architecture, things like business-IT alignment, agility, reuse, etc.  Business architecture, from his description of it, looks at business and IT together as an “organic” whole (with a slight top-down business-oriented perspective), rather than starting with IT infrastructure and then seeing what you can build on it. 

So I guess he’s sort of agreeing with my post (I can’t tell), where I noted the inherent dissonance between BPM (top-down, business-driven) and SOA (bottom-up, IT infrastructure-driven).  But he thinks that trying to explain technology to the business is a misguided approach:

As Frank Lloyd Wright said: “Form and function should be one, joined in a spiritual union.” SOA is the form to the business function. And today, the closest thing we have to being able to define business function is called “BPM.”

So my problem with notions like “SOA for Dummies” is that, once again, we are spreading a technology-led message to less and less technical people, in an effort to help them “get it” when what we should be doing is spreading business-led messaging to more and more technical people so business understanding is shared.

I agree with the goal, but not with the tactic.  IT architects already believe they are business-driven.  They think their SOA initiative already is a proper response to business-driven concerns.  If it’s not adequate — and I agree with Phil that it’s usually not — then the technology has to be demystified for those dummies in business if you want anything to change, because they’re the only ones who can change it. 

In most cases, the strategic goal of the CIO is the same as the strategic goal of the line of business executive.  What’s different are the priorities, the timelines, the degree of centralized control.  Inserting another level of priesthood — the Business Architect — into the picture is not the answer.  The problem with SOA already is too much “A” and not enough “S”.  My approach would be to rearm the business with an understanding of what today’s technology can do.  Empowering the business might make it possible, for instance, to build business solutions concurrently with the service-oriented infrastructure.  Perhaps business people, not just architects, could have a voice in defining the scope and granularity of business services.

So I love the idea of SOA for Dummies.  IDG, if you’re ever looking for a companion BPM for Dummies, give me a shout anytime.