Most companies of more than medium size that does 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 different best of bread design tools used by different engineering disciplines, and the data must at some point in time be consolidated across disciplines and communicated to another discipline. This other discipline being procurement, project execution, manufacturing and/or supply chain.
This article is a continuation of the thoughts discussed in an earlier post called integration strategies, if the full background is wanted.
The names of the applications might be different, but the underlying problem remains the same: Engineering data is created by different best of bread design tools used by different engineering disciplines, and the data must at some point in time be consolidated across disciplines and communicated to another discipline. This other discipline being procurement, project execution, manufacturing and/or supply chain.
This article is a continuation of the thoughts discussed in an earlier post called integration strategies, if the full background is wanted.
As the first figure indicates, this has often ended up in a lot of application specific point to point integrations. For the last 15 years, more or less, so called Enterprise Service Buses have been available to organizations, enterprise and software architects. 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.
By implementing such 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?
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.
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
The header image used in this post is by Bartkowski and purchased at dreamstime.com
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
The header image used in this post is by Bartkowski and purchased at dreamstime.com
RSS Feed
