Dancing Around Integration Bear Traps, volume 2.

Roughly 70% of EAI projects fail – this is a statement by Gian Trotta in blog writing “Dancing Around EAI ‘Bear Traps’10 years ago. Whether that number was true then or reality still nowadays – well at least in company I work we don’t see failure rate that sad. Despite the numbers most of the factors that Trotta depicts are still reality. From my experience, I updated Trotta’s original Bear Traps list as I see situation today.

Pace and Quantum of Changes

In integration only thing that is sure is that changes will come. Unless the business is totally paralyzed something always tend to change at process level or at the system level. Use of centralized integration platform helps companies to prevent propagation of these changes to all connected systems – they tend to concentrate to changed system or process and to the integration platform that connects changing system technically to other systems. This leads to a fact that there will be constant flow of changes to integration platform – which keeps other systems away from the change’s event horizon.

Standards are never universal

This is one of the Trotta’s original trap list and it is still valid today. 10 years ago Trotta used Web Service related standards as an example of popular but immature and conflicting standard. Nowadays things are better as most popular standards have matured, but I wouldn’t drop Standards from trap list because new standards are constantly evolving and companies don’t invest enough on testing and validation of how standards including messaging dialects (UBL, RosettaNet etc.) fit to their needs and existing systems.

Missing Exact Artifacts

Artifacts can be thought as the mandatory ingredients for integration implementation work. If each integration process can answer to the following questions in a documented manner, it is risk for future changes is lower. The list is applicable for messaging integration.

  • What are the systems or solutions to be integrated?

  • What are the data flows between those systems?

    • What transition of the business process this integration part is all about?

  • Which technical systems or parties are sources and destinations of these data flows?

    • What are the interface protocols and messaging patterns of these systems?

  • What data is transferred from source to destination in any transactions (Purchase Order, Invoice or Customer, etc)?What are the peak message or data volumes of the data flow?

    • Schemas

    • Mapping rules between source and destination

    • Variable test material about source system with full permutation of all message combinations (or try make as wide set of test messages as possible).

  • What is the maximum size of one message or batch transfer?

  • How the data flow is triggered and which system triggers the flow? For example:What kind of business and functional errors might happen during the execution of a data flow?

    • User presses button in source system to initiate the data flow to destination systems

    • Data is synchronously requested from source system by destination system. E.g. web page request to SOA layer

    • Source system has scheduled batch job which sends the data

    • Should be scheduled but source system has no scheduling feature. (Scheduled by Integration Platform).

Quite a list of questions? What if all of them are not answered and we need to start implementation because of project schedule? Well, the less you know, the more iterations each integration shall go through. When the answers to previous questions are not available, this might the only way.

Integration is considered as a Tool

One of Trotta’s factor to high failure rate is that Integration is seen as a tool instead of system of it own right. I call it Project Slavery – in this slavery integration is considered as subproject for some bigger project, e.g. ERP upgrade etc. Decision makers tend to think that ERP project must handle its own integrations. Even when there are company wide architecture plan which dictates that centralized integration platform must be used, the project tries to do integration as cheap as possible, usually not even bothering to see whether there already exists reusable integration processes or even SOA based services on integration platform. If wheel is invented again every time, the possibility for failure is evident.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s