A trail of posts on SOA and organization

I followed a trail of posts about SOA and organization and found some nice stuff along the way, starting from "Tearing down silos, brick by brick" by Joe McKendrick...

"I once heard a rumor that there actually is a company with two integration teams that actually meet and talk once or twice a year. Just a rumor, mind you."

"Lorraine Lawson brought up the whole issue of silos and lack of communication in a recent post, and the implications for SOA. Namely, that SOA not only requires developers to know what other developers are doing, but that the business know what developers are doing, and visa-versa. Lorraine cites the example of one IT professional who had no idea what his coworkers did all day."

"I’ve also heard it said that competency centers also lift SOA matters above the grind of organizational politics. SOA projects can be prioritized according to the needs of the business at large, and not to serve the agenda of one business unit. Essentially, they can be silo-agnostic. (How’s that for a new term?)"

...then to the post by Lorrain Lawson "Overcoming IT Siloes on the Road to SOA Success":

"I’m hoping and, frankly, assuming, that most organizations aren’t quite that dysfunctional. Still, even if your developers are 25 percent more talkative and social than the ones in my friend’s workplace, you can see how organizational issues within IT could be a big barrier for successful service-oriented architecture."

"SOA requires developers to know what other developers are doing – hence, you have repositories and registries. But even with these technology solutions, how the IT organization interacts internally and with the business is a common problem for SOA implementations, says Eric Roch"

...and then back to the post "Organizing for SOA Success" Eric Roch:

"While most IT organizations are focused on the technology aspects of SOA a common barrier to SOA success is IT organization itself and how the organization interacts internally and with the business. IT organizational change is needed for SOA governance including the adoption of a SOA software development lifecycle and the runtime governance of shared services and the components that support them"

"The best practice for SOA organization is to establish a Competency Center to own the services catalog, common schemas and governance processes. But a SOA Competency Center does not just spring up overnight, nor will it address cross-functional barriers without participation from other IT entities."

"To overcome organizational barriers I recommend forming a cross-functional SOA Steering Committee composed of the leader of the enterprise SOA initiative, a lead architect from each functional-application system and an enterprise architect"

...and then finally back to a video clip of a customer (Luxottica) who according to Eric Roch is "linking their success to the SOA organizational structure and roadmap". It is worth checking out. To quote one of the persons appearing in the video, Ken Faw who is Director of Integration Strategies at Perficient:

"We don't have to have a massive governance effort. We have to get it to fit in into the whole evolution of people's intuition, their capacity to absorb it. To me, service-oriented architecture is bigger than the entry point - its the plane, it's the whole transformation of intuition that is going to happen to people, that helps them to become more autonomous agents, working in parallel to achieve multiple business objectives."

Yes folks, there we have the mysterious main ingredient in the recipe of success again: PEOPLE. The main ingredient is not technology, nor is it the organization in itself. It is the people, how they think and behave. And the problem with people is that if you can't do it with them, you can't do it without them either. Wouldn't it be easier if it was all just a technology thing, about bits and bytes?