GDSN  - What's Next?

Now that the GDSN community is in full swing of preparing for the update to Major Release 3, which is scheduled for May 2016, it's a good time trying to dare a glimpse into the future and wrap our minds around developments that, as we believe, are likely to become a focus of attention in master data synchronization over the next few years.

Notwithstanding the challenges and efforts ahead, Major Release 3 will be a big step forward. It provides many substantial improvements, some of which were long and eagerly yearned for, and moreover, we are convinced that it will open up the standard for broader adoption. So far, so good. But, what is next? If a standard doesn’t evolve, it’s dead. Thus, nobody should be surprised that there is room for improvement. The discussions that lead the way to Major Release 3 started many years ago, and meanwhile, new challenges came about that have not yet been addressed nor discussed, let alone solved.

These challenges arise from an overall need for greater agility and responsiveness in the supply chain which in turn demands the same from global data synchronization. Essentially, it all boils down to providing and processing

• more volatile data,
• more detailed and fine-grained data, particularly with more attributes,
• more consumer-targeted data,
• more interwoven and interdependent data,
• more data at an earlier stage of the product lifecycle,
• and more partially available or even premature data.

Moreover, these challenges get boosted by an increasing number of participants in the market, that all require access to product data, particularly

• more (and smaller) retailers,
• more verticals
• third-party logistics,
• e-commerce,
• search engines,
• mobile applications,
• and, before anything else, the end consumer.

So why do we think that the GDSN standard in its current form, even with Major Release 3, isn’t fit for these challenges? In business and in engineering there are often good reasons to do things exactly the way they're done, and surely one might be tempted to assume that this applies equally well to the GDSN. On the other hand, it’s occasionally a good idea to have a look beyond the horizon. After all, it is a certain fact that the GDSN community is not alone in its efforts to shuffle data back and forth. And if you look around, you’ll notice that the way synchronization is done in GDSN is not without alternatives. Of course, it’s a valid question to ask: Can’t we do it any simpler than with all that rigid and complicated choreography stuff?

But before we delve deeper into the present shortcomings of the GDSN, we should try to understand how it got there, and thus take a look at how it evolved historically. The GDSN was designed to pursue a “push-centric” messaging approach, where the relevant information is actively sent in the form of business messages. This approach got its roots in the EDI standards of the nineteen-eighties, namely in ANSI X12 and EDIFACT/EANCOM. These were mostly adopted for messaging schemas dealing with purchase orders (ORDERS) and invoices (INVOIC), where clearly a push-centric approach is legally advisable: Before an invoice can become due, it somehow must have been delivered. Similarly, a purchase order can only become binding after the supplier provably received it. In fact, if you need a certain level of guaranteed delivery, usually in the form of a confirmation receipt, then it is better to push the message to your business partner rather than to rely on them for pulling it. By the way, it is no surprise that in the aftermath of the greater adoption of EDI, an Internet-based transport protocol like AS2 evolved, which provides exactly such a kind of confirmation receipt, namely the MDN, on top of a push protocol.

There are several reasons, why the push-centric approach that was initially chosen for purchase orders and invoices, sometimes still makes perfect sense for master data synchronization. For example, when you deliver an update on a product item which is highly important for a retailer to know about, then, of course, you want to be able to prove that you did. In general, however, push-centric approaches tend to be stolid. Why? Because, when a sending party starts pushing a message, it cannot know the receiver’s most urgent demand, at least not at exactly that point in time.

This is what happens to a retailer in the GDSN when they submit an item subscription to the data pool where the pub-sub match results in hundreds of thousands of item notification messages, which is regularly the case when e.g. the subscription retrieves on a target market. The result is often a flood of messages jamming the line for hours or even days and there’s almost no chance of getting through with any other subscription during that time. If you urgently need the product data for another item at that point in time, you don’t have to be a genius to start dreaming of a URL where you could just download™ the desired item data instantaneously and on demand. Technically, what this dream is about is the ability to pull the information, hence a pull approach. And now you understand that the GDSN has implemented only the first half of a push-pull strategy. As they describe it perfectly well in this Wikipedia page: “On markets the consumers usually "pull" the goods or information they demand for their needs, while the offerers or suppliers "push" them toward the consumers.”

That’s why suppliers feel quite comfortable with the push-centric approach of the GDSN, and it’s also why the retailers feel the pain. We see it as inevitable that the GDSN needs to be supplemented with a pull approach. In other words, we believe that the GDSN needs to get its missing second half of the push-pull strategy. Recent ambitions of the GS1 like the “GTIN+ on the web” standard go exactly in that direction. “GTIN+ on the web” provides schemas for structured product information, very similar to the data structures in a GDSN item notification, but adhering to the rules of linked data. The crucial thing about linked data is, that every data object or “resource” as they call it, has its unique, permanent, and addressable location, namely a URL. Now with linked data, a product item or even a set of product items has the URL we dreamed of above, where you can just download the desired data from. It’s basically the idea behind the World Wide Web that we all know, where every page has a URL, just carried forward to the realm of information exchange between software systems.

In our opinion, it’s just a matter of “when”, not “if”, that data pools will pick up on these ideas.