SOA and MDM - Friends or Enemies?

SOA (Service-Oriented Architecture) and MDM (Master Data Management) are two terms that are often encountered in Enterprise IT. I've found a fair amount of confusion over how these two disciplines overlap, if at all, and whether their principles are compatible with or antithetical to each other.

One of the comments I heard went like this

MDM subverts SOA principles because it connects implementation to implementation. It bypasses the business layer with all its rules and validation, and could create a massively coupled mess.

I have a more optimistic view. I think the very opposite is the case. Business rules should only apply when updating the source of truth for any data item. That is emphatically not being compromised by MDM, because MDM explicitly identifies sources of truth and replicas, and only controls the update of replicas whenever the corresponding sources of truth change.

In fact, MDM could help to clean up the mess that may exist with incumbent systems. Many current systems apply business logic redundantly wherever the same data is updated. But common sense will tell us that updating replicas should be a no-no, and putting a duplicate layer of business logic over it is not a solution. It's far better to remove the business logic altogether from around the update of replicas (shocking as it may sound), because MDM can provide a cleaner logic to govern the update, i.e., that replicas are never independently updated but only refreshed when the source of truth is updated. With MDM, business logic around updating a data item only needs to be in a single place - where the source of truth is updated.

I drew this diagram to try and show that SOA and MDM are complementary organising principles that an enterprise could use to advantage.

[There is sometimes the situation that two data stores hold different horizontal subsets of the same data, such as a database that holds details of Sydney customers and another that holds similar details of Melbourne customers. If these two data stores are mastered by different systems, it may be acceptable to duplicate the business logic that governs updates. However, MDM doesn't come into the picture unless the data is actually being replicated, such as when the Sydney database also holds copies of Melbourne customer data and vice-versa. There would be no need to apply business logic to this replicated data because it has already run that gauntlet once at the source of truth.]