ECM co-existence and the vuvuzela

I'm in the middle of reviewing feedback for a number of ECM product evaluations that I'm presently updating.  The upgrade from minor version to minor version (1.7 to 1.8 etc) is usually heralded by loud marketing cries from the suppliers. Closer inspection though tends to reveal fixes and gaps plugged, rather than anything revolutionary. 

But today I was struck all of a sudden by what seems to be something of a change to daily business.  In the past year point releases for many of the more prominent ECM vendors have been much less about fixes and much more about co-existence. To explain...

Though every software firm regales me with tales of how they "replaced" FileNet or EMC or whomever, the truth is usually that they are now installed in the same locations as those legacy vendors.  Gone seem to be the days of "one ECM to rule them all." Instead people want to use multiple ECM applications, and when they introduce the likes of Microsoft SharePoint into the equation it is very seldom to actually replace an incumbent supplier (despite what the vuvuzela-blowing Microsoft channel would have you believe). It is more typically in addition to the incumbent supplier.

For an old-timer like myself (though you would never guess it to look at me) this normally raises concerns,  since the goal for the last 20 years has been to get everything in a single repository, or at least to attempt to. The very idea of multiple ECM suppliers in one location, on the surface at least, flies in the face of this goal, but the reality of the situation is probably somewhat more nuanced.

In the past year increased and expanded support for connectors and adapters of all sorts has been the key theme, and an almost literal acronym soup of protocols are being supported from CMIS to CIFS to IMAP.  What suppliers are slowly coming to accept is that the future is heterogeneous, and that to survive they need to be a team player. If your product doesn't play nicely with the products already in place then you are unlikely to make much progress. This is a good development all round, but its not without its drawbacks.

As a buyer you should absolutely expect any new supplier to be able to technically adapt to and interact with your existing environment. There is often no good reason other than to fatten a suppliers paycheck for you to throw out systems and processes that work perfectly well and replace them with something new.

But be aware that just because a supplier says that their product supports this or that protocol or integration point does not mean that they all do so in the same way.  For example WSDLs (the stuff that describes how a Web Service talks to others) can range from the verbose and barely literate to the simple and profound.  Likewise integrations with common applications such as Word, Outlook or SharePoint can be pug ugly or near transparent. 

Standards are a good thing, and the fact that suppliers are in a rush to adhere to as many as possible is an equally good thing. But don't confuse compliance with a standard as everyone doing things the same way.  They all theoretically reach the same end (hence adherence to the standard) but getting to that point can take many different directions.

So if co-existence of a new application into your existing information management environment is important to you then be sure to test and demo those elements before purchasing. Otherwise you could see your new suppliers' idea of team play akin to the French soccer squad: complete with disagreements, work stoppages, and an early bath becoming the most likely outcome.

Other ECM & Cloud File Sharing posts

ECM Standards in Perspective

In real life I don't see ECM standards proving particularly meaningful, and you should see them as a relative benefit rather than absolute must-have.