SOA so simple even a caveman can do it?

Is SOA fighting complexity with more complexity?

For years, vendors have been promoting the thought that the complexities of IT infrastructure can be abstracted away, and even businesspeople (or at least analysts) would be able to design high-level business process flows while the technological underpinnings underneath automatically fall into place.

The general consensus on this line of thinking seems to be...  ...after some laughter... yeah, right. 

I've been asking this very question in this blogsite, with some interesting feedback. Can, or should, SOA be made simple enough that ordinary folks with little or no IT knowledge can assemble applications?  It would seem the Web 2.0  wave is moving things in this direction, with an assorted variety of widgets, mashups, pipes, and other rich Internet applications. 

The question of simple SOA for the masses was also taken up in Dana Gardner's latest SOA BriefingsDirect podcast (summarized and linked here). I had the opportunity to join Dana,  along with analysts Steve Garone, Neil Ward-Dutton, and Jim Kobielus for a give-and-take discussion on what constitutes simplicity, and are we getting there?

Jim Koblielus said that SOA hasn't gotten any simpler on any level:

"Everybody thinks of simplicity in terms of, 'Well, rather than write low-level code, people will draw high-level pictures of the actual business process, not that technical plumbing.' And, voila! the infrastructure will make it happen, and will be beautiful and the business analysts will drive it. ...these high-level business processes, though they can be drawn and developed in BPMN, or using flow charting and all kinds of visual tools, are still ferociously complex. Business process logic is quite complex in it’s own right, and it doesn’t simply get written by the business analyst. Rather, it gets written by teams of business and IT analysts, working hand in hand, in an iterative, painful process to iron out the kinks and then to govern or control changes, over time, to various iterations of these business processes.This isn’t getting any simpler."

Jim added that technical issues aside, SOA is an organizational transformation strategy, and there's nothing simple about that, either. "The whole SOA governance process is just an ongoing committee exercise of the IT geeks and the business analyst geeks getting together regularly and fighting it out, defining and redefining these complex flow charts."

Niel Ward-Dutton noted that it's not in vendors' best interest to make things too simple. "At the end of the day, too much simplicity is bad for business. It’s not really in any vendor’s interest to make things too easy," he said. "If you make things too easy, no one’s going to buy any more stuff."

Niel reminded us as well that SOA is a process, not a destination. It's a journey that involves taking a hard look at the way things are done, the way processes are managed throughout the organization:

"It’s all of our responsibility to keep reminding everyone that, while this stuff can, in theory, make things simpler, you can’t just consider an end-state. You've got to consider the journey as well, and the complexity and the risk associated with the journey. That’s why so many organizations have difficulties, and that's why the whole world isn't painted Microsoft, IBM, Oracle, or webMethods. We’re in a messy, messy world because the journey is itself a risky thing to do."