Off the Shelf Integration in Enterprises

Two blog posts have got me thinking lately,

This from PSD and this from JP.

The snapshot analogy led to a plethora of sins, to the way we designed databases, to the way we “inserted”, “amended” and “deleted” data. As we tried to force the snapshots to move around between systems, we hit DRM version 1. Enterprise Application Integration. Otherwise known as paying to bury our data, paying to dig it out again, and then, just in case we haven’t had enough, paying to move it around. And we could do so many wonderfully silly things as a result. Hire armies of people to write code to synchronise things, then hire more armies of people to write code to reconcile the data. Sometimes we missed out the “writing code” bit and just hired the reconcilers direct.

And the platform vendors prospered. And the database guys prospered. The storage guys prospered. The EAI guys prospered. The code writers prospered. The reconcilers prospered. Everyone prospered.

Except the customer.

JP

I have seen a number of enterprise projects pay external consultants to bury, dig out and then move around data. Its amazing how complicated a simple job can become. Its even more amazing that an industry still thrives from doing so.

For a while now it has been common practice to buy off the shelf products to perform common tasks. They come with a nice fluffy layer of support and there is always a consultant on hand if you want to spend some more cash. In general these off the shelf products do NOT do what they need to do. They require a great deal of customisation usually taken care of by a bespoke programming language specific to the “Off the Shelf software.”

As a result you either buy consultancy or train your own staff in the bespoke language. – both of which stink of vendor lock in.

Lets think for a moment what that common task actually is. A common task is accessing, consuming and potentially updating data from a completely different system. None of the off the shelf systems seem capable of doing so without swallowing vast sums of consultancy fees. JP points out the daily tasks for knowledge workers are actually search, syndication fulfillment and conversation. Each of these are very valuable to the enterprise. In this case I am particularly talking about syndication.

No man is an island.

Neither is software….. particularly in the enterprise.

Software (as with people) is only as good as its ability to interact with the eco-system around it.

In fact without some kind of syndication between systems you will find that search, conversation and fulfillment lose much of their value.

We seem to be at an interesting time in the enterprise, billions of pounds have been spent on massive integration projects/software but when compared to small RESTful APIs like Flickr and Twitter your left wondering where all the money has gone.

I love Paul’s definition of a mash up :

To me its actually simpler,

  • mash ups are fun
  • integration sounds like hard work and usually is

As Doc points out Markets are conversations, two way conversations, which means companies need to state very clearly to big vendors what they need to change. In this case, its zero touch access to data stored with-in an enterprise system.
Maybe the big vendors will sort out their act or maybe open source and open standards will provail in the enterprise leaving the vendors wondering what to do with all their consultants.

Will that day ever happen?? I’m hoping so…..

PSD has also pointed me to a earlier post of his : A Moral Tale, which is well worth a read.

Advertisements

2 thoughts on “Off the Shelf Integration in Enterprises

  1. My take was really that mashups vs integration is a context thing. I actually think it’s not that mashups are fun, but that if it’s fun you’re more likely to call it a mashup.

    Here’s a good one: what would you call work that involved making flickr talk with sharepoint? Do both ends need to be nice and/or fun for it to be a mashup?

    Oh (pedant alert), and neither Twitter or Flickr are RESTful. Flickr is a good old fashioned RPC API – just a lovingly documented and well designed in most places one. Twitter is what you get if you use Rails, which is in my view better but broken in a couple of important places (check out the destroy method if you don’t believe me).

Comments are closed.