SOA governance is ultimately about control--laying down the law on process and policy, then enforcing it within your organization to ensure IT delivers quality applications and services that meet business needs. Implemented correctly, SOA governance products can facilitate and automate that enforcement, while ensuring adherence to an architectural standard for your SOA initiative, allowing the reuse of services across projects using metadata management, and decreasing the number of defects in deployed services by enforcing testing and documentation policies.
All worthy goals, but "experts" and vendors are tossing the term governance around like crooked Olympics judges hand out perfect 10s. We don't blame you if you're tired of hearing the word. It's overused, overhyped, and under-explained. In many ways, this is to be expected: Governance is about process and policy, which are specific to each organization. But there are some constants.
First, SOA governance should start early--in the requirements-gathering phase, with documentation stored as artifacts in the repository to verify alignment with business goals. Governance covers the SDLC (software development lifecycle) and run-time policies of everything--including deployment of, and access to, the services that make up your SOA. Let's say you're a developer starting a new SOA project. You probably have a directory on a network share, a spreadsheet, perhaps even a document-management system where you're storing the project charter and initial requirements document. SOA governance starts with these documents, so you'll want to create a project and store them in the SOA repository for future reference.
SOA registry/repository products focus on metadata management--the metadata collected about vital documents lets developers, managers and business analysts search and locate them during the development and deployment phases of the project.
