Re-Architecting The DAM Software Market For Longer-Term Sustainability

In the previous article of this two part series, I talked about the risks the DAM industry faced in-relation to building on core infrastructure that was owned by other larger suppliers who could exert power and influence in ways that were not wholly positive, including (but not limited to) competing with them.  Other issues, in particular those relating to the lack of innovation in DAM were also discussed.  At the end of the article I said I would propose some solutions that were not simply attempts to try and reset the clock back to a period a decade or more ago.  With all that in-mind, the following paragraph from the first article is a key one:

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. [Read More]

The situation in DAM software right now is a form of fragmented centralisation.  Every vendor wants their application to be the hub of their customer’s digital asset operations.  This is currently restricted to media or content digital assets, but that situation will likely change too given time.

There are a number of characteristics which could define something that is more sustainable for the DAM software market.  Here are several which I regard as being significant:

• Flexibility and adaptability to changing customer needs.
• Transitioning towards decentralised delivery models.
• Specialised and service-oriented solutions.
• Collaboration amongst vendors via interoperability standards.

Each of the above is closely connected to all the others, as such, pursuing one or two of them in-isolation will not yield many benefits.  A holistic approach is essential.

One further point I should make absolutely clear, all the methods described will require radical change to the market.  That will all introduce upheaval and disruption in the classic sense of the word, i.e. it will be uncomfortable and difficult to deal with.  At the end of this article, I will consider some methods by which the required changes can be implemented from a more practical perspective, but first I will outline what I mean by each of them.

Adaptability To Changing Customer Needs

One of the most complex issues that those who implement DAM solutions have to contend with is the wide disparity in the expertise of users and their corresponding requirements.  This is even more difficult for DAM because the heavier users also tend to be the ones who supply large quantities of digital assets for those who use on less frequently.  A lot of vendors try to deal with the DAM user diversity problem by targeting only the largest group.  Typically, this will be those who require ad-hoc single digital assets fairly infrequently (e.g a couple of times per month).  To illustrate what I mean by this, I see many systems that promote their simplicity but then more demanding tasks such as complex multi-stage batch update which are convoluted or simply not possible.

There are numerous Cloud/SaaS DAM solutions which look great – until you have to do something more advanced with them.  While troubleshooting DAM systems for clients which have been in-use for over a year, a familiar story is end-users being told that what they want to do will require professional services or is something that ‘no one else has asked for’.  Frequently, there are alternative products available which do include the missing functionality.  Unfortunately, it is not as simple as just migrating to the  platform which possesses the desired functionality, since it too lacks something else important which the incumbent one already has.   To get the precise combination of functionality they are seeking would involve both buying about ten different systems and be able to seamlessly transfer digital assets between them all.  Clearly, that is impractical (and not only for cost reasons, as I will explain).

The ‘changing  customer needs’ phrase used in the heading does not mean ‘over a period of time’, more that user needs will change from one group to another.  To use an analogy DAM systems are like food outlets that have customers who may walk in and ask for a sandwich, or they might turn up and expect a five course meal.  To deal with this problem, vendors have to choose which market to service and they tend to pick those who want the sandwiches (as there are more of them).  The difficulty lies in the fact that those who have asked for snacks soon ask for something more substantial not long afterwards, at which point the chefs are run-ragged trying to service a huge menu of individual requirements.

Separation Of Front And Back-End Services

One method for dealing with this ever-expanding range of user requirements is multiple interfaces that are tailored to the needs of different groups.  Other commentators have talked about the separation of DAM interfaces (especially the management of assets as opposed to more conventional tasks like searching).  This method is not without its own issues too, but they can be managed (especially if combined with some of the other recommendations in this article).

While simplifying interfaces is legitimate advice, that often implies sacrificing the needs of one group for those of another.  If your user constituency covers a huge range of differing priorities, that is far harder to achieve than it seems.  This is the dilemma many DAM vendors go through and the conflicted nature of what they have to deal with is sometimes apparent to those external observers with some experience of reviewing DAM systems.  Many applications give the impression that they have 3-4 different interfaces, but without any clear separation nor analysis of who they should be targeted at.

I do not believe that DAM vendors will eventually have the required resources to offer both highly flexible and sophisticated, feature-rich interfaces at the same time as servicing the needs of less complex users.  The fact many are trying to (and struggling with it) is contributing to the tail-chasing which is one of the root causes of the lack of innovation in DAM.  To return to my earlier comparison, most vendors try to be fast food outlets for one group of users with less sophisticated needs while also wanting to be known as a fine-dining restaurant for another more demanding set of customers.  Commercially (i.e. in terms of making money selling software) being one or the other makes no difference, it is only a case of which you can operate more profitably.  There is no right answer as it highly context-dependent and it also is not possible to do both simultaneously and economically unless you have access to considerably more investment capital than most vendors possess.

There has to be a sea-change in the provision of DAM software.  It is time that more vendors came to terms with the fact they can’t do everything and some will have to specialise in interfaces and others in services.  Even though I do not agree with the method for achieving it, I must acknowledge that this is contributory to why Dropbox is being suggested as a DAM services provider in the earlier article.  The instinct is correct, even if the method is not one I agree with.

Not only will some vendors need to transition towards only building interfaces, but they will not even be able to offer all of those in use for a given platform.  If the changes I have described come to pass, some firms will become more like creative agencies who specialise in providing interfaces for content and media catalogues (they might even already be one now).  Some time ago, the majority of design firms would have been responsible for producing a ‘corporate style guide’ or ‘brand book’ etc, i.e. a set of guidelines which would also include logos, fonts and other core brand assets.  I can see those kind of suppliers returning and it might be better that those who specialise in software allow it to happen rather than chasing after this business as well.  Conversely, those creative agencies that are contemplating moves into the DAM software business based on a couple of requests from clients might consider it would be easier getting software businesses to take on these challenges so they can maintain focus on their own specialism.

 Transition Towards Fully Decentralised Delivery Models

A decentralised delivery model  implies two attributes:

• Flexibility about who provides a given service.
• Flexibility to decide who you share your data with.

The first is possible now via microservices and Service Oriented Architectures (SOA).  Adoption of these is by no means universal, but they are becoming far more common than was once the case.  There is a growing demand for Digital Asset Supply Chain (DASC) solutions from end users and more DAM software firms are catering for this kind of requirement.  To deliver DASC, a services architecture is essential because each stage of the supply chain has to be at least capable of being dissected, analysed and potentially replaced, without negatively impacting the rest of the value chain.

In spite of this (or perhaps because of it) this has led to political issues which I have discussed on DAM News recently.  These are the same themes as those described in the first part of this series, vendors fundamentally do not trust each other (with varying degrees of good reason).  The cause is because the second point given above about having flexibility in-relation to who users share their data with is nowhere near being fully met.  When service providers say they offer APIs (whether they are DAM specialists or the cloud infrastructure services they utilise)  the choice of what data is made available still rests with the API provider.

The current state of affairs in DAM supply chains is not decentralisation but the fragmented centralisation I described earlier.  In larger DAM supply chain projects where there are multiple vendors who all either directly compete with each other (or who are too close for comfort in-terms of commercial positioning)  battles regularly break out and they are considerably more difficult to resolve now than they might once have been when the enterprise IT department could play the role of ‘referee’ (albeit sometimes not quite an impartial one).

How does this get solved this without returning to hosting in-house again?  I would argue that something like a blockchain offers a practical method of avoiding having any single entity control enterprise data.  Using blockchains to provide interoperability for cloud applications could offer some compelling advantages because it is far more difficult for one entity to acquire a position of complete power and influence over everyone who might need to use this data.

I can acknowledge that many of the current blockchains available are imperfectly implemented and have issues which are going to take some effort to resolve, but there are a some tangible reasons to use them specifically for interoperability.  They offer a neutral area where data can be stored which one party cannot control to the exclusion of all others.  Using a blockchain for everything is clearly unsuitable and some of the hype and opportunistic use-cases do this technology no favours, whatsoever, however, rejecting them solely on these grounds would be as short-sighted as writing off websites in 1999 because of some of the wackier dotcom pitches for venture funding that were prevalent at that time.

For those who disagree, a better answer is required than simply asserting that there are alternative methods.  Such as what?  Are they proposing going back to monolithic enterprise solutions where data is held hostage on a vendor’s cloud infrastructure rather than an in-house IT department?  If not, then what? In a few years’ time, these same cloud services (having captured significant market share and no longer being motivated to innovate nor reduce prices) might start to look very similar to what they have replaced.  If I have misunderstood their critique, I need to see a more reasoned explanation of what other options are available and how they will work to solve trust issues in multi-vendor digital asset supply chain initiatives.

A delivery and interoperability model where vendors do not need to trust each other to collaborate could potentially be hugely liberating for the DAM software market.  The issues I have discussed in the first part of this article would be far easier to mitigate using a decentralised approach. In combination with independent services and interfaces, vendors would be freed from the necessity to provide an entire solution and users could make their own choices about how to combine vendor’s tools in a more precise and targeted fashion.

Specialised And Service-Oriented Solutions

This is an issue which has been talked about on DAM News for nearly as long as I have been actively contributing to this publication (and it closely relates to the previous section).  The logic is conceptually easy to understand: rather than re-building close reproductions of what their competitors already offer, DAM application developers choose areas to specialise in.  As a result, they are able to tackle user problems in far more depth and therefore increase the likelihood that they will make a better job of it.  By being more focused, vendors have greater capacity to innovate because they are no longer tied up maintaining an over-burdened functional stack.

The breadth of activity carried out in DAM solutions is now huge (even at the cheaper end of the market) .  Vendors currently skim the surface of  each of functional requirement, but only to a level which is roughly around the same level as everyone else.  For example, if batch metadata update capabilities are required, there is usually a find/replace facility plus some capability to update a controlled field but usually not much else.  Similarly, with derivatives (or ‘renditions’ to use another description) there tends to be features to resize, re-sample (e.g. change resolution) and some basic manipulation like cropping.  That functionality also rarely goes to a much deeper level.

What many vendors would argue is that their customers don’t often ask for more than that level of sophistication, yet this is similar to the sandwiches vs five course meal point I made earlier on.  Firstly, most end users (when first confronted with DAM software) have masses of functionality to sift through.  One system demo can blur into the next and even experts can find it difficult to differentiate between them.  This effect encourages users to think about ‘the basics’ and ask for simplicity because they can’t deal with the bewildering array of options they are initially presented with.  At some point between 6-12 months after implementing a given system, their needs will tend to get a lot more advanced as they have had more time to understand how to apply the product’s features to their unique set of problems.

At this point, many vendors are faced with three decisions:

• ‘Fork’ the application and build a custom version just for one customer (with all the attendant maintenance problems for the vendor and increased support costs for the customer which this option entails).
• Directly or indirectly refuse the functional requirement and oblige the customer to wait until enough other people ask for it too.
• Try to devise some method of adding it to the core product, but provide configuration features to allow everyone else to disable it.

There are also some hybrid methods using APIs or SDKs where a partner or consultant can custom build something that sits on-top of the core product or as a plug-in etc (a ‘plastic and wood’ as opposed to ‘concrete and steel’ approach).  These can work, but as my analogy implies, they have fragility and can break when an update is made to the core application.

I guarantee that every DAM developer reading this article will have been confronted with a menu of difficult choices like this.  The problem for them is that their customer’s DAM expertise expands as a result of using one and that changes their view of what they need.  That consequently necessitates changes to DAM software and expands the scope of what they must provide.

I read lots of pithy recommendations from people on LinkedIn comments where they advocate the ‘say no’ approach to dealing with customer requirements and propose some kind ‘Feng shui’ approach to application design instead.  If you have long-term customer who needs something to work a given way or their business will be impacted this is hard to adhere to.  Often, the reason they are long-term customers is because they have faith we can solve their problems for them.  I would argue that instead, we as an industry ought to re-organise ourselves so the customer’s needs can be met without it creating a shambolic mess of difficult to maintain software.

If there is both a separation of the user interface and the services as well as specialisation in particular types of service (rather than building everything) then the impact of this issue might reduce.  If one vendor focusses more on renditions, for example, they build some advanced services that will cope with the obscure requirements that customers will almost certainly come back to them with.  At its core, Digital Asset Management is a service, not a product and a major element of the service delivery is consultative in-nature.  This one of the reasons why vendors find it hard to scale up DAM operations using a the monolithic methods they have to rely upon now.

Commercial pressures: having too much to do and not enough time/money/people to handle it are already forcing this issue, but it isn’t happening by choice (much less by design).  For example, I have yet to find a single DAM vendor that has created their own AI image recognition tools, they all use tools built by someone else.  Similarly, as the need for scalable search capabilities that can deal with very large text corpuses has expanded, few vendors have built their own (if any) they all use NoSQL, Elasticsearch or similar solutions.  I am not advocating that DAM development teams reverse that policy, but it should indicate that the trend is more towards choosing your battles with some care.  Modularisation and commodification are becoming increasingly pervasive in DAM due to commercial necessity (as is the case with any industrial process) and more firms should see the writing on the wall and apply it to the rest of their architectures.

I have heard several arguments against a service-oriented method of organising the delivery of DAM solutions where third party components are used, some are practical in-nature, but others are symptomatic of the fear and greed instincts that control the DAM software market.   In the former case, one of the objections to delegating services to a third party is managing risk, i.e. relying on a component provided by someone else who subsequently fails to deliver.  I can see the rationale for this, however, following this line of reasoning to its ultimate conclusion suggests going back to building everything in-house (which I believe I have proven in the preceding paragraphs, is a poor strategy). Risk management is going to become an ever more critical skill for DAM product managers.  The economics of the delivery model are going to require them to find a way to adopt this strategy while ensuring they can protect the rest of the service they are responsible for.

Dealing with the other objections, the greed and fear aspects are evidently more psychological in-nature, but there are some practical challenges too.  The greed element relates to the belief still held by many vendors that they stand a realistic chance of dominating the sector.  There is a peculiar cocktail of hubris, inability to understand the market dynamics at-work and over-optimism that flies in the face of the facts.  Discussing topics with some vendors is a bit like having a conversation with the spokesperson of an authoritarian regime or dictatorship.  I know they are concocting some half-truth to disguise an undesirable reality about them or what they are offering, they know it too and we both understand the situation perfectly, however, the rules of engagement (in their minds, at least) prevent them from admitting it. This is based on a false belief that you can ‘think yourself big’ and if you assert something enough times, it will become reality.  These kind of attitudes and policies (which far too many vendor marketing departments are still keen on) effectively imprison these firms in a fantasy of their own making from which they are unlikely to ever escape.

The fear side of the equation relates to vendors both not trusting each other and concern about losing what limited market share they already have.  In particular, they worry that if they cease offering the whole solution, they will lose pitches and miss out on the illusory opportunity to dominate the DAM market (or face a decline into obscurity).   The other way in which fear manifests itself is a lack of trust about their peers.  Most DAM vendors are small companies by definition (i.e. about 30-40 staff and a turnover of a few million dollars).  Usually the owners tend to be all about the same age (roughly 35-50, give or take either way) and from similar educational and socio-economic backgrounds.  It’s an ironic fact they while they fear their peer group (‘the competition’) they have fewer problems metaphorically getting into bed with corporations who have multi-billion dollar market capitalisations, thousands of staff and who could wipe them out overnight simply by declining their business.

Those firms who offer ancillary tools which are used by DAM vendors have potentially a far greater opportunity than many of their customers.  By providing a toolset which is designed to be integrated with lots of different DAM solutions, the risks are diminished because if one vendor customer decides to use someone else, there are still others who might take their place (and by some measures, there are well over 200 of them in the DAM market alone).  DAM vendors effectively act as channel partners and provide a route to market with a far shorter sales cycle than selling directly to end users.

If you are currently operating as a DAM vendor, ask yourself would you prefer to have a market of 200+ potential customers who will re-sell on your behalf (and generate repeat business for you) or would you rather have 200+ potential competitors who you are increasingly finding it to differentiate yourself from?

Collaboration Amongst Vendors Via Interoperability Standards

This is another topic we have covered extensively on DAM News before.  Unlike some, I do not believe DAM interoperability ‘is doomed’, however, it isn’t going to happen with a couple of conference calls and some well-meaning charter documents.

A few people have written to me about this topic.  As these are private conversations, I will not reveal who made these remarks, but one observation is that a lot of people turn up to get their name listed on these initiatives so that if they do gain traction they can say they were involved but then they do very little and wait for others to make the running for them.

This kind of ‘optioning’ of participation is strangely similar to what happens with end-user DAM implementations: a bunch of people turn up, talk about their favourite subject (which may or may not relate to standards) then they fall silent and disappear again when it comes to doing some work that might yield something tangible.  This has led a number of more active participants (‘the idealists’ as I have heard them referred to) become jaded and cynical about the prospects for DAM interoperability.  The bottom-line is that without some direct consequence DAM interoperability standards are unlikely to get adopted.  It needs to hurt vendors in the pocket before they take notice.

I do not intend to labour this point further, however, I would note that the intersection of the different factors described previously in this document provide the basis for interoperability standards with the required market clout.  They might become a by-product, rather than something which gets invented for this sole purpose, per sé.

There is still a choice about how the transmission mechanism for DAM interoperability standards will be implemented.  As discussed in the last article, it could be via some much larger entity imposing standards on everyone else.  This is not really ‘standards’ in the received definition of the term, instead it’s doing what the larger player does because you don’t have a choice, i.e. they ‘own the DAM market’, to coin a phrase.  Alternatively, it could be a collective scheme like a decentralised exchange for DAM services.  In this case, we will all ‘own the DAM market’, but then we all might end up disagreeing with each other about how to solve the interoperability challenge.  There is no free lunch for this issue and no opportunity to sit back and let other people do the work on your behalf.  If you’re not part of the solution, you’re part of the problem – which is a cliché, but only because it’s true.

Bringing It All Together By Breaking It All Apart

If you were to analyse the current DAM industry as though it were a piece of engineering, it appears to be an exceptionally poorly  designed.  There is a huge amount of duplication, with hundreds of functional modules that are essentially the same.  In mitigation, it could be said there is a certain amount of redundancy so that if one component fails, there are plenty of others available to take their place.  Each of these is incompatible with each other, however, so recovery from a failure would not be particularly graceful.  By most engineering standards (and taken collectively) the DAM software industry has the worst of all words.

In various selection exercises I have been involved with in the last few years, lack of differentiation keeps being mentioned as an issue by end users.  The method favoured by many of them who lack the time, patience or expertise to painstakingly pick through product specifications and RFP responses to tease out a potential edge is to simply use cost to rank prospective suppliers.  If this state of affairs is left to play out to its natural conclusion, it means many vendors will probably go to the wall as they come under increasing margin pressure.  If everyone appears to be the same, why choose the more expensive option?

To move away from that outcome, the industry needs to be deconstructed and incrementally re-built from the ground up.  This is not a recommendation to engage in a collective second system exercise, so I would not advocate completely destroying existing applications and starting again.  Instead, a transitional approach is needed whereby those who want to offer DAM services are neither required to build and maintain everything themselves, nor expose themselves to the commercial risks associated with renting their application infrastructure from some larger entity who could act like a ‘Cloud Mafioso’ should they feel so inclined.

There are a number of key principles (and strategic decisions) which underpin how this might become reality which I would recommend to vendors:

• Decide whether you are going to specialise in interfaces or services. Long-term, you probably will not be able to do both.
• Separate out everything as far as feasible into discrete services, or at least offers and value propositions. Clearly, from a practical implementation perspective, performance issues could impact the extent to which this is feasible, but it should be the starting point for all new functionality unless there is a good reason not to.
• Use a service-based platform for the delivery of DAM and be interface-agnostic (so they could be sold to anyone, even though you might not necessarily do so). Think like all the suppliers you currently buy ancillary tools from such as databases, search facilities, AI tagging, image manipulation etc.
• Look to form alliances and consensus about protocols with peers who are prepared to be cooperative. There will be a lot more than you think as everyone else is in the same boat.
• Carefully consider decentralised methods for sharing data and collaborating with peers – i.e. hard implementations of the protocols referred to. Blockchain currently could offer some potential in this regard, but something else might also emerge.  Be open to any of the possibilities and look at the facts of how they are implemented, not the marketing keywords currently used to promote any of them.
• Stop treating the DAM industry as though it were like a quasi-professional sports competition. No one DAM vendor is likely to become ‘league champions’, even if they waste huge amounts of their investor’s capital on buying up other teams in order to try to do so.  Everyone in the DAM market needs to come to terms with this.

I can imagine that some more risk-averse vendors are going to want to hedge their bets in regard to a few of the above points.  To an extent, I can accept that tactic as a legitimate one, however, it should be a conscious decision and one that can be changed very easily and without a lot of regret if the facts prove otherwise. If someone else is clearly doing a better job, DAM development teams need to be able to do their own form of ‘buy not build’ and lose any pet albatrosses they might have acquired in their own quest for world domination.  Your DAM software brand is probably less well-known than you think.  What end-users care about (above all else) is who can deliver a solution to their digital asset management problems.  They don’t often worry a lot about who or how the industry organises itself to achieve that, only that it does.

Conclusion

I started this article wanting to offer a solution to the deeper underlying DAM industry issues I identified in the first part of this series.  Much of the advice offered is of a similar nature to what I have been talking about for over five years now (and I started forming my opinions on this subject well before then).

In the next few days, I plan to announce a new initiative which I am involved with that might start to see some of the proposals outlined take a more concrete form.  They will be primarily research based, partly because I ended my own involvement in the software implementation business some time ago, but also due to the fact that they depend on the DAM market collectively coming to terms with the issues I have described.

I am not wedded to any of my recommendations in this article.  I have strong views, but I hold them lightly and if anyone can come up with superior alternatives, I am willing to switch allegiances, having given them the same robust analysis that I expect of my own opinions by others.  The most important point is that these topics are openly debated and discussed in the DAM industry.  The worst outcome would be a passive acceptance of the current innovation status-quo.  Most of the people reading this article are (in one form or another) emotionally and financially invested in Digital Asset Management and now the time has come for everyone to start acting like it matters to them by their deeds as much as their words.

Share this Article: