Our third look in as many weeks into some of the most common misconceptions about governance that we run into.
Governance is only needed for mature SOA initiatives
A truly effective SOA paradigm requires governance from Day One. Assets will stay with companies for years to come (assuming, of course, that the related applications perform as intended), so get it right the first time. Additionally, it is critical to apply governance processes in your pilot or other early stage projects.
SOA governance can be done without policy enforcement.
Policies are the cornerstone of governance. Control is critical as SOA projects evolve and governance needs to happen in all stages of the SDLC, as well as all systems in your enterprise. This promotes effective adoption and educates developers on industry/corporate standards, best practices and design specs for compliance in your organization.
Automation is something to fear
Notebooks of policies are almost never implemented consistently…even if you continue to throw bodies at the problem. If a policy is written, but nobody reads it, is it really a policy?
Policies must be translated into actions and enforced. To do this effectively, the process must be automated and the results must be measured. Proactive, automated policy enforcement ensures quality, increases productivity and reduces risk.
I have testing tools, so I don’t need governance
Another common one. Testing tools are not governance, despite what you may hear elsewhere (existing vendors). You need to enforce policies throughout every step in the lifecycle – from design to development, through testing and into deployment. Testing tools are necessary, but alone are insufficient for achieving anything approximating governance.