A flexible data model as the foundation for the PIM system is invaluable

It's worth taking a look beneath the surface

Information systems rely on a database as their foundation. This is naturally also the case with Product Information Management (PIM). It is generally said that databases have a “lifespan” at least three times as long as the software itself - that is, the user interface and programs. The database is the foundation, the engine; major changes - if they’re even technically possible - are very time-consuming. For the software manufacturer, this means the database should be developed with great care, and for the user, it means it’s worth taking a look beneath the surface. Over the course of my career, I have seen on multiple occasions that software companies have given up, in part because they did not design the database optimally, and the transition entailed immense effort.

The "Database Chief"

When I first encountered data models in a real-world setting, I have to admit it was a hassle. As a young software developer, I wanted to quickly build a great user interface packed with features - but I was initially held back by the database administrator. I “had” to go through all the data structures with him, field by field, and of course there were plenty of questions about the whys and wherefores. The result was visualized in a diagram (“Entity-Relationship Diagram”), and then I had to wait until the data model was implemented in the database and rolled out.

As the project progressed, I came to understand just how sensible this approach was: All the other developers thus had a predefined, robust model and could use data consistently without needing any additional loops.

I took away two key insights:

1.) Having one person centrally responsible for the database is essential—I eventually came around to that idea.

2.) The tedious process of creating the fields manually should be avoided; I wanted to improve that and make it more flexible.

The Flexible Data Model

What does “flexible data model” mean?

First and foremost, “flexible” means that the application can make extensions on its own—figuratively speaking, without the “database administrator.” Therefore, a kind of “metadata model” is needed to extend fields (“attributes”), structures (“tables”), and relationships (“relations”):

• Fields store content.
  In the context of PIM, for example, texts and translations, features (e.g., numbers), images, documents, and videos. Typical extensions include the need for a new attribute, a new text category, or a new image category. Users should be able to do this easily on their own—with no limit on the number of new fields. As soon as a new field is created, it should be immediately visible everywhere: in data maintenance, in interfaces, in print production, and in provision of data of all kinds. By the way, I had sketched out the basic idea for the flexible attribute model with a friend at a bar and then tested it in Access (it worked like a charm :-).
• Structures are typically represented as tree structures. Needless to say, these must be easily expandable and (unrestricted) customizable in terms of content. In the context of PIM, these are necessarily the maintenance structure for products as well as the output structures for websites, shops, portals, and print media. However, other, more complex structures can also usefully complement the PIM, such as a configuration structure as the basis for configurators; structures for standard classifications like ECLASS and ETIM; structures for mapping XML formats like BMEcat; and structures for managing cutting data for tools. And so on. The basic idea behind our flexible structure model came from our first database manager; the so-called “structure object,” a term he coined, is the linchpin. This approach also allows for the illustration of customer-specific, individual scenarios (ready for release!), which our customers greatly appreciate. Of course, the same principle applies as described above for fields: New structures should be immediately visible everywhere.
• Relationships are represented as references. That is actually the main purpose of the database: to create content once and reuse it frequently. Of course, this is also possible without a database—but only as a copy, i.e., without a link to the original content. And copies take on a life of their own, as we all know. In the simplest case, relationships can involve linking images, documents, and texts to items, product groups, etc. Or links to accessories, replacement parts, and parts lists. In the case of parts lists, so-called reference attributes—such as item number and quantity—also play a role; and in the case of packaging, dimensions, weight, EAN, etc., are relevant. A flexible data model should be freely configurable with regard to such relationships.

Flexibility is evident in all aspects

In addition to the points described above, you should look for a flexible PIM system overall. Pay particular attention to the expandability of these aspects: languages and countries, number formats and units, catalogs and assortments, price lists and price attributes, text formats, and special characters.
Flexibility is also evident in downstream programs: How flexible is the provision of data? Can API services and data exports for shops, websites, and other systems be easily customized? How flexible is Printengine—that is, can layout templates be easily customized and expanded for use in InDesign, or is programming knowledge (“scripting”) required?

The Challenge

I won’t deny that a “meta data model” of this kind is very demanding. After all, evaluation becomes more complex because the meta data must be processed first. This dilemma must, of course, be resolved, because without performance, flexibility is meaningless. The good news: It’s doable!

The configuration of the data model also requires an interface that guides the PIM administrator; any changes made must be immediately visible in all programs.

Conclusion

Check the (unlimited) extensibility of the data model—both in terms of content and structure. It’s a bit like the engine of a car. Don’t hesitate to look under the hood—that is, beneath the user interface. After all, the user interface is constantly changing, but the data model itself is very long-lasting. And only with a flexible data model will you be well-prepared for the future. And finally, one more recommendation: Ask how many databases are used for the entire system solution. The answer should be: a single database. Otherwise, having more than one database creates copies, redundancies, inconsistencies, and - above all - unnecessary work.