The DAM industry has enjoyed significant growth in the last few years -- probably as far back as a decade ago. The reason behind this is a simple supply and demand effect that is easier to spot with hindsight but harder to identify while it is in-play (and might explain why DAM was ignored as a side-show by so many for so long).
A proliferation of digital media origination tools means that more digital media is in now circulation than ever before. This is a trend that has unstoppable momentum and I am not able to think of anything (bar global catastrophe) that might halt it. The need to organize digital content has rapidly become a crucial task, hence why DAM solutions are in-demand.
These are the fundamental factors behind the growth in DAM and the implication is that there still is a clear and increasing need for them. A more critical question is whether value can continue to be obtained from the current DAM platforms that are on offer, or if alternatives might better answer end user requirements.
Bloated Applications And The DAM Features Arms Race
There are numerous other methods by which digital assets acquire value. A few of the more significant functional areas include: adding metadata to help users find assets (probably the key reason still), asset manipulation, advanced workflow, decision support, permissions and asset access controls and business intelligence. The interrelationship between these functional areas is also becoming highly sophisticated, especially in respect of metadata. A side-effect of this complexity is that different interfaces are becoming necessary to cope with diverging levels of user expertise.
The scope of DAM applications is becoming too diverse for vendors to handle exclusively on their own. As one vendor adds a feature requested by one client, so there becomes an expectation that they will all offer it. Many vendors now spend large proportions of their development budgets simply trying to remain in the 'feature arms race'. This is unsustainable over the medium-long term from both a cost and technical stability perspective. As with any other capitally intensive conflict, the victor is typically the one with the deepest pockets; however, in DAM, while there are a number of brands which are better known than others, none of them are wealthy enough to win this war outright.
An early casualty of bloatware applications is reliability. Many DAM systems I come into contact with now are more buggy and less robust than they had been several years ago. This has to be a consequence of vendors needing to spread themselves too thinly without adequate resources (and ultimately capital) to achieve their ambitions.
Editor's Note: Also check out DAM Beauty and Usability
More DAM Stakeholders Than Ever
The number of different stakeholders involved in Digital Asset Management initiatives has increased in recent times. There has been a surge of vendors producing dedicated end user interfaces, cut down versions that can upgrade to another product, or features that allow specific functionality to be used outside the core DAM interface. These are all to cope with new users who might be unwilling to go through an extended learning curve. They need to rapidly find relevant media assets and move on.
At the same time, those who do spend most of their working day with a DAM system, such as production personnel, want to be able to do far more with it. They require more advanced batch processing capabilities and assistance with managing common asset workflow tasks.
There is a further class of stakeholders who have a more strategic or managerial role. They have to get all the assets acquired from multiple sources and ensure they circulate through the business. They also need related solutions to contribute metadata to digital assets and create connections between systems that support advanced enterprise-wide competitive intelligence. Although I am unsure about how far DAM is really a subsidiary of CXM, I am certain that it has a key role to play within the strategic approach which CXM represents.
The Break Up Of The DAM Market
The assumption of many in the DAM market is to assume there is likely to be a period of ongoing stratospheric growth in our sector. There is dangerous collective industry-wide complacency developing based on increased customer interest. As described at the top of the article, this is not because end users think DAM software is especially good, it is an external factor pushing growth in demand for anything available which might do the job. At present, users have limited choice outside the options provided by different DAM vendors, but that could change unless some of the structural inefficiencies in the DAM solution market are resolved.
There is a slowing of innovation in DAM as the market participants struggle to keep up with everyone else and maintain working products. The danger period for the DAM industry is right now when the market assumes that there is a limitless opportunity waiting to be exploited, coupled with a failure to fulfill user's existing needs. There are historical precedents in the tech sector to indicate how a DAM bubble might be forming, CRM being an obvious case in point. Although organizations still use concepts from CRM, it has become a proxy term for expensive products that promise much but ultimately don't deliver. Arguably the momentum behind CXM is partly inspired by a collective need to find an escape route from (or even scapegoat for) the issues with CRM implementations. DAM is potentially at risk of a similar fate unless the industry becomes self-aware enough to recognize them.
There needs to be an acceptance by both vendors and also end users that the range of capabilities required implies specialization in one given niche or another. How these will sub-divide is still open to debate, but it is already clear that some operators have accumulated more expertise in certain areas than others and I would predict the DAM industry breaking up into further sub-divisions as a means for vendors to differentiate themselves and keep their development costs in check.
While this might appear to be a reasonable industry survival strategy, a limiting factor is the complexity involved if you want to get one DAM solution to exchange data with another, which conveniently segues into my next topic: interoperability.
Resolving The DAM Interoperability Crisis
Interoperability seems to be one of these subjects in DAM that everyone agrees is essential and is arguably already becoming what could more accurately be described as a 'crisis' rather than merely a technical issue. Most vendors have solutions with APIs which enable their products to be integrated, but the method by which this has to be done changes with nearly every platform and makes the exercise far harder than it really should be. Anyone tasked with making multiple DAM solutions work together or collect asset metadata from a third party content repository understands how demanding it can be -- all this on top of the creeping scope of the products they have to manage. Several of the vendor professional services teams I come into contact with have dedicated personnel or even whole teams of staff whose job is solely to try and keep all these integration plates spinning.
Just like the other DAM industry issues, the root cause of this seems to be down to each vendor independently devising their own integration protocol in the absence of something straightforward and easy to implement which they can use as a model. Usually there are some common themes, like REST with JSON or XML for web based solutions. After that, however, they each start to break away from their peers into bespoke implementations that are something like the software equivalent of the differences between Spanish and Portuguese: close enough to appear similar, but not quite enough for everyone to be able to properly understand each other.
While interoperability standards such as CMIS offer a possible template, I cannot see that standard specifically gaining sufficient market penetration in DAM. The topic needs to be broken down into a far more modular series of integration protocols that can be scaled up to -- possibly with CMIS compliance as an objective, but not as the starting point. It strikes me that interoperability standards are much like software, while technical sophistication is important in expanding the range of what is possible, the hardest part of the whole process is persuading people to actually just use it at all.
Any DAM interoperability standard needs to be so simple to get started with that it would be almost churlish to not make your product compliant with it. This appears (to me) to be the only way to get the majority of DAM solutions onto some kind of baseline starting point from which more ambitious integration options might become feasible over time.
To answer the question: do we still need DAM? The answer is yes, more than ever. Do we still need DAM platforms? That requires a more equivocal answer. Probably the answer is still yes, but, in order to address users' expanding range of needs, no single product is likely to be sufficient. Greater specialization and the ability to combine components in a 'best of breed' fashion seems like it will become an essential characteristic of DAM solutions in the near future.
As evidenced by the increased volume of digital media itself, where a requirement is a 'must have' proposition then you can be reasonably sure that commercial interests will organize themselves to answer it. Whether the current crop of DAM platforms represent the early stage of a long and successful period of sustained growth, or merely one of many evolutionary boom/bust cycles within a wider process remains to be seen.
Editor's Note: Looking for more DAM? Check out Managing Risks With Digital Asset Management