Andrew White

We all know that SOA is a design style – a way of developing applications and integration.  Adopting SOA leads to a change in the way ‘stuff’ happens.  Gartner, and others, have published widely on the different uses of SOA, and I myself wrote a note some time ago on where SOA adds most value to the business.  Recent dialog with users has shown however that the majority of spend focused on SOA has been on more tactical uses of the approach; in simplifying integration techniques.  Given my background in Supply Chain, I would argue that there is potentially far greater value to the business from SOA at the strategic level, that is, in the rapid orchestration, and re-orchestration, of business applications supporting new, evolving business processes.  The baby steps of “simpler integration” are fine, but SOA needs to be more relevant to business if IT is to leverage the approach and support the business. 

In doing over 45 reference calls for last summer’s Magic Quadrant for Master Data Management of Product Data, I found 2 customers that explicitly had connected their MDM strategy to their SOA strategy.  That is a terribly low number – but not surprising to me.  The weakness this exposes in many SOA strategies is that it creates a huge risk factor that threatens to undermine SOA and lead to failure. 

When designing a new business application with application and data services that span multiple data stores (as they exist today), something has to incur the cost of reconciling the different [master data] semantics across the multiple data stores.  Today, IT has to incur this cost with yet more integration work that seeks to link each stove pipe of data to the next with ever more complex point to point or spaghetti integration.   With any new application this same spaghetti has to be expanded, unless something different is adopted. See When SOA Breaks, What Then?   With SOA the development of new applications means many more service to service interactions; far more than there were between today’s far less granular application to applications.  Clearly, if every SOA-based application interaction had to incur the costs of data reconciliation, mapping, clean up etc, then the cost of building and maintaining that SOA-based application would exceed what it costs today without SOA.  The bottom line: SOA needs MDM to help with the evolution of the information infrastructure.  See The Role of Master Data Management in the Business Service Repository for one view on how MDM will get aligned to a SOA oriented strategy focused on reusable services.

However, the reason why so few users align MDM and SOA is because so little SOA is really focused on the high value-add parts of the business, that being between application and/or data domains.  Most SOA oriented spend is focused on tactical improvement centered on integration currently existing applications.  AT some point, as SOA becomes more strategic, MDM will get another fillip in the arm in terms of demand.  SOA runs the risk of being DOA without MDM (in complex environments).  You should see more research on the connection between MDM and SOA in 2009.