With data exchange, in this context, I mean the need for support of processes and data transfer between software platforms.
There is also another aspect, which is the need for interoperability between stakeholders both internally and external to the enterprise.
Would it be possible to combine the two? Yes.
Most companies that do any engineering soon finds itself in a similar situation to the figure below.
The names of the applications might be different, but the underlying problem remains the same: Engineering data is created by best of bread design tools used by different engineering disciplines, and the data must at some point be consolidated across disciplines and communicated to another discipline. This other discipline being procurement, project execution, manufacturing, service and/or supply chain.
As the figure above indicates, this has often ended up in a lot of application specific point to point integrations. For the last 25 years, more or less, so called Enterprise Service Buses have been available. The Enterprise Service Bus, often referred to as ESB is a common framework for integration allowing different applications to subscribe to published data from other applications and thereby creating a standardized “information highway” between different company domains and their software of choice.
Note: In later years more modern alternatives like iPaas platforms, Microservice orchestration tools, event streaming platforms etc. have become available. They often yield quicker results, but inherently share some of the same challenges on higher process level as still, data needs to be mapped.
By implementing an Enterprise Service Bus, the situation in the company would look somewhat like the figure above. Now from an enterprise architecture point of view this looks fine, but what I often see in organizations I work with is more depressing.
Let’s dive in and see what often goes on behind the scene.
Modern ESB’s have graphical user interfaces that can interpret the publishing applications data format, usually by means of xml or rather the xsd. The same is true for the subscribing applications.
This makes it easy to create integrations by simply dragging and dropping data sources from one to the other. Of course, often, one will have to combine some attributes from one application into one specific attribute in another application, but this is also usually supported.
So far everything is just fine, and integration projects have become a lot easier than before. BUT, and there is a big but. What happens when you have multiple applications integrated?
The problems of point-to-point integrations have effectively been re-created inside the Enterprise Service Bus, because if I change the name of an attribute in a publishing application’s connector, all the subscribing application’s connectors must be changed as well.
How can this be avoided? Well, several ESB’s support the use of so-called dictionaries, and the chances are that the Enterprise Service Bus ironically is already using one in the background.
So, what is a dictionary in this context?
Think of it as a Rosetta stone. Well, what is a Rosetta stone you might ask. The find of the Rosetta stone was the breakthrough in understanding Egyptian hieroglyphs. The stone contained a decree with the same text in hieroglyphs, Demotic script and ancient Greek allowing us to decipher Egyptian hieroglyphs.
Imagine the frustration before this happened. A vast repository of information carved in stone all over the magnificent finds from an earlier civilization…. And nobody could make sense of it….. Sounds vaguely familiar in another context.
Back to our more modern integration issues.
If a dictionary or Rosetta stone is placed in the middle, serving as an interpretation layer, it won’t matter if the name of some of the attributes in one of the publishing applications changes. None of the other applications connectors will be affected, since it is only the mapping to the dictionary that must be changed which is the responsibility of the publishing application.
If such a dictionary is based on an industry standard, it will also have some very beneficial side effects.
Why?
Because if your internal company’s integration dictionary is standards based, then the effort of generating information sent to clients and suppliers, traditionally referred to as transmittals or submittals, will be very easy indeed.
If we expand our line of thought to interpretation of data from operational systems (harvesting data from physical equipment in the field). Commonly referred to as IoT, or acquisition of data through SCADA systems, then the opportunities becomes even greater.
In this case it really is possible to kill two birds with one stone, and thereby creating a competitive advantage!
Bjorn Fidjeland
A similar article was published at plmPartner.com several years ago “Data Integration – Why Dictionaries…..? “ but then in a slightly different context.
RSS Feed
