At this point in the evolution of DAM, the actual product makes up a relatively small part of most solutions delivered to clients. While investments in training and configuration have always been part of most DAM implementations, customizations and development of purpose-built workflow systems around DAM are becoming the norm. There are still a considerable percentage of users that can benefit simply by implementing a DAM system to gain control of the plethora of content that organizations of almost any size are struggling to manage and control. However, there is significant value to be delivered to an organization by specifying the exact suite of problems they wish to solve. When those problems are document process issues, a DAM solution as a platform and some custom development to address the issues, is a great solution.

Solutions are still fairly different for most clients and often need something a stock product doesn’t have – even when the product is developed for a comparable business or vertical. Being able to customize for a client’s need is pretty much a must have for most opportunities, particularly the good ones. Value is derived by both vendor and client in these instances as the client gets a real solution to their problems, not just a problem like theirs. The vendor benefits from extra revenue to resolve those problems.

DAM as an industry could benefit from some consolidation as there are probably too many players for the size of the pie that is shared. There should really be no place for DAM systems with out pretty extensive APIs and even a robust development community or partner system.

How important providing solutions has become and how dramatically demand for APIs has increased was never more evident then at a partner meeting for Canto’s Cumulus in 2011. Prior to this point, Canto had a Java API which is great but you must be a Java developer and a WebService API, which is even better because it works with any programming language that can consume a web service. This is much better then almost any other DAM system I am aware of, even with these 2 APIs. The web service API was based on SOAP which is an extremely verbose XML based API and, therefore, difficult to use. What really marked the sea change here was that at this meeting, 3 other APIs popped up: Canto released its CIP REST-based web service and 2 partners, Vitras and Aimtec, made it known that they each had web services for Canto as well. The partners web services were REST based as well which is superior to SOAP based web services (simple URL access and leaner JSON responses). So, this DAM system now has 5 APIs and 2 weren’t even developed by the OEM. How cool is that?

Programming is no longer the domain of true developers – good, bad or ugly – and is used daily by anyone wanting to streamline a workflow. It is great to see that a non-programmer can improve efficiency on their own using scripting or simple programming. Systems developed for use by larger audiences, especially audiences with limited computer exposure, are much better created by true developers.

DAM now should be the engine that drives the car. Anyone with a DAM system should be integrating it with any other systems accessing or serving the files within.