ADAM Update To Version 5.5

DAM vendor, ADAM Software, have released version 5.5 of their flagship DAM solution.  Here is the obligatory press quote from their boss, Pieter Casneuf:

“ADAM 5.5 is our most significant, far-reaching and game-changing software release to date.  It combines product information and rich media management to help enterprises build their brand and the digital identity of their products. This allows their multi-functional teams to engage across online and offline channels effectively.” [Read More]

The first half of the release has the ‘benefits’, the lower half has the features.  For new software releases, some commentators, journalists etc tend to favour the features because they are statements of intent, i.e. time and money was put into development of them.  Although the descriptions are usually highly embellished and may well contain a fair proportion of vapourware lurking behind the impressive sounding language, they are about the closest you will get to the facts.  In this case, there are three new features:

• Updated ‘Enterprise Search’ using ElasticSearch
• REST API
• Cloud Storage

I will deal with each of these items below, but there is also a longer description of what’s in 5.5 for those who wish to read more than what’s in the press release.

The first point is that Pieter’s description of this as ‘our most significant, far-reaching and game-changing software release to date’ might be over-egging it, just a bit.  Most of the features from the new ‘Enterprise Search’ appear to been derived from the use of the underlying Elastic component which is not built by ADAM, but is a third party technology.  A good number of other vendors have implemented this already, or some other NoSQL alternatives which are similar in terms of facilities offered.  In other words, it’s another ‘copy the other fellow’s homework’ type of feature.  In ADAM’s favour, however, to have expected them to build their own custom enterprise search rather than using an established off-the-peg option might be unreasonable and it does illustrate the gradual sea-change in DAM technology trends towards integrating components that someone else has built rather than vendors hand-rolling their own poorer substitutes.

Moving on, according to the ADAM profile on damvendors.com (the one accessible to registered users – but still available to free account holders) they have had a REST API since at least January 2014, i.e. two years ago.  Either this isn’t new, or possibly what they had before wasn’t up to scratch as an example of a REST API and it’s another ‘functional equalisation’ exercise to bring them into alignment with the competition.  My recollection was that ADAM once had a Python-based scripting capability (and perhaps it still does).  I believe there were a few of their resellers who employed it to build their own custom DAM solutions using ADAM as a kind of back-end DAM-services provider (which I thought was a good idea).  REST APIs are usually fairly simple for third party developers to get to grips with (and most apps have them now, in DAM and elsewhere) but unless the architecture is designed to allow end users to extend them (e.g. with a scripting facility) they depend on the vendor having provided the calls with the functionality you require.

A point made in a CMSWire article I read yesterday is that Cloud apps can be harder to integrate with because the range of options tend to be more restricted, especially if the integration counterparty happens to be a competitor.   In some cases, this might be a good thing as it avoids ill-advised integration techniques, like developers firing raw queries and updates at the core database (obviously, that never happens in the real world, right?).  The flip-side of that though is that if the vendor hasn’t provided you everything you need for a particular task to be completed via their API, you are paying  them professional services fees for them to build the missing piece of the integration puzzle – or worse, waiting for a future release when they finally get around to providing it.  From my experience, some DAM users can incorrectly assume all integration features they need are included, as standard, just because the word ‘API’ is mentioned in the spec, but you need to check the finer points about what facilities are actually available and then measure them up against your requirements.

The last point referred to in the press release about Cloud storage appears to be that ADAM can now be hosted on the Microsoft Azure Cloud computing platform, which is logical enough because ADAM is a Microsoft .NET-based solution.  Again, however, this isn’t necessarily that innovative, other vendors such MediaValet have being doing the same for at least four years now solely using Azure (in fact, they claim it is six).  Indeed, ADAM actually announced they were Azure partners in July last year.

Having filtered out the marketing hyperbole, this release looks like it is bringing ADAM into alignment with numerous other competing products out there: i.e, it isn’t really innovative, nor quite as ‘significant, far-reaching and game-changing’ as billed.  A question I have speculated on earlier this week is how long the DAM software market can sustain itself without making any real investment into genuine R&D that is not simply based on copying the rest of the market?  Perhaps this is the cue for another Keynes quotes about markets being able to remain irrational for longer than you can remain solvent etc, but another possibility is because they are eyeing a hook-up with a larger (and wealthier) suitor, for example, OpenText.  This is evidently baseless conjecture on my part, but a few other people appear to have thought along similar lines – even if the specific cases under discussion might be not be the same.

Share this Article: