The Matrix

The data governance discipline, the Master Data Management (MDM) discipline and the data quality discipline are closely related and happens to be my fields of work as told in the post Data Governance, Data Quality and MDM.

Every IT enabled discipline has an element of understanding people, orchestrating business processes and using technology. The mix may vary between disciplines. This is also true for the three above-mentioned disciplines.

But how important is people, process and technology within these three disciplines? Are the disciplines very different in that perspective? I think so.

When assigning a value from 1 (less important) to 5 (very important) for Data Governance (DG), Master Data Management (MDM) and Data Quality (DQ) I came to this result:

The Matrix

A few words about the reasoning for the highs and lows:

Data governance is in my experience a lot about understanding people and less about using technology as told in the post Data Governance Tools: The New Snake Oil?

I often see arguments about that data quality is all about people too. But:

  • I think you are really talking about data governance when putting the people argument forward in the quest for achieving adequate data quality.
  • I see little room for having the personal opinion of different people dictating what adequate data quality is. This should really be as objective as possible.

Now I am ready for your relentless criticism.

Bookmark and Share

Data Quality X-mas Stories

Today is 2nd of December and time for the 2nd x-mas theme on this blog this year following up on the early yuletide post about The Shortcut to Lapland.

In a way it is not in line with a main subject on this blog being diversity to focus too much on Christmas as I know that many readers may have for example Eid, Diwali or Chinese New Year as the main days of celebration during the year.

To me The Holidays is much about having light in a time of year up north that else would be very dark and even depressive. When I am in Copenhagen I live on a cosy square called Gråbrødretorv (Grey Friars Market). In summertime the square is filled with outdoor seating. Not so much in the winter. But then there is a fir tree with lights on.

Gråbrødretorv2

Anyway there is lots of stuff in the x-mas theme you can relate to data quality. Some of the older ones on this blog were:

Bookmark and Share

The Multi-Domain Data Quality Tool Magic Quadrant 2014 is out

Gartner, the analyst firm, has a different view of the data quality tool market than of the Master Data Management (MDM) market. The MDM market has two qudrants (customer MDM and product MDM) as reported in the post The Second part of the Multi-Domain MDM Magic Quadrant is out. There is only one quadrant for data quality tools.

Well, actually it is difficult to see a quadrant for product data quality tools. Most data quality tools revolves around the customer (or rather party) domain, with data matching and postal address verification as main features.

For the party domain it makes sense to have these capabilities deployed outside the MDM solution in some cases as examined in the post The place for Data Matching in and around MDM. And of course data quality tools are used in heaps of organizations who hasn’t a MDM solution.

For the product domain it is hard to see a separate data quality tool if you have a Product Information Management (PIM) / Product MDM solution. Well, maybe if you are an Informatica fan. Here you may end up with a same branded PIM (Heiler), Product MDM (Siperian) and data quality tool (SSA Name3) environment as a consequence of the matters discussed in the post PIM,  Product MDM and Multi-Domain MDM.

What should a data quality tool do in the product domain then? Address verification would be exotic (and ultimately belongs to the location domain). Data matching is a use case, but not usually something that eliminates main pain points with product data.

Some issues that have been touched on this blog are:

Anyway the first vendor tweets about the data quality tools quadrant 2014 is turning up, and I guess some of the vendors will share the report for free soon.

Magic Quadrant for Data Quality Tools 2014

Update 3rd December: I received 3 emails from Trillium Software today with a link to the report here.

Bookmark and Share

PIM, Product MDM and Multi-Domain MDM

Over on the Informatica Perspectives blog Monica McDonnell of Informatica seems to be determined to separate Product Information Management (PIM) and Product Master Data Management (Product MDM) as we now have the second attempt in the post PIM is not Product MDM Part 2.

I can easily see the reason for this quest for Informatica, as Informatica will very much like to position the Heiler acquisition as an Informatica Multi-Domain MDM aware PIM solution as mentioned in the post MDM Aware MDM Solutions.

There will always be pros and cons for having capabilities delivered in smaller best of breed packages opposed to in larger integrated packages. On the MDM market the vendors pitch their offerings according to how they got there. SAP is using Hybris as an eCommerce focused PIM add-on to SAP. On the other hand Stibo Systems and Riversand have been adding MDM to PIM and now adds Multi-Domain to MDM as reported in the post The second part of the Multi-Domain MDM Magic Quadrant is out.

In the PIM / Product MDM realm we have several other considerations on how to address different disciplines with technology support. An important capability within PIM is Digital Asset Management (DAM) as described in the post Digital Assets and Product MDM. DAM can be a separate application or part of PIM / Product MDM. Technology support for Data Governance could also come separately as reported in the post Data governance tools: The new snake oil?

QuadrantNow, back to PIM versus Product MDM. I’m not sure it is wise to divorce these two. It seems to be a kind of back looking exercise. I would like to marry them as part of looking forward in a multi-domain MDM world. To catch up on Monica’s arguments PIM has been much about the sell-side of things. I think we should be better at integrating the buy-side and the sell-side of Product MDM / PIM as examined in the post An Alternative Multi-Domain MDM Quadrant.

Bookmark and Share

Digital Assets and Product MDM

Digital Asset Management (DAM) solutions are often seen working beside or within product Master Data Management (MDM) solutions.

I guess I might have been some of the first folks working with relating digital assets and enterprise software. That was in the early 90’s when I worked with Wang Laboratories that was a pioneer in handling digital images in the IT world.

Digital assets today are typically stored as files of well-known types as jpg, png and pdf. Within product MDM they are images of products, installation guides, safety handling sheets and so on.

The rise of the multi-channel theme has emphasized the importance of digital asset management capabilities.

Data quality is as ever an imperative. Related to well-known data quality dimensions that for example for product images means:

  • Uniqueness: You want to use the same image in your printed catalogue and on your web shop.
  • Accuracy: The image must show the described product and not something else.
  • Consistency: The images for similar products should have the same style.
carlsberg six pack
A random product image

Many of the leading product MDM solutions were born in the printed catalogue era. Here the product image was the dominant digital asset. Adding eCommerce and mCommerce means that a lot more digital asset types must be handled.

Usually we see digital assets as unstructured, or sometimes semi-structured, data. Therefore we often relate structured keywords in order to control the digital assets.

Digital assets should flow and should be controlled in the eco system of manufacturers, distributors, retailers and end users of the products. Here we have the same issues as with the structured product attributes. Giving the foreseeable steep increase in the volume, velocity and variety of the digital assets used as part of product MDM, we must drastically improve our capability in Sharing Product Master Data.

Bookmark and Share

The Place for Data Matching in and around MDM

Data matching has increasingly become a component of Master Data Management (MDM) solutions. This has mostly been the case for MDM of customer data solutions, but it is also a component of MDM of product data solutions not at least when these solutions are emerging into the multi-domain MDM space.

The deployment of data matching was discussed nearly 5 years ago in the post Deploying Data Matching.

Neural NetworkWhile MDM solutions since then have been picking up on the share of the data matching being done around it is still a fairly small proportion of data matching that is performed within MDM solutions. Even if you have a MDM solution with data matching capabilities, you might still consider where data matching should be done. Some considerations I have come across are:

Acquisition and silo consolidation circumstances

A common use case for data matching is as part of an acquisition or internal consolidation of data silos where two or more populations of party master data, product master data and other important entities are to be merged into a single version of truth (or trust) in terms of uniqueness, consistency and other data quality dimensions.

While the MDM hub must be the end goal for storing that truth (or trust) there may be good reasons for doing the data matching before the actual on-boarding of the master data.

These considerations includes

The point of entry

The MDM solution isn’t for many good reasons not always the system of entry. To do the data matching at the stage of data being put into the MDM hub may be too late. Expanding the data matching capabilities as Service Oriented Architecture component may be a better way as pondered in the post Service Oriented Data Quality.

Avoiding data matching

Even being a long time data matching practitioner I’m afraid I have to bring up the subject of avoiding data matching as further explained in the post The Good, The Better and The Best Way of Avoiding Duplicates.

Bookmark and Share

Customer MDM Magic Wordles

The Gartner Magic Quadrant for Master Data Management of Customer Data 2014 is out. One place to get it for free is by using the Informatica registry style page offered in the Informatica communication here.

So, what is good and what is bad when looking for a MDM vendor if you are focusing on customer data right now?

Some words in the strengths assessment of vendors are:

Magic plus

Some words in the cautions assessment of vendors are:

Magic minus

Bookmark and Share

The Path to Multi-Domain MDM

Multi-Domain Master Data Management (MDM) is about dealing with master data in several different data domains as customer (or party), product, location, asset or calendar. The typical track today is starting in one domain. There are many, even contradicting, good reasons for that.

Depending on in what industry vertical you are the main pain points that urges you to start doing MDM belongs to either of the MDM domains. Customer MDM is the most common one typically seen where you have a large number of customer records in your databases. We see starting with product MDM in organizations with many products in the databases. This is for example the case for large retailers and distributors.

Master DataIt can be other domains as well. One example from a MDM conference I recall is that Royal Mail in the UK started with the calendar domain. Besides that this domain had pain points for that organization a reason to do that was to start small before taking on the big chunks.

Even though you start with one domain, you must think about the end state. One thing to consider multi-domain wise is the data governance part, as you will not come out well if you choose different approaches to data governance for each master data domain. Of course, the technology part is there too. Choosing a solution that eventually will take you all the way is appealing to many organizations looking for a MDM platform.

Another approach to multi-domain MDM can be through what I know at least one MDM tool vendor calls Evolutionary MDM™. But we can call it other things. Agile or lean MDM for example. Using that approach you do not solve everything within one domain before going on to the next one.

It is about eliminating as many pain points as possible in the shortest feasible time-frame.

Bookmark and Share

Post No. 666

666This is post number 666 on this blog. 666 is the number of the beast. Something diabolic.

The first post on my blog came out in June 2009 and was called Qualities in Data Architecture. This post was about how we should talk a bit less about bad data quality and instead focus a bit more on success stories around data quality. I haven’t been able to stick to that all the time. There are so many good data quality train wrecks out there, as the one told in the post called Sticky Data Quality Flaws.

Some of my favorite subjects around data quality were lined up in Post No. 100. They are:

The biggest thing that has happened in the data quality realm during the five years this blog has been live is probably the rise of big data. Or rather the rise of the term big data. This proves to me that changes usually starts with technology. Then we after sometime starts thinking about processes and finally peoples roles and responsibilities.

Bookmark and Share

MDM Aware MDM Solutions

The concept of MDM aware applications have been around for some time. What the Master Data Management establishment, including yours truly, is hoping for, is that applications like CRM, ERP and other systems will start to utilize the master entities in MDM solutions instead of having their own more or less useful data models within data silos around master data entities as parties, products, locations and assets as well as exploiting other good structures and services in the MDM realm.

puzzleBut what about MDM solutions themselves? Are MDM solutions that smug that they don’t take in good capabilities from other MDM solutions?

One reason to do so is if a MDM vendor have several MDM solutions to offer. An example of that I experienced recently was when attending the Informatica MDM day for EMEA in London the other day. Informatica has recently acquired the Product MDM specialist firm Heiler and has therefore two MDM solutions to offer to the market. It has been too early for the newest version 10 of the general Informatica MDM solution to embrace the Heiler solution, so what I learned from one of the good now Informatica folks was that the Heiler solution is becoming MDM aware – at least aware of the Informatica MDM version 10 solution I guess.

On another front I’m working with the iDQ™ MDM Edition. Here we do have a default data model for party master entities, but we are not that smug that we can’t be aware of other MDM solutions and their capabilities in a given IT landscape. Even in the party domain.

Bookmark and Share