In the last 5 years of my career as an enterprise architect, whenever the word "integration" came up, discussions started about the choice of an ESB (Enterprise Service Bus), SOA (Service Oriented Architecture), FTP or web services, SOAP or REST, XML or JSON, etc.
In short, when involved in discussions about "integration", one most likely finds himself drowning in a multitude of technical acronyms and technological standards.
I compare the technological side of integration to the "Dr. Jekyll" personality : it is the side well-known to everyone, stable, under control and increasingly complying to uniform standards.
Functional aspects prevail
However, when envisioning an integration strategy, many companies seem to ignore the "other side" of integration, the side that is concerned with "what will we say to each other ?".
In a mainly technology-driven integration hype the functional dimension is largely being neglected. Yet, these functional aspects carry as much weight as the technical ones in making or breaking integration efforts within an enterprise. Hence, in the spirit of the 19th century novel, the functional dimension could relate to the "Mr. Hyde" character : it most often hides behind "Dr. Jekyll" (the one everybody speaks of) and it can hit hard if not taken seriously.
Finding the balance
Now, to successfully accomplish business integrations, we need to find a proper balance in this split personality, so that both functional (Mr. Hyde) and technical (Dr. Jekyll) integration aspects receive the attention they deserve.
Therefore, an integration endeavour has far more probability of success, if the exercise can start from a business and functional perspective. In my opinion and experience, following a top-down plan can help to find peace and balance :
- Business layer: "Whom must I communicate with ?", "What information do we or our communication counterparty need ?", "What do we need this information for ?", "How frequently will we be interacting with these parties ?", "What is the required data quality when interacting?", "How can we improve the organizational responsiveness?"
=> Identify business actors, information needs, semantic conversation, etc. and put these in context of end-to-end processes.
Note : Don't forget about constraints here : "How long can I afford to wait for information ?", "How critical is the quality of the information received ?", etc. - Application layer: "What data represents the information need ?", "Where can I find these data ?", "What is the current quality of the data (completeness and correctness) ?", "How fast should the data be available?"
=> Identify applications and data sources, the structure, terminology and values to be exchanged, establish a common communication language aka canonical model
Note : Thinking in terms of wisely chosen reusable services, with a clearly defined and described contract and owner (also called service-oriented) greatly increases the agility of the application layer towards the business layer. - Technology layer: "How will this data travel across applications?", "Which data format and protocol should I use?", "What do we need to use that data format and protocol?", "What technology is already in place?"
=> Identify the technical platforms (ESB), data formats, security and protocols to be used.
This way the two personalities of integration can be harmonized avoiding some very nasty consequences.
Bottomline : "Don't hide from Mr. Hyde !"
