What is Evolutionary MDM™?

Evolutionary MDM™ differs from traditional MDM because it is designed from the outset to expect the MDM requirements of the organization to change and evolve over time. This evolution happens when organizations connect new data domains, modify existing domains or create new validations, enrichment rules or governance processes.

Evolutionary MDM™ is defined by its key design principles:

  • Fast Time-to-value
  • Iterative project evolution
  • Secured data evolution

Fast Time-to-value

When looking to ensure that project duration and costs for each incremental evolution in the MDM infrastructure are kept to a minimum, the last thing you want is for your MDM solution to force you to make changes to your IT infrastructure or your business processes or workflows.

Writing code that tightly binds your business applications to a specific version of the MDM data model can be a very costly thing to maintain. This is especially true if you expect the MDM infrastructure to change and evolve over time.

Changes may be needed but your MDM infrastructure shouldn’t force them upon you. Ideally your MDM infrastructure should simply accept data provided to it by business applications through whatever mechanism makes the most sense from a technical and cost perspective. It should then create reliable and consolidated versions of that data and make them available to downstream IT systems, again using whatever interface is best for you.

An Evolutionary MDM™ solution should be built upon an open architecture that requires zero IT infrastructure changes and forces zero business process and workflow changes.

Iterative Project Evolution

Over time an organization’s MDM requirements evolve. This might mean that the shape of an existing domain is changed:

  • additional validation rules are added to the governance process within an existing domain
  • additional master data publishers and consumers are connected to the platform
  • changes are made to the data model to add new entities, relationships and attributes
  • external data is used to enrich the organization’s existing data

Alternatively, it might be that the breadth of master data being managed is increased by placing a new domain under Master Data Management.

  • Customer master data is connected for business intelligence analysis
  • Supplier information is connected for statutory reporting purposes or consolidated spend analysis
  • Product master data is connected in preparation of the market place project for sharing product catalog with business partners

This ongoing process of requirement evolution puts pressure on data and business architects. First they must understand the current model, then they must design and model the changes that are required and then finally they must understand the impact of those changes on up and downstream systems.

An Evolutionary MDM™ solution starts from the assumption that data models will change. This design philosophy makes it easy for data and business architects to build and maintain powerful, semantically-complete data models that make modifying existing domains or extending MDM into new domains, a simple configuration change. Version control of data models with the ability of hosting simultaneous versions of the same model within the same master data instance is fundamental for Evolutionary MDM™.

Secured Data Evolution

In a complex master data environment it is not just the data model that changes and evolves. The data content itself changes. It changes in the upstream source systems that author the master data. It changes because of the addition of a new publishing application that adds additional fields to the golden record. It changes due to new rules that have been triggered to consolidate master data into golden data.

Data evolving like this within an MDM platform is a fact of life and can be a very powerful thing. The problem comes when the organization needs to be able to access and analyze data on a consistent basis. If a change in the data breaks an analysis category halfway through a financial year, it could mean incorrect analysis and weeks of effort to reverse the changes.

It’s important that consolidated master data can be versioned so that it can be accessed as it was at a specific point in time.

  • Financial applications should be able to view a consistent set of cost centers within a given financial year no matter whether the data has evolved during that year.
  • Business Intelligence applications should be able to report and analyze using consistent “as-of-version” customer classifications, while the underlying master data is being edited and modified significantly in the source systems.
  • Analysis must be consistent through mergers, acquisitions or divesting. Business performance and legal obligations must be able to be clearly delineated before and after the acquisition or divesting of subsidiary organizations.

Audit and visibility into the provenance of golden data is important to give business users confidence in the master data that they are using. Presenting users with a golden record where they do not know the lineage of that information, can lead to a lack of confidence in the data. Users accessing consolidated master data should be able to see the systems that contributed to it together with the data governance rules that were applied.

An Evolutionary MDM™ solution should allow the business to access master data as it was at any point in time along its evolution. Data lineage management should allow users to drill down from master data, through enrichment, validation and all governance processes, to see which source systems contributed what to the golden records.

Why Evolutionary MDM™?

Evolutionary MDM™ exists as an antidote to the inability of traditional MDM solutions to cost-effectively manage MDM requirements that change and evolve over time. Traditional MDM systems approach the challenge of building master data management solutions from the assumption that if you spend enough time analyzing requirements and building models, then those models will stay in place unchanged over time. This is simply not the experience of MDM users. And when these changes inevitably occur, traditional MDM products do little to help users to connect these changes to their IT systems, model and implement these changes or cope with the resultant version control of the golden data and data models.

Products designed around Evolutionary MDM™ principles expect change in the breadth, shape and content of the MDM requirements. This, small but fundamentally important principle, results in products that make initial projects easier to define and implement; and subsequent projects, or changes in existing projects, less time consuming and costly to complete.

Semarchy believes that IT management teams are wary of promises of big-bang, end-to-end, analysis paralysis data governance strategies and don’t want to be forced to re-write business applications or change business processes to accommodate an MDM solution. Semarchy’s evolutionary approach to MDM is the answer, where requirements evolve and projects are deployed in short, easy to manage cycles that deliver value iteratively, one step at a time.

Next Steps