A colleague recently passed me an article from Joe McKendrick, "Is SOA governance also its own silo?" that really got me thinking. If SOA governance is a software development activity, does it become a self-defeating initiative?
In the post, Joe cites an Ovum analyst and blogger we've followed for some time, Tony Baer: "There are various issues at work with SOA governance silos, Tony said
in the Ovum report. First, there's a perception that SOA-based
technology is "reserved for elite practitioners." Of course, relegating
SOA to an elite group "compounds the waste and duplication that SOAs
were supposed to avoid."
The threat of Vendor-based SOA is well known - basically locking you into one technology stack isn't a SOA approach by definition. But neither is the reaction of having a SOA Governance strategy assembled strictly by a star chamber of developers within the company.
What is ironic here is that the very concept of SOA Governance is to accommodate federated authority, loose coupling and flexible assembly of technologies around business needs. If indeed the concepts and tools required for SOA Governance become so specialized or complex that only a certain class of technologists can use (or reuse) them, instead of the business subject matter experts, we are inherently missing the boat.
This has been one of the biggest questions we ask ourselves as an organization -- "Am I doing everything in my power to make ensuring quality and agility as approachable for the customer as possible?" We hope all vendors and services firms involved in SOA consider this line of reasoning. Specialist IT teams, if put into a [[SOA Governance Silo]] will be increasingly stretched and understaffed, plus the farther removed they are from the business, the more they will take a technology-first approach to governance (what are my tools, what WS* protocols, etc.), and limit the business value they can deliver over the long term.
Comments