• Conrad Chuang

Key Master Data Facets: Modeling - Part 1

Updated: Jun 6, 2018

As we mentioned in our last post we're highlighting commonly overlooked facets of in MDM. These posts are in preparation for our Sept 19, 2012, webcast with Andy Hayler on "Best practices in MDM vendor selection." In this post( and the next) we will examine the problem of modeling. In this entry we examine data modeling. Workflow modeling will be covered in an upcoming post on governance and lifecycle management.

The data model is documentation. For an MDM project to be successful, you need to be clear on what you will be governing. And that means you need to document, in an unambiguous way, the values and the relationships you plan on managing with your MDM. This creates many questions, since some of these concepts are fairly meaty we've broken up modeling into two parts:

Modeling Part 1 (31 Aug 2012)

  • Can I use someone else's model?

  • How will I capture, or document, my master data requirements?

  • How can I deal with different data models patterns?

  • How can I define business rules to enforce validation?

Modeling Part 2 (4 Sept 2012)

  • How will I deal with models' lifecycles?

  • How will I verify that what I've documented is accurate?

  • How will I integrate my models into the MDM platform?

  • Can I use the models for more than documentation?

  • Can I use someone else's model?

It depends on what you're mastering.

In cases where you're mastering fairly simple things: standard code lists, country/postal codes, securities symbols; you can use someone elses model. But most firms are looking to manage more than simple things. They would like to master their financial data, organizational hierarchies, customers, products, locations-data that are specific to their organization. The more specific the need the less relevant a 3rd model becomes. At some point the costs of learning, analyzing and customizing someone else's model outweighs the benefits of starting with a vendor-built, or industry standard model.

How will I capture, or document, my master data requirements?

Documenting models usually involves using a UML or database modeling tool, such as Enterprise Architect or Rational. The resulting UML or ER diagrams are imported into your MDM platform. There's a couple of interesting considerations that emerge when you start to use a generic modeling tool.

The UML tools have a very wide feature scope, covering everything from interface design, class modeling, and state transitions-you'll probably use a very small subset of the tool for your MDM project. Additionally, UML is a conceptual modeling language, while this means that it has the richness to describe your domain and it's relationships in full — it may be too conceptual for an MDM implementation. This means investing some time, after documentation, translating the conceptual model into a more logical / physical form which can be easily implemented in an MDM system. Database modeling tools are on the other end of the spectrum. Unlike UML model, several kinds of relationships (inheritance, multi-cardinality) are difficult represent cleanly in these kinds of models. This means investing time to translate the physical output into something more logical/conceptual that can be implemented across multiple type of repositories.

Avoiding the model upsampling / downsampling effort may be reason to consider avoiding a generic modeling tool and examining an MDM platform with a built-for-purpose modeling tool. The vendor is likely to have built the modeling tool around the specific constraints of the MDM problem which avoids the over-expressiveness of UML and the physical-prescriptiveness of physical database models.

How can I deal with different data models patterns?

One of the difficulties of master data modeling is the wide range of model patterns. In most cases, you will think of a relational model with "flat" tables but as you look at the data and its relationships you'll notice that you'll need to define other type of structures. Some data model are highly hierarchical, with recursive relationships between node ; that's the case for charts of accounts or cost centers hierarchies. Other data models must contain dynamic structures. For instance, in a product data model, product attributes frequently depend from where the product is attached in a hierarchy. Other examples include inherited field, multi-value fields, complex reusable types. And don't get me started on internationalization. In some companies both the product names AND the product hierarchies are different across borders.

If your MDM solution cannot absorb all those different patterns, there is a risk that you might implement an overly rigid model. That lack of flexibility translates into hard-coding a lot of behaviors and rules on top of a physical model. This will increase the cost of implementation but more importantly make any change expensive and time consuming.

How can I define business rules to enforce validation?

Usually, the development of an application starts with the design of a data model, and then the coding of business rules and processes. In Master Data Management, the challenge is that the business rules that enforce validation must be part of the data model. From simple control like min/max values to complex algorithm with functions and operators, your business rules are part of the definition of your master data. To achieve flexibility in the MDM, it is necessary that rules are linked to the data model definition and rely on the same life cycle.

These are just a few of the modeling, or documentation, issues and problems that teams should be aware of when investigating master data management platforms. Certainly, there are many more issues that are out there in just this narrow slice. Please feel to send along any comment (challenges?) on our post in the area beneath. And look for our next post in which we cover issues related to model lifecycle management, vetting (or verify your model's accuracy), model integration and using the models for more than just documentation.