Data Spaces are not enough – Part 1/2

Happy New Year everyone. Hope you had a relaxing holiday season and good start into 2025. My intent is to continue our journey into the world of sustainable supply chains, including some deep dives, from a business and technology perspective. I would appreciate if you could spread the word about this newsletter, so we can get a 4-digit number of subscribers this year :) Thank you!

I would like to start off the year with the topic of Data Spaces, a topic that I observed to be discussed especially in the context of scope 3 emissions. Thinking about it, I came to the conclusion, that to cover it in one article would make the article very long and as I try to keep the content of my articles to a digestible size, I thought splitting the topic into two articles might be appreciate by time-sensitive readers. Those that have more time to discuss the content of an article further, can of course do this in the comments or engage with me directly.

This two-part article intends to answer the question, if Data Space are enough to capture and exchange accurate and timely scope 3 emission data. My point of view is, that they are not enough, but let’s start with some basic facts and observations. What scope 3 emissions are to one supply chain partner are scope 1 or scope 2 emissions to another supply chain participant. Therefore, it is correct to state that everyone in the supply chains contributes to its scope 3 emissions, through their own scope 1 and 2 emissions. This is important to understand for the argument that Data Spaces are not enough in the context of scope x emissions, as we also need to look at scope 1 and 2 emissions that in aggregate make up the scope 3 emissions of a global supply chain.

Data Spaces for Exchange of Sustainability Data

When I talk about Data Spaces, I am talking about Data Spaces in the context of Industry 4.0, as defined by Plattform Industrie 4.0, being based on standards from organizations like Gaia-X and the IDSA. If you have never heard about them, please pause reading this article and do a little Google (Or Perplexity ;)) search before you continue. You only need to understand what those standards are, not reading them in order to understand the rest of this article ;)

You use Data Space to exchange your scope 1 and 2 emission data with other supply chain participants and also use them to receive scope 3 emission data from you supply chain partners. While Data Space are a great vehicle to exchange also, but not only, emission data in a standardized and secure way, we also need to look how to capture scope 1 and 2 data, which is something Data Space are not designed for.

Focusing on the exchange of data for a moment, the question is why we need Data Spaces in a Supply Chain. Are we not already exchanging data with supply chain partners digitally for decades now, even using standards like EDIFACT? Yes, we do and EDIFACT could certainly be extended to contain sustainability data, like CO2 emissions. So, the question is, why certain industries are creating new standards instead of expanding something that is a standard of the United Nations. I am sure that I am not aware of all the reasons as an observer, but having be exposed to standard development on an international and national level, I could image that the speed of developing standards and changing them, might have been a reason. From my involvement in the mining industry several years ago I remember that the mining companies complained a lot about the 5–10-year timeline to develop ISO standards for the industry. In the automotive industry within the Industry 4.0 ecosystem it took 3 years, including the development of Data Spaces. If you are not aware of it, I just want to call out, that the standards in the Industry 4.0 area have now become ISO/IEC standards, e.g. the Asset Administration Shell.

In this article, I want to discuss the topic of data exchange from the perspective of integration, as this will show why Data Space as a data exchange approach are superior to existing integration approaches. I have been working on integration topics for a long time and have experienced changes in how integration is done already in the past. I will talk about the difference of three different integration approaches using a hypothetical company called EU-T1, which is a tier 1 supplier, e.g. an asset OEM, to the energy utilities industry.

If the company EU-T1 has 5 systems that need to be integrated with both, 10 customers and 100 suppliers, the number of integration points will change accordingly, based on the chosen integration approach. Let’s explore how the calculations unfold for each approach.

Point-to-Point Integration

In the point-to-point integration model, each of the company's 5 systems needs to integrate with each of the 10 customers and 100 suppliers. Therefore, the company will need to establish direct integrations between each of its systems and each partner in the supply chain.

• Integration points per system: Each of the 5 systems needs to integrate with 10 customers and 100 suppliers, totaling:

10?customers + 100?suppliers = 110?integration?points?per?system.

• Total integration points for 5 systems: Since there are 5 systems, each requiring 110 integration points, the total number of integration points for EU-T1 is:

5?systems × 110?integration?points?per?system = 550?integration?points.

Thus, in the point-to-point integration approach, the company will have a total of 550 integration points, each representing some software component. Now this approach is nowadays not very common to be honest, because the integration of the internal systems has come a long way with approaches like Enterprise Application Integration (EAI) and Enterprise Services Busses (ESB), but still worth considering as a base scenario.

For those of you who would like to look at this topic also from a cost perspective, just make an estimation what an update of one integration point (software component) would cost on average and how many integration points per year might change, e.g. through changes to APIs or data models. This should give you a yearly maintenance cost for your supply chain integration infrastructure.

Enterprise Service Bus (ESB)

In an ESB model, the company needs to integrate each of its 5 systems with the ESB, and the ESB will handle communication with the 10 customers and 100 suppliers. However, since the company operates the ESB, the company needs to build individual integrations between each internal system and the ESB, and between each customer and supplier system and the ESB.

• Integration points for internal systems: Each of the 5 systems needs to integrate with the ESB. So, each system requires 1 integration point with the ESB:

5?systems × 1?integration?point?per?system = 5?integration?points?for?all internal systems.

• Integration points for external systems: The ESB itself will manage integration with the 10 customers and 100 suppliers. Since the company is running the ESB, the company must build these integrations:

10?customers + 100?suppliers = 110?integration?points.

• Total integration points for the company: The total number of integration points the company must manage is the sum of the integration points for its internal and external systems into the ESB:

5?internal integration?points + 110?external integration?points = 115?total?integration?points.

Thus, in the ESB model, the company will need 115 integration points in total. This is already a significant saving compared to point-to-point integration and makes clears (or reminds us – depending on our age ;) ), why a whole new product category around EAI/ESB came to live a couple of decades ago.

As someone looking at the cost aspect, you can now calculate how much money a ESB approach saves compared to a P2P approach. You have reduced your cost base by around 80%. As we are now finally moving to Data Spaces as an integration approach, I assume you sense already how the story will play out ;)

Briefly going back to the EDIFACT example, it is fair to say that an EDIFACT solution is using either the Point To Point or ESB integration approach. Key point here is that the systems exchanging EDIFACT data must be directly integrated, which makes sense as the connections need to be authenticated and secured and the respective systems on both sides known.

Data Spaces

In a Data Space model, EU-T1 5 systems, and all its customers and suppliers interact through a shared framework (the Data Space), that also provides service (system) discovery, authentication and secure connections. Assuming the company uses an ESB it still has to integrate its internal 5 systems with the ESB, and the ESB with the Data Space itself, which handles the communication with all the customers and suppliers.

• Integration points for internal system: Each of the 5 systems needs to integrate with the ESB, so each system requires 1 integration point:

5 systems × 1?integration?point?per?system = 5?integration?points?for?systems.

• Integration points for external systems: The ESB needs to integrate with the Data Space, so this requires 1 integration point. Often there is an (internal) Data Space gateway that is integrated with the ESB. I either case it remains one integration point.

·?????? Total integration points for the company: Since all internal systems, customers, and suppliers are integrated through the data space, the total number of integration points for the company is:

5?integration?points?for?internal systems + 1?integration?point?for?the?Data?Space = 6?total?integration?points.

Thus, in the data space model, the company will need just 6 integration points in total.

Again, look at this approach from a (maintenance) cost perspective for the supply chain integration. Compared to the ESB approach you get around another 90% (maintenance) cost reduction.

Key Takeaway

While changing the integration infrastructure will cost money, the question is not so much on the initial implementation cost, but more on the TCO and ROI, based on the saving in the maintenance cost. When companies moved from a P2P to an ESB integration approach, it also costed them money and there was risk involved in replacing something that works with something new. I see us in a similar situation right now. New approaches to do better integration in a global supply chain are not coming around every couple of years. The shift to Data Spaces is a change to the fundamental integration architecture, with all its risks and opportunities. Also, that Data Spaces and associated standards were developed by the technology users and not technology vendors or standard organization should give us more confidence that Data Spaces are here to stay and its adoption in the next couple of years with accelerate.

This finishes off part 1, and in part 2 we will look at other digital components necessary for a scope 3 emissions solution along a global supply chain, especially Digital Twins and Digital Product Passports and how they complement Data Space in building an end-to-end solution for the exchange of scope 3 emissions. See you in February.