Effective SOA Governance keeps the focus on architecture
By Bob Rhubart-Oracle on Feb 25, 2008
Thanks to a post by Joe McKendrick, InfoWorld blogger David Linthicum picked up on my recent post about an informal survey we conducted at an industry event late last year. In his post, David suggests that there is too much focus on SOA governance and not enough on architecture. He offers this comment:
The clear path that most are taking is to build the services, and then layer in the SOA governance technology without a clear understanding of what they will do with those services. There is typically no architectural notion of how to place volatility into a domain to facilitate agility. SOA governance, at the end of the day, is good infrastructure for SOA (behavior and technology). SOA governance should be more of a best practice than anything else, and a small part of a more holistic solution. No single technology will allow you to win the game here, trust me.
I agree with David's assessment that the strategy of building services and then layering in SOA governance technology is unwise. The first problem with that strategy is that SOA governance should apply to the entire service life cycle, not just the determination of how existing services should be used, but also the determination of what services should be built in the first place.
The second problem is the reliance on technology alone to implement governance. Effective SOA governance is a matter of people, process, and technology -- all three. That should be a familiar mantra to regular readers of this blog.
SOA governance is about organization, about clearly defined roles, processes, and policies. It's about knowing what you have and how it's being used. It's about shaping behavior to insure compliance with architectural guidelines -- and ultimately with business objectives -- at every stage in the service life cycle. Technology's role in larger SOA governance picture is to provide the tools necessary to address the responsibilities and information needs of the various roles, automate the various governance processes, and apply and enforce the appropriate policies. Technology isn't SOA governance -- technology is a tool of SOA governance. Let's not forget that other mantra: SOA governance is something you do, not something you buy.
I agree completely with David's assertion that no single technology will deliver SOA governance, but I'm a bit confused by his comment that SOA governance should be a "small part of a more holistic solution." When properly organized and implemented, SOA governance is the holistic solution, no? It's true that SOA governance should be a part of the larger SOA effort, but it's a critically important part. Effective, holistic SOA governance is exactly what is necessary to place the focus on architecture, and keep it there.
Read David's entire post: Too Much Focus on SOA Governance…Not Enough on Architecture