Is The DAM Software Market Sleepwalking Into Becoming A Digital Sharecropping Business?

This is the first of a two-part article series, the second item is now published also.

In the last 4-5 years, some trends have been subtly and gradually developing in the DAM software market.  Their cumulative effects are more significant than is being widely acknowledged.  Based on my conversations with a number of end users, vendors and investors, I know there are a number of others who have had similar thoughts.  In this article, I want to try and draw together those perspectives.

The trends I am referring to can be summarised as follows:

• The now ubiquitous use of Cloud delivery for DAM solutions.
• The blurring of the lines demarking different varieties of content digital asset solutions
• The decline of innovation and the homogenised nature of most DAM software
• The dependence of DAM solutions on a small range of embedded suppliers.
• The rise of ‘near DAM’ as opposed to (and at the expense of) ‘DAM Lite’.

I will examine each of these in this article.  In a follow-up piece, I will consider the characteristics of some solutions or strategies that could be applied by the DAM market to avoid the more negative consequences they might bring.

Ubiquitous Cloud Delivery

Cloud delivery of DAM solutions is now the norm rather than the exception – even in the enterprise segment.  I am not going to argue against using the cloud as it is, by far, the easiest method for both end users and vendors for many different reasons and makes everything far simpler than was once the case.  It has, however, led to some unexpected outcomes which are beginning to pose more of a challenge than many might have anticipated.

In February this year, I wrote an article about political issues with using an Enterprise Service Bus to coordinate interoperability between solutions (especially Enterprise Digital Asset Supply Chain requirements).  As described in that piece, more Digital Asset Supply Chain solutions now rely on multiple DAM technologies: whether introduced by a single vendor acting as a primary contractor, or end users deciding to bring in multiple providers as part of a strategy they have devised themselves.

In the past, when everything was deployed to an organisation’s own internal network, it was sometimes easier to force reluctant vendors to collaborate with each other and even if they refused, the use of shared databases and other core infrastructure (which the IT department controlled access to) made it virtually impossible to actually stop anyone from taking matters into their own hands.  Integrating software using direct connections to databases and file servers rather than through APIs is nearly always a bad idea, but it nearly always used to happen anyway either due to laziness, intransigence (or both) on the part of one or more solution providers.

With cloud delivery, that option is not usually on-offer because the required data is walled-up in the vendor’s own heavily-defended castle in the sky and they are now the sole arbiters over who gets access to it.  If one counterparty refuses to play nicely with everyone else, sanctions are required to get them to behave (a fact which increases the friction associated with DAM interoperability where it should be the opposite).  Clearly, not all vendors behave in this fashion and many lack the necessary clout to resist these demands even if they wanted to.  As should be apparent, however, if anyone decides to be difficult, they certainly can be.  It is ironic that in many of these integration disputes, a lot of cloud vendors start to sound like the in-house IT departments they once railed against when promoting their product to prospective end users.

The underlying theme here is control and the shift in the balance of power.  Those who employ cloud services to deliver their solutions have to make a choice between either settling for a state where they are the junior partner subservient to someone else who has more influence than they do, or they seek to dominate every available profitable market niche and dilute their offer as a result.

Blurring Of The Lines Of Differentiation Between Product Categories

This point is closely related to the preceding one.  DAMs, are no longer simply ‘media warehouses’ as they might have been once (which is a positive development).  They must integrate with WCM, MRM, PIM and a range of other adjacent toolsets.  Further, the more aggressive vendors of these associated products now also claim they provide some of the capabilities of DAM solutions or even offer the whole piece themselves.  The same is true in the other direction too and a number of DAM vendors flirt with changing the name of their product classification to one or other fashionable descriptions that the pay-to-play analysts are eager to promote.

There are two factors driving this: wanting to secure a far bigger slice of the budget pie and/or fear that an ambitious competitor will come along and eat their lunch.  These are not at all mutually exclusive and in many ways, they are simply the greed and fear sides of the same psychological coin.

When I talk to clients who are considering upgrading DAM solutions, often they will mention how they have a spoken to a vendor who operates in an adjacent field and asserts that their product ‘has DAM as well’.  The complexity of the Digital Asset Management problem is routinely underestimated, but that never stops ambitious salespeople from claiming their product has solved it (even though subsequent deeper analysis usually reveals that rarely to be the case).  The reverse is true also and DAM vendors who tell their prospective clients they ‘can do MRM/WCM/PIM (delete as appropriate) as well’ have also frequently underestimated the scale of that challenge.

In nearly all DAM requirements I have been involved with, the client would be better off getting dedicated, best-of-breed systems that are highly focussed on solving one specific problem, rather than the ‘fornicate with half the farmyard’ technique that vendors are sometimes prone to experimenting with.  While suites give the appearance of being a neat and tidy solution to a lot of procurement complications, the actual benefits often turn out to be illusory as the business ends up with a solution that doesn’t do anything particularly well.

The fact so many vendors inside DAM and adjacent to it have attempted to develop a DAM solution means that there is now a basic level of core technical knowledge about the subject.  Even moderately talented developers can now assimilate enough knowledge to give the impression that they have the skills required to deliver a credible DAM solution.  These contribute to the sense that DAM is now ‘nothing special’ and further weaken the business case for investing in a fully-featured one.

The Decline Of DAM Innovation

The demise of DAM innovation is a topic that has been extensively covered on DAM News before so I will not labour it again here.  I believe, however, it is more of a symptom or composite of the other factors described in this article and that partly explains why it remains unresolved.  As such, readers can consider this item the answer as to why no one innovates in DAM very much any longer.

Dependence On Key Embedded Suppliers

A contributory reason for the lack of innovation in DAM is the far greater dependence on some key large suppliers and/or toolsets.  Some of these are open source projects like ImageMagick or FFMPEG etc rather than businesses, per sé, but the effects are similar, nonetheless.

To illustrate this, let me ask a question: who is the biggest company in DAM?  It could be argued that it is Amazon.  Although many might counter that they do not sell a DAM software product, probably around 75% of DAM vendors use them for storage, transcoding, content delivery, application services and an array of other core components.  A lot of DAM firms would find it difficult to keep trading if these dependent services they are heavy users of ceased to be available for only one or two weeks.  To an extent, this risk can be mitigated by using multiple suppliers from other providers like Microsoft, Google etc, but what should be clear is that DAM vendors are the tenants rather than the landlords in this business relationship.

Nothing stops Amazon, Google nor Microsoft from offering DAM solutions and if they wanted to, they could wipe out large swathes of the competition overnight very easily.  Apart from the PR impact that kind of manoeuvre might have on the perception of them by their other cloud hosting customers, the hard-headed business reason they do not do this is because the DAM software market is unappealing for them due to its small size and the cost/complexity of managing customers.  It is far easier to provide services and let someone else deal with the problems of the end users – the ‘sell the shovels’ argument which is often used in these contexts.

Viewed from one perspective, the DAM industry has turned itself into a channel partner or integrator business model which depends on a small range of key suppliers to continue to exist.  This goes a long way to explaining why there are so many DAM vendors offering homogenous systems that are delivered and marketed using nearly identical methods.  If you view the current DAM systems market as largely an aggregate of similar operators who have slightly different implementations of the same set of services, they start to look a lot more like conventional channel partner or VAR (Value Added Reseller) businesses that can be found in sectors like IT hardware.  In these markets, participants usually compete on price or ability to successfully implement product (i.e. consulting skills). To use an analogy: if all the chefs use identical ingredients, there is a higher probability that their food will all taste the same, whatever restaurant you decide to dine in.

This kind of reductionist analysis is useful from an economic perspective to assess the who holds the influence or power in the DAM market, but as discussed earlier, this also radically underestimates the complexity of the Digital Asset Management problem domain when it comes to delivering solutions that generate ROI for end users.  To re-use my earlier analogy, although the chefs might use the same ingredients, their level of skill and expertise can substantially affect whether they can produce a dish you actually want to eat.  There is a risk, however, that these kind of subtleties are going to get ignored by many DAM users, either to save money or (more likely) because they don’t know any better.  I can foresee a potential scenario where the DAM software market blurs itself out of existence and I would argue that this loss of definition is already taking place.

The Rise Of ‘Near DAM’

Last month, Ramon Forster wrote an article for CMSWire about Dropbox and its silent takeover of DAM, especially for a core DAM use-case: sharing files.  There are some elements of this piece that I can partly agree with:

“File sharing tools are the de-facto standard for not just file sharing, but also creation and collaboration. Given this, file sharing tools literally own what the DAM industry was invented for, offering us DAM vendors more competition than we wished.” [Read More]

I would question whether the original reason DAM was invented was file sharing.  It is more the ability to associate metadata with a digital essence to give it context so you can find it to do something useful.  Digital files on computer systems are a conceptual metaphor  (i.e. a form of metadata) invented to link together non-contiguous blocks of data stored on a storage medium like a disk or tape etc.  They are still digital assets.

I have to accept, however, that these are mostly semantic arguments and practically speaking, sharing files is what a lot of DAM users have in mind when they think of what they do with their DAM on a daily basis.  In that respect (and for the same reasons I discussed earlier with reference to vendors who claim they offer DAM) Dropbox draws more users away from DAM.

Later in the piece, there are some interesting conclusions reached:

“… independent DAM software vendors should not try to compete with file sharing tools in creative collaboration and operations. Refraining  from doing so will relieve us from spending thousands of men-hours for features such as file synchronization, creative review & approval management, brand resource portal building which all needs to be super-easy to use by marketeers and their clientele (notably always on on all devices).  Instead, let’s integrate all these bespoke features that we get ‘for free’ from the file sharing tool vendors. Have us then revisit our own DAM software core strength which I believe is being the one-stop inventory for master content, managed using powerful metadata capabilities.” [Read More]

I say ‘interesting’ because I don’t agree with Ramon, however, I might have done once and I can see the logic from a complexity and cost-saving perspective.

The arguments in favour of using Dropbox have some similarity with those for using Cloud infrastructure.  What is the point of re-inventing a whole array of basic services which are likely to be incompatible with anything else available when you can just use those already built by someone else who is much larger, better capitalised and who already has market traction?  The majority of ancillary tool vendors who develop tools to extend DAM solutions nearly always include an edition which is compatible with Dropbox.  They are now becoming an interoperability ‘standard’ solely by virtue of their size and reach.  As such, this argument has some commercial logic to it – at least until you examine the longer-term implications.

The ‘for free’ phrase in Ramon’s article should offer some portents of trouble ahead, especially viewed in the context of the recent news about Facebook and their mining and exploitation of user data via applications that were also offered ‘for free’.  Not too long ago, I was approached by some people who had the idea of building a DAM based on Dropbox using their API in the manner that Ramon describes.  We did an analysis which considered the investment opportunities and risks of using this kind of strategy.  As might be expected, the cost argument was a highly compelling one, however, the big risk was that this could turn into not much more than a digital sharecropping business model.  Those who pursue this strategy cede control over their customers and the core technology to Dropbox, who take the role of the Lord of the Manor.  If Dropbox deem that DAM presents a more interesting business proposition than they once thought, they can pillage their tenant farmer’s lands and do away with them relatively easily and far more easily than Cloud infrastructure services providers like Amazon etc who would have to do some work before they could offer a direct alternative themselves.

There is an ignominious history of larger tech vendors competing with their own channel partners when they discover that they might have something of interest to them and it seems possible that this could happen here.  If the extent of the vendor’s ambitions is to operate an entity which provides them with an alternative to paid employment (and where they are willing to risk losing everything they have worked to establish in a potentially very short period of time) this might be acceptable, but this is not a platform on which anyone can build a sustainable and scalable business.  This is moving from having a product where you own the IP and which has some prospects for growth into becoming something like a consultant for-hire (and you can take it from the author of this article that you won’t get rich with that strategy).  The software market is such that not many customers are likely to be willing to pay by the hour for someone to provide them with working product.  They will want their cake (the fully functional DAM solution) and to eat it (properly supported and all for a fixed and highly competitive cost).

From a purely technical perspective, the other issue to contend with is what happens if Dropbox decide to change their API protocol?  This has happened in the past and although they give notice periods, they are not required to do so.   I suspect many vendors will eventually take up the Dropbox option anyway.  Many might be those I referred to earlier who operate in some other market who see this as an expedient and low-cost method to start competing in the DAM market.  If there is one clear trajectory which points towards the demise of large numbers of dedicated vendors, however, it will be when they relegate themselves to becoming Dropbox implementation consultants.

Currently, a lot of DAM vendors are in a far more financially secure state than they would have been a decade ago.  To an extent, established DAM software businesses can still enjoy years of profitability with little or no investment in the platform and only retaining a minimal support resource – this is the sleepwalking phase which is alluded to in the title of this item.  Without anything to differentiate themselves, however, that is likely to be eroded incrementally to nothing over a period of time.  Many firms might not care and could be willing to see out the next five years seeing a gradual managed decline in their revenues.  I don’t think that is universally the case, however and there are many companies that are far more ambitious than that.  With that in mind, they should carefully consider whether moving the farm to the land owned by Mr Dropbox is a wise decision for the long-term sustainability and growth prospects of their business (which in quite a few cases is also likely to also be their biggest financial asset).

Conclusion

Control, centralisation and the relentless eradication of unique selling points in the DAM market are the overriding themes of this piece.  For the reasons described in the preceding section, I do not believe that handing over ownership of a DAM vendor’s digital infrastructure to Dropbox, Amazon or any other cloud services operator offers anything like long-term stability – the opposite, in fact.  Neither, however, would I argue that entirely eschewing these services and hosting bespoke products with private data centres or on internal network is a very good strategy either.

To survive and prosper, the DAM market needs a better settlement than is currently being offered.  While this might superficially appear to be only the concern of the vendors, the implications touch everyone who has a stake in Digital Asset Management, including end users and investors who are strategizing about whether to take positions in DAM technology.

If DAM software platforms either disappear or become an amorphous blob of homogeneous functionality which clings to the centre of the bell-curve, they will end up offering limited value for a large section of end users and demand will fade away as a result.  Some calculated risk-taking and new capital to back it up is now urgently required, especially as those who currently have the means now appear to just be washing money between their positions rather than actually investing in DAM innovation.

It is exceptionally easy to criticise DAM vendors (and many of them do themselves absolutely no favours in this respect).  Simply making a critique of their poor decisions, however, is facile and nihilistic.  Offering cynicism alone (while acknowledging that it can generate some entertaining copy for DAM trade publications) is of limited practical value.  With that in mind, in the second part of this article, I consider some solutions which I believe could avoid the potential outcomes I have discussed in this piece.  In the meantime, I welcome any comments on my conclusions, whether you share my view, or hold an alternative one.

Share this Article: