What’s wrong with governance?
David Linthicum, in this blog, this blog, and this podcast, rails on the recent trend of SOA Governance products. I’ve been a frequent listener of his podcasts, and I usually agree with what he has to say, but not in this case.
As we know, last year the buzz was around ESBs (Dave railed on those too), this year the buzz has been around governance. He correctly points out that most of the vendor products “are directories, repositories, or registries, at their essence, and may or may not include policy management.” He then states that there is “no clear architectural use case for most of these tools” and that they are “application development support tools, akin to configuration management and metadata management of years gone by.” Hmm… I think someone else pointed out the relationship of these tools to configuration management databases.
So, where’s the problem? Dave states that the biggest thing missing is the focus on architecture. He correctly states that architecture brings agility, rather than focusing on reuse. Again, no arguments with that statement. What he never states is what the role of governance should be in architecture. He implies that the tools should be offering something more, but never states what that is. If the tools really are all about management, is that really a problem? After all, that’s largely what governance is. According to dictionary.com, one definition of governance is “a method or system of government or management.” Personally, I think that SOA has actually given a more concrete purpose to these tools that have struggled to gain a significant foothold until now.
3 Responses to “What’s wrong with governance?”
Leave a Reply
I actually agree with you and David. Talk about sitting on the fence. At any rate I believe governance is probably the single most important aspect to SOA. I’m not talking about just the tools either. The entire life cycle has to have a strong discipline behind it or success is just not possible. The toolsets can assist in this but ultimately it has to be embedded in the culture. No amount of tooling can overcome the culture of a department.
The other important aspect to SOA is the actual Architecture. That’s what the A stands for after all. A collective ah-hah…. 🙂 I still think that is overlooked by most. A lot of folks make the assumption that the technical side is easy and is simply not true.
No arguments here! I’ve been known to state that the “A” in SOA doesn’t stand for Application, it stands for Architecture. It’s definitely true that the SOA Governance tools are probably more like Service Governance tools, but they’re still very important.
I believe Linthicum is right. But I miss 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.
Jack van Hoof,
Enterprise integration architect at Dutch Railways