Due to its highly organized and governed nature, Master Data is often mistaken for information with a structure and rules set in stone, changing only in content on a simple linear time dimension.
This wrong perception leads new MDM projects owners to believe that the requirements definition and analysis can be managed in a very strict way and that MDM projects can be put “on rails”. Well, experience seems to prove that MDM project management is not the same as driving a train on rails, but is closer to flying a plane in a storm. There are various reasons for this, the main one being: “MDM is about business”.
Today, the economic environment requires the business to evolve very quickly and under heavy pressure. MDM being a business enabler, it must evolve in the same way, along 3 dimensions: Content, Shape and Breadth.
Content
Master data content changes easily and freely from the operational source via a Convergence Hub, and meets milestones that reflect the company organizational milestones. For example:
- The hierarchy of Cost Centers is modified every year and frozen by the Finance team at a precise date.
- The Product Catalog (internal or external) is edited, then frozen and published every quarter.
When these milestones are met, the corresponding master data content needs to be frozen in time. Past versions of this content must remain available for access, for obvious archiving, reporting and regulatory compliance reasons. The entire company master data history, for example the cost center structure of the past years and the product catalogs published in the past are still be needed in the future.
Shape
The shape (or structure) of the master data evolves with the company organization to meet the business stakeholders and data governance team’s requirements:
- Existing entities have to support new attributes, new constraints or new processes defined by the data governance team. For example: adding the Twitter, LinkedIn, Facebook or Google+ account to the Contact definition is today a must, and making sure that a contact’s Company is refreshed from his LinkedIn profile is a plus.
- Similar changes appear when new systems become master data providers. For example, to take into account the Customers or Products from an acquired company’s systems in the corporate master data.
As the shape of the master data changes over time, these changes need to be designed, implemented and deployed with time and budget constraints. In addition, changes in shape should be version-controlled as previous versions of data shapes and content must remain accessible.
Breadth
The master data evolves in breadth as new domains are included in the data governance initiative. Master Data Management/Data Governance is a journey and not a one shot process. It starts typically with a tactical approach and a single domain (typically, Customers or Products) and absorbs progressively new functional domains.
Evolution in breadth must follow a fast and seamless path similar to the one available for the changes in shape. In a nutshell, deploying an entire new domain must be as easy and safe as modifying an attribute in an entity.
Evolving in 3 Dimensions
Evolution is performed on several dimensions simultaneously. For example:
- An acquisition occurring in the middle of an MDM project cycle, forcing changes in Shape and Breadth at the same time.
- Yearly milestones (closing period, fiscal year) occurring while projects are in progress, forcing changes in Shape/Breadth and Content.
As a consequence, a maximum of flexibility and reactivity is needed on the three axes of evolution, and support for parallel/simultaneous evolution and versions on the various axes need to be supported smoothly.
The Evolutionary MDM approach takes into account the 3 dimensional nature of the master data evolution, in a simple, fast and reliable way. It assumes that to truly evolve in the three dimensions you need a platform that gives you the evolution capability and speed of a plane.