Data Architecture

MDM vs ADM

Henrik Gabs Liliendahl4 Comments

The term Application Data Management (ADM) has recently been circulating in the Master Data Management (MDM) world as touched in The Disruptive MDM List blog post MDM Fact or Fiction: Who Knows?

Not at least Gartner, the analyst firm, has touted this as one of two Disruptive Forces in MDM Land. However, Gartner is not always your friend when it comes to short, crisp and easy digestible definitions and explanations of the terms they promote.

In my mind the two terms MDM and ADM relates as seen below:

ADM MDM.png

So, ADM takes care of a lot of data that we do not usually consider being master data within a given application while MDM takes care of master data across multiple applications.

The big question is how we handle the intersection (and sum of intersections in the IT landscape) when it comes to applying technology.

If you have an IT landscape with a dominant application like for example SAP ECC you are tempted to handle the master data within that application as your master data hub or using a vendor provided tightly integrated tool as for example SAP MDG. For specific master data domains, you might for example regard your CRM application as your customer master data hub. Here MDM and ADM melts into one process and technology platform.

If you have an IT landscape with multiple applications, you should consider implementing a specific MDM platform that receives master data from and provides master data to applications that takes care of all the other data used for specific business objectives. Here MDM and ADM will be in separated processes using best-of-breed technology.

Product Data Completeness

Henrik Gabs LiliendahlLeave a comment

Completeness is one of the most frequently mentioned data quality dimensions as touched in the post How to Improve Completeness of Data.

ChecklistWhile every data quality dimension applies to all domains of Master Data Management (MDM), some different dimensions apply a bit more to one of the domains or the intersections of the domains as explained in the post Multi-Domain MDM and Data Quality Dimensions.

With product master data (or product information if you like) completeness is often a big pain. One reason is that completeness means different requirements for different categories of products as pondered in the post Hierarchical Completeness within Product Information Management.

At Product Data Lake we develop a range of cloud service offerings that will help you improve completeness of product data. These are namely:

  • Measuring completeness against these industry standards that have attribute requirements such as eClass and ETIM
  • For manufacturers measuring completeness against downstream trading partner requirements (if not fully governed by an industry standard).
  • For merchants measuring incoming completeness when pulling from merchants.
  • Measuring against completeness required by marketplaces.
  • Transforming product information to meet conformity and thereby ability to populate according to requirements
  • Translating product information in order to populate attributes in more languages
  • Transferring product information by letting manufacturers push it in their way and letting merchants pull it their way as described in the post Using Pull or Push to Get to the Next Level in Product Information Management.

Product Information on Demand

Henrik Gabs Liliendahl1 Comment

Video on demand has become a popular way to watch television series, films and other entertainment and Netflix is probably the most known brand for delivering that.

The great thing about watching video on demand is that you do not have to enjoy the service at the exact same time as everyone else, as it was the case back in the days when watching TV or going to the movies were the options available.

At Product Data Lake we will bring that convenience to business ecosystems, as the situation today with broadcasting product information in supply chains very much resembles the situation we had before video on demand came around in the TV/Movie world.

As a provider of product information (being a manufacturer or upstream distributor), you will push your product information into Product Data lake, when you have the information available. Moreover, you will only do that once for each product and piece of information. No more coming to each theatre near your audience and extensive reruns of old stuff.

As a receiver of product information (being a downstream distributor, reseller or large end user), you will pull product information when you need it. That will be when you take a new product into your range or do a special product sale as well as when you start to deal with a new piece of information. No more having to be home at a certain time when your supplier does the show or waiting in ages for a rerun when you missed it.

Learn more about how Product Data Lake makes your life in Product Information Management (PIM) easier by following us here on LinkedIn.

Product Data Lake

 

Three Major Sectors within Product Information Exchange

Henrik Gabs LiliendahlLeave a comment

When working with Product Information Management (PIM) and not at least with product information exchange (product data syndication) between trading partners, I have noticed three major sectors where the requirements and means differs quite a bit.

These sectors are:

  • Food, beverage at pharmaceuticals: These are highly regulated sectors where the rules for taxonomy, completeness and exchange formats are advanced. Exchange standards and underpinning services as GS1/GDSN are well penetrated at least for basic data elements among major players. This sector counts for circa 1/6 of the world trade.
  • Fashion, books and mainstream electronics: The products within this sector can be described with common accepted taxonomies and do not differ that much though there certainly are room for more common adhered standards in some areas. The trade here is becoming more penetrated by marketplaces with their specific product information requirements. This sector counts for circa 1/6 of the world trade.
  • The rest (including building materials, special electronics, machinery, homeware): This is a diverse segment of products groups and the product groups themselves are diverse. The requirements for product information completeness and other data quality dimensions are overwhelming and the choice of standards are many, so most often two trading partners will be on different pages. This sector counts for circa 2/3 of the world trade.

Note: Automotive (vehicles) is a special vertical, where the main products (for example cars) resembles mainstream electronics and all the spare parts resembles special electronics. Some retailers (like department stores) covers all sectors and therefore need hybrid solutions to their product information exchange handling challenges.

The main drivers for better product information handling are compliance – not at least within food, beverage and pharmaceuticals – and self-service purchasing (as in ecommerce), where the latter has raged many years within fashion, books and mainstream electronics and now also is raising in more B2B (business-to-business) biased product groups as building materials, special electronics and machinery.

Learn more about how to tackle these diverse needs in product information exchange in the article and discussion about Product Data Lake.

segments.png

Embracing Standards versus Imposing Standards

Henrik Gabs LiliendahlLeave a comment
When working with Product Information Management (PIM) and the recurring challenges in exchanging product information between trading partners the idea about everyone adhering to the same standard is a tempting idea.

This idea is also governing the many product data pools around. However, there are some serious considerations against this idea, namely:

  • Being on the same standard and not to say on the same version within your business ecosystem is quite utopic (being that within your own organization is hard enough).
  • It is not desirable to have the same product information as your competitors if you are going to compete on other factors than price.
In my eyes it is a better idea to forget about imposing a rigid standard for everyone and instead embrace the many available standards for product information where your organization utilize those being best for you at the given time and your various trading partners utilize those being best for them at a given time.

The solution for that is Product Data Lake.

Sell more Reduce costs

Why it is not a Product Data Warehouse, but a Product Data Lake

Henrik Gabs LiliendahlLeave a comment

There is a need for a new solution to sharing product information between trading partners. Product Data Lake is that new solution. Using the term data lake as a part of the name for the solution is very deliberate. Here is why:

Volume

When setting up a warehouse, and a data warehouse, you have to estimate the storing size and the throughput. There will be a limit to how much data you can store and how much data you can upload and download within a given period.

Our vision is that Product Data Lake will be the process driven key service for exchanging any sort of product information within business ecosystems all over the world, with the aim of optimally assist self-service purchase of every kind of product.

In order to achieve that vision, we need to be able to scale up drastically. Therefore, we use a document-oriented database called MongoDB to store product information.

Even if you choose to implement a Product Data Lake instance for a single business ecosystem, you will benefit from the high scalability.

Velocity

Business ecosystems changes all the time. You need to rapidly be able to adapt your data management, not at least when it comes to exchanging product information.

Swapping trading partners is one thing. That often means dealing with other product information requirements and opportunities and adhering to other standards.

We will also see business ecosystems in new shapes in the future. There will be fewer nodes between manufacturers and point-of-sales and point-of-sales will more likely be online marketplaces.

However, the changes will not happen as a big bang but in varying pace for each industry, geography and organization.

The rigid consensus structure of a data warehouse, and product information exchange solutions that resembles a data warehouse, will not cope with that change. The data lake concept, in the form of Product Data Lake, will.

In Product Data Lake you as a provider upload product information in your structure and format and you as a receiver download in your structure and format. The linking and transformation takes place inside Product Data Lake using linked metadata.

Variety

While everyone agrees that a common standard for all product information is the best answer we must on the other hand accept, that using a common standard for every kind of product and every piece of information needed is quite utopic. We haven’t even a common uniquely spelled term in English for standardization/standarisation.

Also, we must foresee that one organization will mature in a different pace than another organisation in the same business ecosystem.

These observations are the reasons behind the launch of Product Data Lake. In Product Data Lake we encompass the use of (in prioritized order):

  • The same standard in the same version
  • The same standard in different versions
  • Different standards
  • No standards
Learn about some of these standards in the post Five Product Classification Standards.
big data pdl.png

The Old PIM World and The New PIM World

Henrik Gabs LiliendahlLeave a comment

Standoff both sides narrow

Product Information Management (PIM) is challenged by the fact that product data is the kind of data that usually flows cross company. The most common route starts with that the hard facts about a product originates at the manufacturer. Then the information may be used on the brand’s own website, propagated to a marketplace (online shop-in-shop) and propagated downstream to distributors and merchants.

The challenge to the manufacturer is that this represent many ways of providing product information, not at least when it comes to distributors and merchants, as these will require different structurers and formats using various standards and not being on the same maturity level.

Looking at this from the downstream side as a merchant you have the opposite challenge. Manufacturers provide product information in different structurers and formats using various standards and are not on the same maturity level.

Supply chain participants can challenge this in a passive or an active way. Unfortunately, many have chosen – or are about to choose – the passive way. It goes like this:

  • As a manufacturer, we have a product data portal where trading partners who wants to do business with us, who obviously is the best manufacturer in our field, can download the product information we have in our structure and format using the standards we have found best.
  • As a merchant we have a supplier product data portal where trading partners who wants to do business with us, the leading player in our field, can upload the product information we for the time being will require in our structure and format using the standard(s) we have found best.
  • As a distributor, you could take both these standpoints.

This approach seems to work if you are bigger than your trading partner. And many times, one will be bigger than the other. But unless you are very big, you will in many cases not be the biggest. And in all cases where you are the biggest, you will not be a company being easy to do business with, which eventually will decide how big you will stay.

Using (often local) industry product data hubs is a workaround, but the challenges shines through and often it leads to that everyone will only benefit from what anyone can do and still calls for many touch points when doing business internationally and across several product data groups.

The better way is the active way creating a win-win situation for all trading partners as described in the article about Product Data Lake Business Benefits.

Data Lakes in Business Ecosystems

Henrik Gabs LiliendahlLeave a comment

The concept of a data lake has until now mainly been used to describe how data gathered by a given organization can be organized in order to provide for analytical purposes. The data lake concept is closely tied to the term big data, which means that a data lake caters for handling huge volumes of data, with high velocity and where data comes in heaps of varieties. A data lake is much more agile than data marts and data warehouses, where you have to determine the purpose of the use of data beforehand.

In my eyes the idea about that every organization should gather all the data of interest behind its own firewall does not make sense. Some data will for sure be only for eyes of people behind the corporate walls. Here you should indeed put your private data into your own data lake. But a lot of data are common known data that everyone should not spend time on collecting and eventually cleansing. Here you should collaborate within your industry or other sphere around data lakes for public data.

Perhaps most importantly you should share data lakes with other members of your business ecosystem. You probably already do share data within business ecosystems with your trading partners. Until now such sharing has resembled the concepts of data marts and data warehouses being very purpose specific exchanges of data build on common beforehand understood standards for data.

Right now I am working on a cloud service called the Product Data Lake. Here we host a data lake for sharing product data in the business ecosystems of manufacturers, distributors, merchants and large end users of product information. You can join our journey by following us here on LinkedIn at the Product Data Lake LinkedIn Company Page.

bridge into lake.png

How MDM Solutions are Changing

Henrik Gabs LiliendahlLeave a comment

When Gartner, the analyst firm, today evaluates MDM solutions they measure their strengths within these use cases:

  • MDM of B2C Customer Data, which is about handling master data related to individuals within households acting as buyers (and users) of the products offered by an organisation
  • MDM of B2B Customer Data, which is about handling master data related to other organizations acting as buyers (and users) of the products offered by an organisation.
  • MDM of Buy-Side Product Data, which is about handling product master data as they are received from other organisations.
  • MDM of Sell-Side Product Data, which is about handling product master data as they are provided to other organisations and individuals.
  • Multidomain MDM, where all the above master data are handled in conjunction with other party roles than customer (eg supplier) and further core objects as locations, assets and more.
  • Multivector MDM, where Gartner adds industries, scenarios, structures and styles to the lingo.

QuadrantThe core party and product picture could look like examined in the post An Alternative Multi-Domain MDM Quadrant. Compared to the Gartner Magic Quadrant lingo (and the underlying critical capabilities) this picture is different because:

  • The distinction between B2B and B2C in customer MDM is diminishing and does not today make any significant differentiation between the solutions on the market.
  • Handling customer as one of several party roles will be the norm as told in the post Gravitational Waves in the MDM World.
  • We need (at least) one good MDMish solution to connect the buy-sides and the sell-sides in business ecosystems as pondered in the post Gravitational Collapse in the PIM Space.

Who is Behind with GDPR?

Henrik Gabs Liliendahl4 Comments

The answer to the question about who is behind with EU General Data Protection Regulation (GDPR) readiness is in short:

  • A lot of companies
  • A lot of governments

When following the vibe around getting prepared for GDPR, and from my own involvement at clients, there is no doubt about that time is short and that not every company (well, probably only a few companies) within the European Union will be 100 % ready on 25th May 2018 and this also counts for those outside EU who is targeting EU citizens or processing personal data from the EU.

However, most EU governments are not any better. According to a recent communication from the EU only two Member States (Germany and Austria) have adopted the necessary national legislation. And from own experience I can tell that the late incoming of the national legislation does not help in getting the details ready for 25th May.

Some areas where national legislation is important were discussed in the post Where GDPR Still Becomes National. In my eyes, the remaining governments do not set an example for companies who are struggling with this (else justified) extra work.

GDPR adoption.png
What Brussels says 24th January 2018