I have been wrestling with this for a while but I think I have finally found an elegant solution to the SOA Governance terminology and positioning conundrum. First, this is a short recap of the problem: we have approached solving the problem of SOA governance very methodically and developed a model that identified a number of well-defined entities that exist in the problem domain. Since most of the SOA terminology was coined by the analysts and other industry pundits, it is very imprecise and often downright ambiguous. As a result we decided to introduce our own terminology that has not been marred by multiple contradictory connotations in the context of SOA governance. That worked fine and allowed us to develop and successfully communicate the solution to technically apt listeners, however as soon as we widened the audience, those same analysts and pundits started picking on us for lack of support for the things like policies and service contracts broadly accepted as must-haves for any SOA governance solution. Ironically, when we did an about-face and renamed key artifacts of our solution to match the closest industry-standard monikers, we opened ourselves to criticism that our policies and contracts differ from those talked about in the analysts’ reports and vendor’s white papers.