Before we know who owns the SOA business case, how about simple business processes?

There's a good article on "owning" the business case for SOA on SearchWebServices.com. Some of my most respected analysts are quoted.

But is the question posed a relevant one? While making the business case for SOA is and will be a fascinating topic for some time, we may be jumping the gun.

From where I sit, just about everyone that has a strategic role in IT and business decisions at an enterprise has an "ownership" stake in SOA. It's that pervasive. The COO may be the best person under many current organizational charts to see all the moving SOA parts.

Yet buy-in and inclusiveness -- both wide and deep -- for SOA are essential, so it can't really fall to any one person. Assigning "business value" ownership is too abstract, really, for real-world companies to begin using it and embracing SOA. SOA is ubiquitous in its effects. The positioning of SOA as an abstraction is holding back its embrace and adoption.

So let's look at more practical questions on SOA and business value, before we go shooting for the moon. Sadly, in even the most progressive enterprises, the ownership of a single business process is ambiguous. Organizations have been ceated for decades based on the notion of decentralization -- which is just another way of breaking up complexity into small chunks and assigning responsibility for the chunks, often at the expense of minding the whole. Very few individuals or teams are defined or incentivized to manage an entire business process. Yet this an essential stepping stone to SOA, and to eventually making the business case for SOA.

We see attempts to proffer SOA from the top down, with even less emphasis on adoption from the bottom up. What I'm saying is also, and perhaps predominantly, build it from the middle out. Create the new middle for SOA at the business process level, and then evangelize it in any which way.

In effect, SOA and its foundational core, business processes, are fighting back against the long-term tide of decentralization and IT specialization. SOA says you can now make the chucks of discrete IT resources relate far better, so why not begin to look at an entire process and work to make it more efficient, and more flexible? Why not extract the best of specialization and improve, refine and reuse the parts best in the context of general business -requirements whole? See the forest and the trees. Make better business decisions -- operationally and strategically -- as a result.

As Dr. Paul Brown points out in a book I recently helped review via a sponsored podcast, Succeeding with SOA: Realizing Business Value Through Total Architecture (Addison-Wesley, April 2007), the business process is the right level to assign "ownership." Now.

When an analyst or architect -- as well as their teams -- begin to see themselves as managing and evangelizing on a business process level, then SOA can begin to make strides as a concept and methodology more broadly. To try and inject SOA into a company broadly, then discretely is putting the cart in front of the horse. Better yet to re-arrange all the horses and carts based on the right trips for the right loads, making it easier to change horses and carts as needed.

I like the idea of cross-functional teams (horses, carts, drivers, and caravans) created that serve a business process lifecycle. These would be pods (perhaps virtual in nature) of tightly-coordinated people with the right mix of skills and experience -- specific and general, technical and business-oriented, able to communicate as a team on many levels.

Like the Ray Bradbury book, Fahrenheit 451, where individuals learn and carry on whole books in their memories as a way to preserve the books and their knowledge, business process pods would retain and refine the essence of a business process and care for it and extol its virtues throughout an enterprise. They would cross all the chasms across the constituent services but at the higher business value level.

We've heard talk of a "T" person from SOA evangelists at IBM, whereby the horizontal bar in the "T" represents business acumen, and the vertical bar represents technical depth. But I like the idea of the cross-functional pod better -- a team of, by, and for the business process.

The ownership of a business process (never mind SOA) is too much for one person. A multi-talented team can provide the wetware and organizational dynamism to get SOA started on a practical, middle level -- that of a business process as a productivity entity. This step is what's needed before we start assigning ownership for the business case for SOA.