Introduction to MDM and PIM systems illustrated by Akeneo and Pimcore examples

A classic MDM-system is a system that is aware of different data sources and is responsible for the data quality, i.e., contains the so-called Golden Record. For example, there are differences in the customer information that your sales offices, an online store, and your marketing services have at their disposal. An MDM system can standardize all addresses and client names, identify client records that refer to the same client, and correct errors using different algorithms.

MDM systems manage different data areas, which are usually called domains (the Clients domain, the Products domain, etc.).

Nowadays, it is safe to say a PIM system as an MDM system for the Products domain.

An MDM system provides a centralized location for change validators, integrations with other systems, and the rules according to which this information is uploaded to other systems.

All the attributes, the most comprehensive information about each entity – everything is stored in MDM.

It is much easier to understand the essence of MDM systems if we first consider PIM systems as an example. Therefore, we will discuss them in more detail down below.

PIM systems allow you to bring together all information from operators, photographers, suppliers, as well as different product rules. PIM systems are used for managing different product representations on marketplaces and in social networks.

PIM systems usually provide an opportunity to configure a product status ("Validation by manager", "Ready for publication", etc.) and have tools for mass product processing (quick uploads from an XLS file, updating a common attribute for a product group etc.).

The most advanced PIM systems include DAM system (or PLM system) functions – management systems for files and images that can have their own attributes.

This means that images used as an attribute to a certain product can have their own attributes, for example, Side Image or Certification. This image is not simply indicated as an attribute – it is stored in a specific catalogue, it can be reused, and there can be a separate workflow for it ("being retouched", "outdated", "to be remade").

It helps simplify all business processes and get rid of unnecessary information in other sources. For example, is it necessary to store website images and the website category in a system not specialised for it?

Let's consider the two systems that we usually use for the integration: Akeneo and Pimcore systems. In terms of the tech stack, they are very similar: it's PHP / Symfony 4, MySQL, and Elasticsearch. However, in terms of approach, these are two absolutely different systems.

Pimcore is an MDM system. Even though there is a "PIM" prefix, de facto it only provides a layout that allows working with products. There is also a CRM (a layout that allows working with clients), plus you can create any other entities that are necessary for effectively solving business tasks.

This does not mean it has weak PIM functionality. On the contrary, it is quite powerful, and there is also an opportunity of data deduplication.

I just want to emphasize that by default Pimcore is not designed solely for product information management. It explains the high complexity of configuring the system and its extreme versatility (both in terms of attributes and in terms of the API for these entities).

Unlike the versatile Pimcore, Akeneo is a classic PIM system, a highly specialized tool.

There are three product editions: Enterprise, Growth, and Community. In terms of architecture, it is a single system (one core) with various sets of modules. The Enterprise edition has more modules; most of them are used for product management in big companies (with a need for approvals, complex access rights, a complex hierarchy of operators etc.).

In contrast to Pimcore, there is no complex attribute hierarchy in Akeneo. Attributes are classified into attributes, attribute groups, and families. There is no possibility to create an abstract entity you can inherit from. For example, you cannot create Furniture category with the corresponding attributes, and then enrich it with Sofa and Table subcategories, which will be added as Furniture attributes.

Imagine that you are a mobile service provider. You have a price breakdown with multiple options and particularities for different country regions or countries. Some tariffs are not available in certain regions. In this particular case pricing becomes a product property (price is not always a product property – it is usually the property of a sales channel).
Pricing is not an easy task for you, and it is important to know and control all the factors affecting the price.

Another example: you make sofas. You can use different upholstery fabrics of different colors and textures. Sofas' sizes, recliner mechanisms, and armrest material are also different. These differences are not just the product properties – they are connected in a certain way: sofas of some price categories are only made using certain upholstery fabric and come in a limited number of colors, whereas other designs have more options.

Now let's look at how Akeneo and Pimcore systems help manage information for such composite products.

Akeneo supports a planar data model (with slight differences: the Enterprise edition allows for the composite attributes, i.e. attributes can have their own attributes).

So, you basically have to scale the Akeneo system with a special configurator – developers write a module for managing a complex data hierarchy in a planar Akeneo structure.

A composite attribute in the Akeneo Enterprise edition and Pimcore system is an attribute that can have its own attributes. For example, the Color attribute has the name, HEX and CMYK color codes and an image, whereas the Fabric attribute has the name of the fabric and the recommendations for washing or cleaning.

In the Pimcore system, this task is solved with an inbuilt interface: any class can be expanded, that, in its turn, can also be expanded. Relationships, including many-to-many, composite or calculated, can also be attributes.

The following cases perfectly illustrate the Akeneo and Pimcore systems operation: a company has a base product sold at a basic price (for example, a basic sofa model with a particular upholstery fabric), and as you change the configuration, the price has to be automatically changed as well (a sofa with a different upholstery would be more expensive), and the process has to comply with the set rules (there are several categories of fabric, and the price increases by £2 per running meter as you move to the next category).

The interface for attributes configuration in the Akeneo PIM system looks as follows:

And that's the Pimcore:

Pimcore is a flexible, convenient and multifunctional MDM system. Let's take a closer look at its features and discuss which of them are also provided in Akeneo.

Both Pimcore and Akeneo systems ensure the connectivity and high quality of various data sets: structured and unstructured, internal and external. You can compare, validate, and standardize information so that you always have up-to-date and accurate data for operations. For example, you can enrich product information using data from other websites and cloud services. From the data quality management perspective, Pimcore has a better architecture, whereas Akeneo ensures a better visual representation.

These systems also allow you to format various types of datasets based on industry standards, business rules, unique tests, meta-data, and machine learning. You can change data values according to the domain constraints, data integrity constraints, or other business rules.

Sometimes you need to navigate products through statuses – just as a task tracker controls a task implementation. For example, the product status sequence can be as follows: New → Reviewed by a copywriter → Reviewed by a brand manager → Published.

This feature is provided in both Akeneo (Enterprise) and Pimcore systems.

It is quite possible that while navigating a product between the statuses, the brand manager notices some inaccuracies in product attributes. If that's the case, they can leave a comment and submit the product for improvement, and the operator will see the need for corrections. Or another option: sometimes you need to write a validator.

The status can be connected with the launch of the product data import or export.

The Pimcore system recognizes the concept of validators and operation cancellation rules. For example, a product cannot be published if its price hasn't been updated for more than 30 days; you can't submit a product with the status for validation Blocked, and so on.

These validations can be calculated (including the opportunity of sending a request to an external system to make a decision).

User Interface for configuring Pimcore Workflow looks as follows:

Any PIM system – even without DAM functionality – provides an opportunity of uploading product photos.
However, sometimes your files have to constitute separate entities (for example, photographers only take a photo without specifying the SKU, or we have to use the same photo for different products). Then you need a DAM system. It used to be called PCM, and, if I remember correctly, the name comes from SAP. But now it's just DAM.

A DAM system is a system for storing files (images, documents) that have their own attributes. Sometimes, we have to know that it's not just an SKU photo, but a side photo in particular. Not just define a document as a certificate scan, but understand when it expires. It means the file itself is accompanied by lots of meta-data, which can be connected with products (for example, you can not publish products if their certificate has expired).

All these features can be configured in the DAM system.

As a rule, the DAM system is connected right to the systems that are responsible for content generation (so that you can use the standard NFS or some other network protocol for accessing the folder), and content managers use DAM files for their products (assign photos and certificates to specific SKUs).

At the same time, if we need to send all the certificates at once, we can make it with a single click, even provide a shared download link, instead of sending large files by mail. And only the certificates with the valid expiration date will be uploaded.

The DAM functionality is included in both Pimcore and Akeneo systems, in former – Enterprise edition only, although you can connect any open source DAM to the Community, or even write your own one, if you have relatively modest requirements.

Pimcore also provides very basic document and image editing functions (via third-party libraries).

Versioning helps you determine when, how, and by whom a product was edited (GIT for products).

It allows reverting to the previous version, submitting a revised version for approval, and shows that in case product updates were made to a single attribute that is only relevant, let's say, for the website, then the updates should only be uploaded to the website, and there is no need to inform others about the changes.

These features are available in Akeneo Community (but in a reduced form), Akeneo Enterprise, and in Pimcore.

Sometimes you have to know that not all the attributes required for a particular channel are filled in (by channel we mean a data recipient: a website, a marketplace, an ERP, etc.).

And sometimes you need this information not only in the context of a sales channel, but in the context of a product group. Akeneo Enterprise allows you to monitor data quality and completeness in a group in the context of sources – the feature is called Teamwork Assistant. For example: the autumn-winter season is about to start and we single out all the relevant products into a separate group. As a result, we see the percent degree of channel completeness with the group filter applied, and it is easier for us to track the progress.

In addition to custom import and export profiles, both systems (Akeneo and Pimcore) have a slightly different approach to data.

An out-of-the-box Pimcore provides flexible management of external tables directly from the interface for all kinds of entities (attributes, products, customers). You can upload a table document directly to the interface and specify what fields are to be added and where.

Akeneo is designed for working with products and has a data enrichment service (Franklin), as well as relatively simple import and export mechanisms (you can set up an import profile and upload a table). Franklin collects product information from the Internet and combines it in a smart way correcting data discrepancies.

Sometimes you have to set up the product information enrichment by the enterprise manufacturer.

I think a good example would be a food delivery service that works with lots of suppliers, who submit product information separately. Internal users only confirm the information upload and check its correctness.

Akeneo Enterprise has a separate cloud service Onboarder for such tasks, whereas in Akeneo Community and Pimcore you can only use available access rights configuring them and providing selective access rights to the suppliers.

Nevertheless, it is more preferable to configure data import from their sources (and as a rule, such import is already available).

PXM (product experience management) system is a PIM system that can provide the necessary information to different marketing channels.

Whereas a classic PIM treats product information as a golden record (yes, products can have different localizations – language, etc. – but it will be the same set of attributes), the PXM system considers a product as a set of descriptions for different marketing channels.

Figuratively, if you produce water, you would use different positioning techniques for moms and for offices. The product is the same, but marketing is different.

Akeneo claims that its Onboarder and Franklin together with the PIM system itself constitute a full-fledged PXM. In fact, both Akeneo and Pimcore have similar interfaces for the actual marketing activity: these are product variations that can be connected either by relationships (Akeneo and Pimcore), or through inheritance (Pimcore).

If you receive EDI messages (for example, from a European manufacturer) and want to set up their automatic upload to the information system, you can't do without a system customisation.

Though the amount of relevant data is limited, that will be enough to fill in primary product information (which will then go through complex workflow enrichment).

The reasons are both a variety of EDI messages and their formats, and a relatively low need in such exchanges.

If your company has a microservices ecosystem, it might have issues with the product treatment.

Strictly speaking, you will not be able to manage Akeneo PIM business processes from your BPMS unless you implement additional Akeneo features. The situation is a bit less complicated for Pimcore system users due to the rich workflow access capabilities via API. However, we recommend that you do not integrate such business processes and treat PIM as a closed system with specific business processes of its own. The only thing you can do with such a system from other services is to use its API.

Sometimes business processes and products are very much connected. For example, when the product is tariffs of some mobile service provider that have complex business processes, but also very closely connected with the marketing campaign processes, time zones and the billing. In this case, it is better to manage products through Camunda Workflow automation and other associated interfaces.

Strictly speaking, modular systems (even the open source ones) are not the best option for complex and large-scale processes.

Another option is to develop a module for Akeneo or Pimcore systems so that the interfaces and validators are derived from Camunda or jBPM, and displayed in the PIM system. Of course, such a development will not be cheap, but it helps maintain the workflow transparency from BPMS and ensures a rich PIM interface.