The Digital Asset Management Specialisation Debate

Last month’s CMSWire DAM Tweet Jam included some debate about whether specialisation in DAM was becoming more or less prevalent and if it was a positive development or not.  The summary of this discussion (and others along similar lines) seems to revolve around three aspects:

• Horizontal specialisation
• Vertical market specialisation
• Platforms vs dedicated applications

I tend to side with specialisation as the way forward for DAM and, indeed, all types of software. In my view, it is preferable to have products that fulfil one task and do it very well, rather than a more wide-ranging application that is unsatisfactory across lots of different capabilities. As I will discuss, however, that is a somewhat generalised and facile analysis which is, itself, not specific enough. The reality is more complex when you start to pick through the various inter-dependent factors.

Horizontal specialisation

This is what you might alternatively term, feature oriented specialisation. In DAM, this often takes place on the asset type axis, so some systems will be more oriented towards photos, videos, audio etc Business functions such marketing or archival might also be points of differentiation. At present, the majority of end users are still looking for a single product to deal with all their needs. This is partly because the procurement process of obtaining multiple DAM systems, with different service and support options, plus complications like multiple accounts etc all make doing this an unappealing prospect. End users quickly grasp this and prefer to avoid the issues by buying a single solution so they can tick DAM off their list of enterprise applications and move on to other tasks. Not long after they implement DAM initiatives, they often find themselves wanting to further break down the problem into its component parts. In other words, their perspective on DAM changes once they start properly engaging with it and understanding the issues that really affect them, as opposed to the hypothetical scenarios they envisaged pre-implementation.

I think there will remain a market for non-specialist DAM applications, but suppliers staying in this shrinking segment will find themselves outsourcing more functionality to ancillary vendors who provide the key niche features that their users are increasingly asking for. This already happens now to a lesser degree than it probably soon will. Most web based DAM products use third party video players developed by someone else and we have mentioned some of the collaboration tools like Concept Share and Aproove (to give just a few examples) a number of times on DAM News.

My expectation is that the more vendors will develop specialist skills in key features that negate the need for them to buy these skills in, further, a market may emerge where they can offer these to others. The B2D market is still in the earlier stages of formation within DAM, but as with other related fields like Marketing Automation, it is easy to see how it might become more important over time.

Vertical market specialisation

Vertical specialisation is easier to understand, but harder for vendors to practically manage, especially, if they need to support multiple verticals. Common examples in DAM include: Architecture/Engineering/Construction (AEC), Sports, Entertainment, Law Enforcement and Culture/Heritage. These all tend to be sectors where a lot of visually oriented assets like photos or videos are an integral part of an organisation’s operations.

Most modern DAM systems will support extendible metadata models where custom fields can be defined to represent multiple metadata schemas, but, they may not be versatile enough to cater for some of the verticals described. Earlier this year, I wrote an article about DAM and CMS (Collections Management Systems) where I described a few of the challenges with using DAM on museum or preservation oriented projects. That sector can sometimes be one of the more complex ones from a metadata perspective and I have noticed that a number of DAM vendors now appear to be partnering up with firms who are dedicated to this field so they can stick to DAM.

Sports can be another challenging vertical with demands that put DAM solutions through their paces. As part of my consulting work, I have a baseball client and while the video encoding and some playback aspects are feasible to handle generically (up to a point) there are highly domain-specific subjects like Sabermetrics (analysing players based on their performance statistics) which the users are starting to need to cross-reference with footage. These are just as important as the assets and, as metadata, both elements are effectively becoming two sides of the same coin. Integration between the custom MIS and the DAM solution I am involved with has now become a hot topic. The client also has multiple DAM solutions in use across the business. It is impractical for them to replace them all with just one application as the needs of different groups of users are too diverse and coordinating a project of this scale would be expensive and risky to undertake. Integration between them, however, is a more credible proposition since it enables separate solutions to be managed in an independent fashion while still enabling selective exchange of data on an as-needs basis.

The examples I gave above are fairly obvious ones, but even with what are considered more homogenous usage scenarios, e.g. marketing, there are some wide disparities between requirements. For example, B2B marketing departments tend to deal with smaller volumes of branded promotional material since they usually advertise through consumer channels less, however, they also have fewer personnel available to deliver campaigns. Their issues are more about providing self-service facilities for colleagues involved in sales pitches so their time is not monopolised with basic requests for common assets. By contrast, B2C marketers have longer media supply chains involving many different participants. Their concerns are more about ensuring brand consistency and delivery of up to date materials to everyone who needs to get them (e.g. printers, design agencies etc).

During the CMSWire Tweet Jam, there was some discussion about whether vertical specialisation was really necessary. As organisations expect to leverage more from their investments into DAM solutions, I cannot see how user needs will be adequately addressed any other way. In order to manage this effectively across multiple verticals, vendors will be obliged to partner (and integrate) with a range of applications which only exist to service a given vertical. Once you start a systems integration exercise, you effectively commit to becoming experts in the corresponding application (or at the very least, quite knowledgeable about it). All the time vendors have customers that require them to interoperate with a given system, they need people available who understand it to maintain support for the combined functionality. At that point, those vendors have (consciously or otherwise) started to develop vertical specialisations, even if they did not plan to do so at the outset of their involvement in a given DAM implementation.

I can acknowledge some elements of truth in the argument that DAM solutions will still remain generic and applicable across verticals while it is specialist applications dealing with each segment that will fill the functional gap. Noting the point about integration, however, it seems hard to see how a relationship between two applications can be maintained over the long-term without both affecting the development of each other. A further possible emerging trend is those same specialist applications assimilating DAM functionality themselves (so the DAM components becomes part of the specialist application rather than a classical integration exercise). In this sense, there is no such application as a dedicated DAM system any longer, only DAM-like features which depend on a common platform to communicate – which neatly brings us to the next point.

Platform vs dedicated application

This is one of these debates which oscillates in a tidal-like fashion throughout the history of the software industry. There are some alternative approaches to the platform vs dedicated application discussion which suggest the two are not as mutually exclusive as they might first appear. A lot depends on the business strategy and ambitions of the platform vendors and how well they can assemble networks of partners to fulfil needs that are currently addressed by dedicated applications.

Platform vendors want to emphasise the benefits of having a common application infrastructure. The theory goes that by purchasing a core platform from a single vendor who can mandate certain requirements from dependent applications (or provide them, themselves) end users can get advantages like consistent user interfaces and application integration facilities to exchange data in a unified manner.

This appears reasonable, but a lot depends on the execution, modus operandi and whether the vendor’s revenues from the platform itself are sufficient to avoid them being tempted to stick their fingers into too many different pies.

With a multi-faceted subject like DAM where there is a built-in tendency towards specialisation and fragmentation anyway, platform vendors get into a trade-off situation. If they make their DAM modules more functionally rich and able to answer many more of the esoteric user needs, they become steadily more divorced from the rest of the platform and harder to maintain. If they ignore many of these requirements, they run the risk of not being able to offer a DAM solution that is usable by a sufficient number of prospective users. At present, the favoured approach from platform vendors seems to be a PR offensive to try and persuade end users that they don’t really need the extra DAM functionality anyway.

That does not seem satisfactory to me and I cannot foresee them being able to maintain that approach without losing out to specialists – as happened a decade ago in DAM.

There is another approach, which is sustainable and could offer the best of both worlds. The platform vendors will need to be willing to let others into their party and provide them with tools to build specialist DAM functionality for them while they provide the lower level facilities they can take advantage of. With platforms, the clue should be in the title: stuff is supposed to stand on top, not get absorbed by them. The nature of those service objects should be determined by those who choose to develop for it (who presumably will take their cue from what their own customers are asking for).

Many (maybe all) platform vendors are likely to claim they already do this, but there seems to be conflict between them wanting to provide application to run on their platform or offer lower level services to let others do that for them. In part, the former scenario maybe due to a need to demonstrate their capabilities, otherwise, they are just giving third party developers and channel partners a bag of tricks and expecting them to get on with it, but the point at which platform vendors are supporting their partners as opposed to directly competing with them is a blurry one.

Some platform vendors seem to understand this, but they are more likely to be very large operations whose interests are wider than DAM or ECM. An example is Amazon. I do not necessarily mean their hosting platform, but the whole range of value added services they are steadily introducing. Myself and Naresh have highlighted in the past on DAM News how they are silently muscling in on many aspects of what traditional DAM vendors might consider well within their sphere of interest (such as video transcoding and workflow services). Earlier this week, I covered the latest release from Widen and one of the stand-out points was how they were leveraging more of the services offered by Amazon to fulfil needs. They are not the only vendors to do this and as discussed in that article, this strategy is also not without risk for vendors (nor their users by proxy). But, with that said, the focus is clearly more on service oriented architectures and letting others work out how to fit these components together to address a specific user requirement. This has to be how platforms can manage a sustainable long-term future, the question is whether they have the capital resources and courage of their convictions to see it through.

Conclusion

This debate is likely to become a noisier one in DAM circles over the forthcoming years. I expect to see further attempts by some market participants to aggregate what they offer to try and corner an ever-expanding market. This is folly, in my opinion and they will find it necessary to then sub-divide their products into more modular offerings that precisely address user need, i.e. they end up specialising anyway.

At the same time, those who have carefully selected their niches will be able to dominate them and profit as a result. Ironically, some of those interests may then decide to link up their areas of expertise to enable them to compete with non-specialists at their own game. At the point they do this, they also then become at risk of being subverted by more specialised competition.

As should now be clear, specialisation in DAM is less a debate and more an on-going multi-act theatrical saga with numerous unresolved plot twists!  There are entropic characteristics to all types of software system, DAM  is no different in that respect and I believe that will provide built-in momentum towards increased specialisation.

Share this Article: