top of page

No matter what THEY say, Integration is hard

THEY are the vendors that have been telling me since 2000 that they have great tools to make application to application integration plug-and-play. First they were called Middleware, then we had this thing called the Data Hub, then we had Web Services*, then came the API* economy, next will be?


In my experience, this simplified integration promise has been an utter failure in practice. So I’d like to introduce my own terms like plug-and-pray, plug-and-grief, plug-and-pay, … maybe you can add to my arsenal.


There are two reasons why app-to-app integrations are such a pain

  1. There is no universal data standard Application functionality is driven by Master Data and Transactional Data. Each application defines their Master Data and Transactional Data differently. Some Master Data fields in application A are required fields, while in application B they are optional and in application C the field doesn’t even exist. The same is true when entering transactional data. Not only might the data thus not be there to send from application A to application B it might have a totally different meaning. Then add the custom fields you created or the fields you decided to use differently than designed by the application. So as an interface designer you have to properly map all these fields and find ways to augment the data with the fields that certain apps do not have. Then you also have to decide how to handle error or warning messages between the applications. Just think of the simple example of System A having a required field with a list of entries to chose from. System B that needs to interface with System A has this field as optional and it is free text. System B does not allow you to change the field to required and/or add drop down lists of values to chose from. To make this work you really have to enhance system B and what if it is a SaaS product and it will not let you? I’m sure you all have tons of integration nightmare stories. That application developers will agree on some universal data standard for APIs is a total pipe dream. How long did it take to agree on EDI standards? And Ironically, one of the companies I worked for enhanced the EDI formats for its unique purpose … out goes the standard.

  2. We suck Sorry, couldn’t think of any other words. Middleware can get you close to plug-and-play if we properly managed our data standards and publish/subscribe approach. The problem is that most firms’ IT department does not have the discipline to make this happen.

I’ll leave it at that for now. This blog is in my architecture principle section and is more of an intro principle to “pick the integration point with other applications carefully” and “integrate the right way”. We’ll touch on integrate the right way next time. Hint: In “We suck” above it is not entirely the IT department’s fault that we often integrate not quite the right way.


* There is some disagreement among developers on what exactly defines a web service or API, and how the two differ. We’ve done our best to stick to the facts, but bear in mind that everyone has their take on precisely what these concepts refer to

  • Web services require a network. While APIs can be on- or offline, web services must use a network.

  • APIs are protocol agnostic. While APIs can use any protocols or design styles, web services usually use SOAP (but sometimes REST, UDDI, and XML-RPC).

Thomas Bush (http://thomasbush.co.)

Recent Posts

See All

Comments


bottom of page