Joe McKendrick (once again!) has another post which caught my blogreader today. This time he is pondering the relationship between SOA and data governance:

If data governance is inadequate — information is outdated, out of sync, duplicated, or plain inaccurate — SOA-enabled services and applications will be delivering garbarge. That’s a formula for SOA disaster.

He goes on to reference an article by Ed Tittel, which draws the same conclusion:

Amidst all the hype and buzzwords that surround SOA nowadays, it's still far too common for organizations that seek to integrate service-oriented architecture into their IT infrastructure to omit issues related to data integration, management and governance in their designs. As they roll out and learn to live with an SOA, however, they often discover that interoperability with other systems and solutions poses interesting problems. In fact, these problems can make interaction between systems and SOA components both vexing and time consuming.

Absolutely! When we put together our SOA Strategy Planning Tool, we explicitly acknowledged the importance of a common information model that provides:

standard representations of core information types for communication between services

Where I deviate from Joe and Ed, however, is their perspective that data governance and SOA governance are separate disciplines. Without inter-service communication there's no SOA and so SOA governnance must encompass data governance. Furthermore, that governance needs to extend beyond service design throughout the service lifecyle.

In a subsequent post, Joe calls out this post from David Linthicum in which he noodles on the same topic. I am not so sure about David's view that SOA initiatives:

need to start with the data first

It all depends on the scenario where a service-oriented approach is being applied. However, I agree with him that there is a need to understand:

the core purpose of the data, how it relates to other data, how the data is bound into entities, as well as security issues, integrity issues, and the binding to existing functions or transactions. I would go further and say that it's not just about understanding those things. In the case of security and integrity issues, there is a need to ensure that what is understood is enforced. That means defining service contracts that take account of those requirements and enforcing them through policies.

Which brings me neatly back to the SOA versus data governance discussion. Policies are the lingua franca of SOA governance and policies apply as much to the data flowing in a service network as they do to the services themselves.

If you are embarking on an SOA initiative you need to ensure that those responsible for SOA governance, ideally though an SOA centre of excellence, include individuals with data management expertise. Your governance processes should enforce utlilisation of a common information model and encompass a policy-based approach to ensure that data management objectives and constraints are enforced.