I had a few good responses to my blog post on SOA Governance. First, from Miko: "This is helpful for sure, but one of the things that's worth pointing out is the fine research by Gartner which suggests that making an artificial distinction between design time and run time governance is potentially dangerous. To quote: 'Vendors of these solutions tout their product "suites" as SOA governance platforms, but in rea I had a few good responses to my blog post on SOA Governance. First, from Miko: “This is helpful for sure, but one of the things that’s worth pointing out is the fine research by Gartner which suggests that making an artificial distinction between design time and run time governance is potentially dangerous. To quote: ‘Vendors of these solutions tout their product “suites” as SOA governance platforms, but in reality, many of these products only enable some aspects of governance. To further differentiate their products from competitors’, these vendors mold their messages into governing either the runtime or design-time environments. Although this differentiation helps the vendor identify potential buyers and would-be “champions” of their products, it can be detrimental because it promotes the erroneous notion that, with SOA governance, there should be two distinct and mostly separate viewpoints: development and execution.'” The purpose of the post was to define the patterns found in SOA Governance tools, and it is indeed okay to define those patterns. Not sure it’s “dangerous,” just adds clarity for those looking at these tools. In essence, that was the purpose of the post. I should have been clearer about that. More of a pushback came from Todd Biske. “I was surprised at David Linthicum’s latest blog entry. Normally, he’s pretty good about emphasizing that you can’t buy an SOA, but in his ‘Defining SOA Governance’ post, a lot of the conversation was very tool-centric. He stated the following.” “I’ve said it before, and I’ll say it again. Governance is about people, policies, and process. Tooling really only comes into play when you start looking at the process portion of the equation. I don’t want to dismiss tooling, because it absolutely is an important part of the governance equation, but if you don’t have the people or the policies, tools won’t help.” I’m not sure my post took “people, policies, and process” out of the mix. Indeed, I was talking about SOA Governance in the narrow (to use a term from ZapThink). The larger value of SOA governance is an approach, methods, as well as technology. Todd and I agree on that. Again, perhaps I should have been more clear about that, but the other bloggers will keep me honest. SOA governance is indeed something you do, and there is some good technology supporting the notion of SOA governance. That technology has certain emerging patterns that allow you to better define the features and function of the tools. Software Development