The problem is, I don't always do things right. Sometimes I don't have time to do something right. Other times I'm not sure I know the right way to do something, so I make up a solution as I go along. Or perhaps I simply think that this time, there's no one watching me, so it doesn't make a difference how I do it. It won't matter, as long as it gets done.

In the same way, there are a million ways to do SOA wrong -- and a lot fewer ways to do it right. That's where SOA governance comes in.

SOA governance provides ways for organizations to help ensure that their SOA environment and SOA implementations are being built and maintained correctly. That not only are things being done, but that the right things are being done. Consistently.

As I mentioned in my last column, SOA really isn't about technology, and it isn't about picking which ESB is better than another ESB, or which version of what standard to use (though all these types of questions must, of course, be answered at some point). Rather, it's about creating a culture and a set of processes that let an organization invest in services-oriented approaches that will deliver real benefits.

In short, SOA is about culture, not technology. The goal of SOA is in creating re-usable systems. Good SOA results in systems composed of services that are and can be re-used in different systems.

However, doing SOA right requires significant changes from the way that organizations traditionally develop, deploy and maintain applications. It requires more and deeper collaborations across business units, IT architecture, infrastructure managers and project teams. It requires a level of detail and strategic thought -- even at the project and task level -- that has generally not been required in most IT shops.

In short, there is no way to "instant SOA." Individual products or projects can certainly move you along the path and help your organization put some components of a good SOA strategy in place.