In my last blog I highlighted how services could be utilized in an Event Driven Architecture. In this blog I want to focus on Master Data Management (MDM) solutions. As the number of applications and databases grows over time, so too do cases where data entities are duplicated and fragmented across the organization. This is a natural occurrence since most legacy applications were built in a standalone fashion, with very little sharing of data. The problem is compounded enormously when companies go through mergers and acquisitions. As a result it becomes difficult, if not impossible, to merge common entities to create a holistic view and to keep everything synchronized.
Copies diverge and the overall integrity of data degrades. Consumers and aggregators of data must determine which copies to use and which to ignore. This can lead to different versions of truth depending on the data sources selected.
MDM solutions are designed to address this problem by creating a master “golden” source of data, and providing a mechanism to keep other copies synchronized with the golden source. New applications, processes, and services that need access to such data are encouraged to go to the master data source, as is feasible.
In many ways MDM and SOA are complementary strategies that are designed to accomplish many of the same goals. Both address the issue of IT fragmentation by unifying and rationalizing existing assets. Both attempt to establish a gold source, either of function or of data. And both promote reuse and agility.
The synergy of MDM and SOA lies in the focus of each strategy. Where SOA defines a modular approach to solution engineering where SOA Services encapsulate reusable functionality and access to data, MDM provides quality data to operate on or expose. MDM enhances the value of SOA by establishing a clean, unified, master source of data. As SOA Services are leveraged beyond application silos and departmental boundaries, their applicability and integrity depend on the establishment of a consistent and universally accepted source of data.
As illustrated, master data can be exposed directly to consumers or via SOA Services. Direct access through database connections would yield master data in its native form, (typically relational and normalized). The consumer would need to transform it into object or hierarchical form as needed. By developing SOA Services the transformation can be encapsulated in the service implementation. The service interface could offer master data in a hierarchical form aligned with canonical model specifications. Likewise, access to legacy data by the MDM infrastructure may or may not utilize SOA Services. Unless such SOA Services pre-date the MDM effort, it is more likely that new SOA Services will be created from master data rather than from legacy data.
I think I will finish of this series of blogs with looking at Business Intelligence and see how services can be utilized in that environments.
Good Luck, Now Go Architect…
An Enterprise Architect's Musings 