I have a new article in the developerWorks Architecture zone, "Introduction to SOA governance."
The article distinguishes between governance, IT governance, and SOA governance. The more I learn about governance, the more I'm coming to understand that a lot of IT shops aren't very good at governance in general. Companies tend to be reasonably good at corporate governance because it's required by the SEC (at least for companies on the US stock exchanges). Hospitals tend to have a lot of governance around proper health practices. But a lot of IT departments have a hard time with governance.
For example, most IT departments want to develop reusable components. But that requires identifying good reuse opportunities, designing for reuse, cataloging reusable components, encouraging development of reusable components and rewarding reuse of components, etc. Many shops don't do this very well, and so their success with reusable components is fairly limited.
SOA isn't going to make this any easier; if anything, it will make it harder. (Yes, SOA can actually make things harder; for example, see Why and when should you choose SOA?) SOA means not only that components/services should be reusable, but that they should match the business. Groups that are already good at governance can build on that success to develop effective SOA governance practices. For groups that don't do IT governance well, SOA will be even more challenging, but will also be a greater opportunity. SOA may finally be the excuse some departments need to take governance seriously and really focus on doing it well.
I hope you'll find my article a good introduction to what some of the SOA governance issues are and why they're important. Enjoy.
Introduction to SOA governance