In a previous blog I discussed the four primary MDM architectural styles: consolidated, registry, coexistence, and transactional. In case you missed it, read it here: MDM Architecture Styles – Do you have the right mix? Each has their individual strengths and weaknesses, but no single MDM architectural style is ideal for every application. Beyond the implications of the architecture styles themselves, organizational factors—as well as characteristics of specific domains—should be considered when determining the optimal architectural style for a domain. Adding to this complexity, organizational factors will evolve as a business grows. In this blog I’ll discuss a few examples where organizational growth can make re-architecting an existing MDM application with a new architecture style worth the investment.
Chart of Accounts – From Consolidated to Transactional
If an organization has one authoritative General Ledger (GL) application and a flat organizational structure, then the IT strategy will probably channel the master data management budget to other priorities. However, complex or acquisitive companies often have several general ledger applications, each being the system of reference for their given domain or geography—and, almost certainly, overlapping financial accounts and conflicting hierarchies at the central point. This lack of clarity at the central point could mean bad news for your BI strategy, but an investment in a consolidated MDM solution—where the consolidated accounts don’t need to be mapped back to the source systems—provides a quick win for a manageable investment.
Changes in the business such as new regulations, expansion into new markets, and mergers/acquisitions should compel firms to evaluate the chart of accounts MDM strategy. Shifting the architecture from consolidated to transactional MDM provides the necessary governance—through improved stewardship-driven accountability, increased data accuracy and timeliness, as well as greater system flexibility—to keep up with these demands. In many industries, increased regional and global regulation is fueling greater accountability for the data in corporate systems, wherever it may originate. Enabling governance—led by centralized stewardship of the data—over important changes that require quick decisions makes the investment in a transactional MDM architecture worthwhile. Several Kalido MDM customers in the consumer packaged goods (CPG), heavy assets, and financial services sectors were early pioneers in using transactional MDM architectures. With the trail blazed, it is easier for other organizations to follow this same path.
Location – From Consolidated to Coexistence
Public-facing industries like retail, CPG, and financial services tend to apply a bottom-up business process to location data. In multi-national organizations, differences exist both in how locations are addressed and how the local business organizes locations into hierarchies. And those hierarchy differences are often critical to doing business in those locales, even if the same locations are mapped to different standard hierarchies for the central organization. But in the earlier stages of an MDM architecture evolution, a consolidated strategy will certainly get the job done—and for some organizations this may be all that is ever required.
However, more complex businesses that have multiple lines of business operating in the same geographic areas discover that both local and global harmonization of this data using data mapping technologies and stewardship, then distributing the data back to the local layer are needed. This requirement for layering localized and centralized data organization and control can make a coexistence MDM strategy the ideal architecture for location data in these overlapping organizations. Another possible architecture style organizations consider employing to meet this requirement is the registry style of MDM. However, virtualization of the data can be particularly cumbersome to implement and maintain across a heterogeneous system landscape and where data management policies are not globally consistent.
Product – Coexistence or Transactional?
The product domain often encompasses several types of goods, from raw materials to the finished goods that roll out of the factory. Raw materials tend to be highly localized; whereas, finished goods tend to appear in multiple markets. Focusing our MDM discussion on finished goods, different markets (e.g. business units, geographies, etc.) may measure, package, and classify a product quite differently. This is particularly true of the packaged goods items we all purchase as consumers. Differences range from the simple things like using the correct unit of measure for products in that geography to more subtle variables of local distribution channels, packaging, and incentive preferences of local consumers in each market. The later examples are often better understood by the local team than management back at corporate. However, coordinated pricing, production, promotion, and distribution are essential to success. CPG finished products are a classic case of the need to balance local autonomy with centralized control.
CPG finished products are also an optimal fit for the coexistence MDM strategy. A coexistence strategy balances the needs of local autonomy and centralized control well—and does so without necessarily requiring big investments in infrastructure to perform real time data synchronization and harmonization.
While it may be cost effective for most organizations to implement a coexistence MDM strategy for product data harmonization, other companies with products that have variable or rapidly changing components and configurations may be inclined to seek more centralized control of their product data. Reducing the chance for costly errors with products that are either inherently complex or add complexity through their configuration process can be best accomplished through centralized authoring –an important component of transactional MDM strategies. This allows complex products to be configured rapidly and integrated into downstream systems so that opportunities are not lost to the latency of a coexistence model. Those organizations that truly need a transactional MDM environment for their finished products will typically find it well worth the investment.
In this blog I have walked through a few typical domains and tried to focus on the tipping point where companies may want to consider moving from one MDM architecture style to another. Next time I will explore some of the technology patterns that are common to implementing the coexistence and transactional architecture styles.