DAM integration and application architectures seems to have been getting more attention recently from vendors, both in terms of direct connections to specific non-DAM platforms, but also API modifications and changes to the underlying architecture of DAM solutions.
First up is this blog post from Asset Bank. They sent me details of their Sitecore integration a few weeks ago, but this is rapidly moving towards being a de rigueur feature for all modern DAMs as numerous other vendors have done this already, so it’s not of great interest as a news item. The integrations with SharePoint, Drupal and WordPress are more noteworthy and while quite a few other vendors offer these facilities too, it is a smaller number than Sitecore.
I am encouraged by the fact that most DAM users seem to be electing to use a dedicated DAM solution which they integrate with SharePoint, rather than trying to adapt that platform to do Digital Asset Management. There are tools you can get to help improve SharePoint’s media transcoding capabilities to potentially create something like a DAM, but as most experienced DAM users know, that is only part of the story, however and the cost/effort of adapting SharePoint to try and get it to work like a dedicated DAM solution often isn’t justifiable unless you have other strong motivations for tying everything into SharePoint and/or Office 365.
I see that you have to pay an additional fee to get these integration modules for Asset Bank. A number of other vendors offer these same options, but without any further cost, however, this could just be a case of them being more transparent about their charges since with other vendors who apparently offer them for free, you might find additional fees being applied for professional services and other ‘setup’ costs (and not be able to identify specifically how much the integration element has cost you either). As we discussed in our DAM News vendor pricing survey, to get a good comparison of vendor costs, you need to look at more than licences and consider them in the context of your particular DAM scenario.
The second post of interest this week is by Ramon Forster, CEO of Picturepark where he has published a public letter describing their release plans for 2017. This quote is probably the key one:
“We realized that we had to build a next-generation Picturepark that would become a content platform that can route content from where it is stored to where it is needed, levering our Adaptive Metadata at the core. And because such a content-routing platform must primarily serve as an integrated backbone to other systems and processes, the next-generation Picturepark had to be built “API first” and highly scalable from the ground up, while staying lightweight and easy to use.” [Read More]
It should be noted that Picturepark is already widely integrated with a lot of other solutions (and I believe they were among the earliest to connect with both SharePoint and Sitecore). The API-first point is an interesting one. I think this is almost certainly the right way to go and if you are planning on buying a new DAM system those where the interface is built using the vendor’s own API are the preferred choice. I need to point out that Picturepark are not the first, nor the only firm to implement this type of architecture in their DAM platform. There are products have been built this way for years now (including a few that did it from the start, rather than adding it later) but the letter from Ramon is further evidence of an emerging pattern.
To try and explain the importance of all this for those still unsure, the API (Application Programming Interface) is a core ‘back-end’ range of functionality which developers provide for other systems in order to facilitate integration and data exchange. API-first means that the interface (aka ‘front-end’) users operate to do tasks like searching, uploading, downloading etc, is built using the same API features, so theoretically, someone else could create their own solution which looks completely different (and potentially operates in a unique way also) but is still based on the same underlying capabilities. Under normal circumstances, most users are not going to want to re-invent the wheel and create a completely separate DAM, but there are many situations where they want to re-use the capabilities of the DAM elsewhere, for example inside a WCM solution to choose images for use in website, from an HR system to store photos of employees or managing sales-related assets in CRM systems (to name just a few of the more common examples).
The trend towards integration and API-first methods is causing something of an unseen functional rift in the DAM solutions market – but it might well become a lot more visible as we move into 2017. On the one hand, there are the vendors have done a lot of front-end work to make the solutions appeal to a marketing-communications audience and features have been rapidly added without too much concern for the underlying architecture. Some less well-informed DAM system buyers, do not attach a great deal of value to these topics and usually don’t understand the need for them until they ask for something slightly out of the ordinary and get offered excessively large quotes for the requested work and/or reticence to deliver on the part of the vendor (usually accompanied by mass-outflows of their development personnel, who fear being assigned to the job in question). Those firms who have pursued this route will now probably have a number of customers, but to keep them satisfied and to continue innovating, they will have a substantial amount of work to do to rebuild their solutions in a more flexible and resilient manner. These products tend to be easier to spot because the API capabilities are far less sophisticated and the firms in question go to a good degree of effort to hide the extent of what they offer (for example, no public documentation and evasiveness when asked to present it).
The second type are those vendors who have already seen this coming. This might be due to the fact they have a better understanding of the need for a robust architecture designed to be integrated from the start, or it could be that they just ran into the aforementioned problem sooner. These are also not clear-cut distinctions and I suspect a few product managers and system architects may have wanted to do things ‘properly’ at an earlier date, but were either persuaded to defer it by colleagues, or had to compromise because there wasn’t enough money available to sustain their ambitions. In addition, most implementation staff approach these tasks with some trepidation as it is the software equivalent of taking an engine apart and then wondering if you will be able to put it back together again in working order. This second group are poised to reap the benefits in terms of agility and capacity to innovate without generating numerous unwanted application stability and maintenance side-effects.
Earlier this week I was invited by representatives of Brandworkz to look at their product based on our article about their recent press release. As described, in terms of the ‘headline’ features, this didn’t look particularly interesting and there was a lot of stuff about tab controls etc – i.e. focusing on the user interface. The application architecture, however (which they rebuilt for the latest version) had a depth of sophistication which wasn’t apparent from the press, in particular there were methods of defining some very flexible and advanced metadata schemas and workflows that are quite a long way ahead of many of their peers (although certainly not all of them).
When I talk to a lot of DAM users about this sort of subject, they tend to use phrases like ‘we don’t want anything complicated, we want something simple’. Their definition of ‘simple’, however, tends to differ from to other groups of users in another organisation who have a requirement which sounds superficially similar. What they really mean is ‘we want something built exactly for our needs (which are simple for us to understand because we came up with them)’ to which you can also add ‘and we want it at the same price as a generic, non-custom edition’. Resolving those two positions is virtually impossible (or very difficult) for vendors to deliver economically once they get beyond a handful of customers. The only practical way for them to deal with it is either to talk users out of what they say they want, or (the better option) to develop a very flexible architecture with a lot of different configuration options which can be made as simple as possible for the end user but is advanced enough to be adapted. In other words, like everything else in IT (and life in general) it has to be both, sophisticated/advanced enough to deal with nearly anything thrown at it, but capable of being presented in a rationalised manner that seems simpler than it really is.
When these kind of topics get discussed, many users (and a depressingly large number of DAM vendors and consultants) tend to regard them as ‘technical’ subjects and are eager to discount or ignore them as a result in favour of the more aesthetic considerations, but ‘technical’ is the wrong term – these are operations management issues. The decisions about how your metadata models and workflows get configured (and whether they can be adapted as your business changes) will have a massive impact on ROI which will feed into your bottom line. You don’t need to be a management consultant to understand that if a given process takes slightly longer to complete than an alternative approach (even just a few seconds difference) and you repeat this effect hundreds of thousands of times, significant costs will be incurred; the mathematics are very difficult to argue with. This is where the benefit of a flexible DAM architecture really starts to pay off and it is the sort of issue that needs to be considered carefully before you choose a given product as the basis for your implementation rather than finding out later on that it is less adaptable than you need it to be.
I can understand that good DAM application architecture isn’t a particularly easy sell for vendor marketing people, but those suppliers that have already put in the investment to achieving it should be making more of this asset (especially as it might yield them a huge commercial advantage in the future). In addition, end users need to educate themselves more about this subject than they have done hitherto. I am obviously not going to argue too loudly if you want to offer up cash to my firm so we can help do this for you, but before that happens, I recommend spending some of your own time instead becoming more familiar with the issues and thinking about DAM as a process rather than a form of communication.