The Need For DAM Architectural Strategy: Seeing The Bigger Picture And Doing Something About It
It is a month since we published the What’s Holding DAM Back? series of article which was written by Jeff Lawrence, David Diamond and myself. Previous to that we published, our critique of current DAM innovation which used Jeff’s CMSWire article as a primary source. There have been a some follow-up items and others which are not in response to them, but do have relevance. One example is the following which was written by Lisa Grimm on her personal blog:
“To summarize, my view is that there is a lot of truth in each article, and it’s something of a vicious circle. DAM vendors (or vendors that have decided they have a DAM solution, even if it’s far from best of breed) aren’t incentivized to innovate because the clients don’t demand it. Clients don’t demand it because they have systems that can be difficult to use, and therefore hard to build a business case around further improvements when they’ve already spent their initial budget – not infrequently on the ‘wrong’ system, so they are essentially starting from scratch again when they can afford to ‘go shopping’ once more. And much DAM media is so internally-focused that the ‘right’ people in organizations that need DAMs don’t even know it exists. It seems that one solution would be for DAM vendors to seek out long-term DAM managers and librarians for product management roles – people who live and breathe the tools, and who understand the importance of standards – to really push the next generation of DAM solutions.” [Read More]
I would agree with this description of the issues. The DAM problem is more complex than people think, it is also becoming larger and more critical as the volume of digital assets starts to ramp up more steeply than it has done before. The vicious circle Lisa refers to is getting tighter and is in danger of becoming more like a noose that has the potential to choke off the prospects for the whole sector. On her point about DAM managers and librarians being well placed in product management roles to help vendors build more relevant solutions, I agree with that also, but I think the problem has a wider dimension which not enough people are understanding yet, and they will need to before adequate progress is made.
A big issue with DAM innovation currently is the lag effect that has developed from vendors copying functionality ideas from each other. They do this because the users don’t really understand what they need a DAM solution to do and derive aggregated lists of functionality based on looking at numerous vendor websites. This is like buying a cake based on the number of different ingredients it contains, with a false assumption that having more is going to make it taste better. The vendors get these lists reflected back to them and want to make sure they aren’t going to lose points on evaluations. So they spend large sections of their development budgets reproducing what they think the other team has which lost them their last pitch. This is another aspect of the vicious circle mentioned in Lisa’s article. When I talk to vendors, they usually agree with me about this point, but then proceed to carry on doing it anyway. The DAM software market is stuck in a rut of its own making – we did say this was on the cards two years ago with our series of articles on the DAM Value Chain. This hints at the nature of the problem and a way to fix it that does not involve the current market blowing itself up, which is a point I will return to later.
The other article in response to the innovation items was by Emily Kolvitz, who is one of the authors of the DAM directory along with Deborah Fanslow and Ian Matzen. Coincidentally (at least as far as my understanding goes of people’s job titles goes) Emily appears to have a product consulting/management position with vendor, Bynder of exactly the kind Lisa was describing. Below are a few quotes:
“Recently there has been a lot of critique in the DAM Industry as to product development and innovation for the future, specifically in what we’re doing wrong. And, as humans, it is our natural tendency to look for what is wrong with something or perhaps what is more desirable. If we know this, then the logical next thought is to spend some time making DAM desirable: less clicks and more wow with products and features that capitalize on metadata and information governance best practices without trying to explain to someone why it’s important or what is does.” [Read More]
Later, Emily says this:
“Transcendent technologies that surprise and delight the end user are not necessarily built on product suggestions. It requires vision for what could be and not just what someone is requesting.” [Read More]
That is exactly right, but it is also what is not happening currently. There was plenty to not like about early prototypical DAM solutions (and having been responsible for developing some, I am well aware of all the numerous flaws that many had). One key advantage then, however, was that there were no user expectations about how something was supposed to work, so solution developers had a lot more freedom about many aspects of the product design than they have now. There were user suggestions, but they tended to be directed towards what they wanted to achieve rather than how a particular feature might be realised. If you were building DAM technologies in the 1990s, you had to have a unique vision of where you planned to go because there weren’t very many other examples to copy from (certainly good ones, at least). That meant taking a number of risks, some of which had better outcomes than others. The level of capital investment into product innovation by participants in the DAM software market now in 2015 is not being replenished and the return from it is diminishing as a result. Vendors might think they are spending a lot of money on developing features which are new for them but usually they are deluding themselves about how innovative they are, or have to come up with all kinds of weasel-words and corporate marketing newspeak to try to get reality to fit what they have (or have not) done. To re-iterate the point: just because it is the first time your firm has developed a feature, does not, ipso facto, make it an ‘innovation’. The DAM software market has initiated the maturity phase, but without the depth of functional sophistication necessary across the whole market to sustain it. There is a measurable level of dissatisfaction with current products, but denial of that fact by many vendors and a lack of understanding over what to do about it by the users.
“Stop focusing on the ‘new technology’ that is going to come out from Google or Facebook to overtake the DAM industry and focus more on a culture of innovation that allows the end user to collaborate, work more efficiently, create, and share without the boundaries of our current technology systems and the constraints of what you may or may not think is possible.” [Read More]
I agree with this point also, but to get to that stage, the vicious circle problem referred to above has to be unwound. The recent upsurge in interest in DAM from marketing departments is a relevant example. I see a number of marketing-oriented DAMs and they are beginning to resemble corporate style guides or interactive ‘brand books’. It is reasonable that software sponsored by marketing teams should fully reflect the brand of the sponsoring organisation, but there is a blurring of the form and function which is creating some confusion where an operational problem (‘we can’t find all our stuff any more, it’s costing us time and money’) is being converted into a skewed hybrid marketing/brand project where the latter is given prominence over the former. If you operate a marketing/design agency where regular refreshes of corporate communications material are the bread and butter revenue of your business then this isn’t a problem, but from a DAM strategy perspective, it is not ideal to have to raise corporate media archives to the ground every few years and undergo the potential disruption and cost of data migration each time. If a digital media supply chain infrastructure is required (and I don’t hear many who argue against that) then it needs to be one which can be maintained for a far longer period – not a ‘website’ that gets trashed every three years after a logo update or agency roster review.
To meet everyone’s objectives for this type of requirement, I do understand that both form and function need to be addressed, but there is a set order that has to be followed to do that effectively. To put this in simpler terms, you don’t start decorating your house before the walls have been built and if you try to then usually you end up with a lot of mess and paint everywhere.
A few years ago, there was an article in The DailyWTF with the title Front Ahead Design (FAD). The DAM software market exhibits many characteristics of FAD principles (and no doubt has its own fair share of certified ‘FADstronauts’ too). For example:
“The essence of FAD is conveyed directly in its name: design your front-end/user-interface first, ahead of everything else. The customer could care less what’s behind the scenes, so long as it looks good and does what it’s supposed to. Deliver a working front-end first and then Do What It Takes to fill in the functionality gaps.” [Read More]
I have to point out to a shocking number of people that this isn’t a serious piece of writing and the advice should not actually be followed. To a point I can sympathise with software companies who might be inclined to utilise these expedient methods as they have to get implementation projects through sign-off stages so they can get the authority to put a bill in and afford to pay everyone. But if we are all collectively in the process of building burgeoning warehouses full of digital assets that are going to need to be both stored for an extended period, tracked and shipped globally, within and outside enterprises then this isn’t a sustainable approach.
The problems in the DAM software industry are essentially architectural in nature (or ‘strategic’ if you prefer) and they are getting more acute as a result of practices like those described in the FAD article referred to above. Enterprise Digital Asset Management is becoming more like a logistics challenge: there are layers to it from a supporting DAM infrastructure of core services through to integration and then front-end interfaces, plus all points in-between. A lot of vendors and consultants in DAM like to use phrases such as ‘Digital Asset Supply Chain’ without demonstrating any evidence of really understanding it, although there is now a growing appreciation of what the term means and its implications. John Horodyski’s article for CMSWire last week had the following paragraph (with the section title ‘House of DAM’)
“DAM systems are technology solutions but DAM strategy is the true foundation for controlling assets. The key variables that make up the strategy include business requirements, staffing considerations, stakeholder preference, preservation and rights requirements. Understanding these variables before choosing and implementing DAM require multiple conversations across the enterprise, which if undertaken positively and with enthusiasm, can have the additional benefits of creating a foundation of support within the organization and platform for future growth.” [Read More]
It is about seeing the architecture of the overall solution and not only that, but the business impact at each different level.
In previous articles on DAM News, I have expounded the benefits of dedicated DAM departments. Not everyone is keen on the idea because they still hold the view that this is the exclusive province of some over-worked corporate photo or video librarian plus assistants (if there are any). If you place Digital Asset Management in the context of business operations, however, so it comes under the remit of the COO (Chief Operating Officer) then this seems to be one method to give DAM the operational focus it requires without sparking off internal arguments about why a non-core activity is being given its own budget. This also frames the problem domain as one that is multi-departmental (i.e. it’s enterprise-wide as John says above). It is understood that there will be some departments (e.g. marketing) who will be more active with DAM than others, but just like a company’s email system isn’t called ‘The HR/Legal Messaging Portal’ (even though they probably need the most sophisticated tools in relation to their use of email) this places digital assets into the wider scheme of the overall business and provides an opportunity to make more informed decisions and identify opportunities resulting from storage and management of digital assets.
The Digital Asset Management industry (by which I mean all of the stakeholders in it, not just software vendors) needs to understand the context into which it will increasingly operate. Other older and more established markets have become more collaborative and multi-faceted nature to solve customer’s problems. It is certainly true that in industries like financial services, logistics or manufacturing, you do still find many very large operators who would very much like to ‘own’ the customer exclusively and will do anything they can to lock them in, however, even in those cases, it is implicitly understood that each of the points in the supply chain need to integrate with each other as the customers absolutely demand it and it represents an opportunity as well as a threat for incumbents. This is what creates the conditions for the kind of competitive innovation that is in the best interests of users and stops the wider market from stagnating and being usurped by other alternatives. Last year, I wrote a feature article for DAM News about large scale DAM requirements with the title: Devising Strategies For Consolidating DAM Solutions Using A Service Oriented Model. In that there is a pyramid diagram showing in a very basic and highly abstracted way the three major types of services needed:
At this point in time, many DAM software firms are operating on the top section only. A few have sub-divided it with some plasterboard partitions to try to offer a wider scope of services, others have inflated the description of what they provide (but without actually changing it very much) and a far smaller number have invested into deeper architecturally-oriented solutions that have foundations at the lower levels. At this point, however, in nearly all cases I am aware of, you have no choice about who you use for what and there is still no concept of asset liquidity to facilitate transfer between systems, much less mechanisms to support it.
When dissatisfied DAM users start looking around for alternatives, what they often find at present is more of the same and very limited differentiation (especially if they remain within the same price bracket). DAM systems all tend to be remarkably similar these days and there is a degree of high cost or risk involved when it comes to migrating, so there is a lot of just ‘dealing with’ the shortcomings of DAM solutions by users (as per the phrase used in the FAD article above). At present, there isn’t anyone from outside DAM making a clear move to corner the market, although potential warning signs do appear periodically. In Emily’s article referred to above, she makes reference to Google and Facebook and I would agree with her advice to stop waiting for them to arrive and ‘disrupt’ the DAM industry (in the non-pejorative sense of that word). I can’t see them being interested in DAM either, as a market, it is too small and complicated to be worth them bothering with. Amazon and perhaps Microsoft might be willing to sell some DIY-motivated users a subset of the tools needed to do the job themselves, but they will be on their own in respect of supporting their creations. This doesn’t mean there are no credible threats to the current DAM software market, however, just that circumstances do not yet make it commercially justifiable. That might change over the longer term, but when, exactly, is not something I care to try and quantify.
My expectation is that profits at many DAM vendors are likely to have been improving quite a lot in the last few years because the marginal cost of adding new clients has decreased (certainly compared with the hand-to-mouth existence that firms operating in the earlier years would have been used to). The nature of the game in free market capitalism, however, is that if you get one participant (or a group thereof) accumulating a surplus, it attracts more challengers who want a slice of the action themselves and the income distribution curve flattens as a result. So further points of differentiation have to be found as a priority for those who plan to remain in the market for an extended period. I understand that for the owners of many DAM vendors getting told that they have to invest yet more money in product development (a good proportion of which might not be funded by clients and could need to be paid directly out of reserves) might be not exactly be welcome news and worse still, possibly needing to collaborate with current arch-rivals to boot. That is likely to be the price of long-term commercial survival in DAM, however, and it does mean developing a competitive edge that is based more on positive reasons for users to remain with a supplier, rather than user inertia and homogenisation.
It is a common in DAM circles to complain about vendors and dump all the issues at their door. The generic, spam-infused tactics employed by many of their sales and marketing staff (with some notable exceptions) does them few favours in that respect. However, those using their products and services, as well as the consultants who, in turn, advise them need to come to some understanding of how to re-architect and engineer more useful solutions as well: this is going to need to be a collaborative and non-adversarial endeavour where everyone has to participate. DAM isn’t a one-off job where you can tick a few implementation boxes and then leave it to self-manage for a number of years. There are no free lunches on offer; if you are not sufficiently well-informed and assertive about what you want to get out of the exercise, the paid ones may be unsatisfying and not much to your liking either.
Share this Article: