"...it's architecture that drives agility first, not reuse that drives development. Write that on your hand."
"...focus on architecture, which brings agility, and less on reuse."
On Infoworld Dave Linthicum posted two very short articles on the state of SOA governance tools. He is not very amused...(part I, part II)
Linthicum stresses that SOA governance vendors focus too much on software development support and too little on an architecture that brings agility, too little on the ability to leverage foreign services and too little on standards.
I believe he is right. But I want to add yet another viewpoint: SOA governance should also support organizational aspects of the SOA life-cycle. If your company has a centralized software development department with profound mandate, things may go smooth. But in a federated organization with redundant systems, highly delegated ownerships, multi development/deployment departments and full departemental autonomy, things may not go as smooth as you would like. In order to implement an SOA, all departments have to agree together on functionality of common services, on ownership, on mechanisms for semantic harmonization, on security implementations, on performance, on accountability, on coordination processes, on common infrastructures, on error handling and routing and so on. All of these requirements must be fulfilled, otherwise you will not be able to build enterprise wide SOAs, if that's your ambition at all (well, I think it should be). To organize these aspects in a decentralized organization is a tremendous political effort which goes far beyond the capabilities of many CIOs. In practice it's not so much about bringing order in an environment of high entropy, but it's more about surviving in such an environment.
How can SOA governance tools support the requirements of highly decentralized organizations? So, maintaining local autonomy and at the same time leveraging SOA? I think by delivering methodologies, guidelines, standards, sample processes, best practices and development mechanisms that support federation. What might be a good starting point is the idea of merchandizing business events between the autonomous departments and - at this level - focus on synchronisation rather than on reuse of software components.
What do you think?