A Simple Technique For Cloud DAM Customisation Without The Need For Unique Instances

This feature article has been contributed by Ralph Windsor, Editor of DAM News and Project Director of DAM Consultants, Daydream.

Recently I have been working with clients who have started using Cloud/SaaS DAMs (or plan to).  All of them are migrations away from older product platforms, some that were more conventionally hosted as single instance solutions and others that were on-premise.  The cloud vendors who are replacing their legacy counterparts are a mix of mid-range and higher-end DAM systems (as measured by price points).

One issue which comes up a lot is a need to customise product because it lacks some key element of functionality or has a user interface issue which will pose a problem (for one reason or another).  To an extent, it may be the case that DAM users who are motivated to call in consultants like myself to assist them have obscure or unusual requirements, but in my experience, this happens with all DAM initiatives.  I have about 25 years experience of implementing DAM solutions and I can’t recall ever having a client who did not need something that no one else had asked for previously.  Digital Asset Management is an abstract activity which is highly conceptual in-nature.  There isn’t very much tangible that users get at the end, in contrast to something like Web Content Management where the output is something visible (web pages etc.).  ‘Organised assets’ is self-evidently a highly subjective description.  As such, even if the vendors were exceptionally skilled when it comes to application architectural design there will always be something missing.

The way this problem often used to get solved in the old days was for either a custom edition to be created or (if feasible) some complex configuration to force the DAM app to deliver the required behaviour.  As David Diamond talked about in his DAM News interview last year, with on-premise DAMs this wasn’t so difficult to deal with as the customer could decline the upgrade or defer it until any issues or conflicts with their partially customised edition were resolved.  With Cloud/SaaS DAM this isn’t an option.  Although the end-user thinks they have their own dedicated DAM, this is an illusion created by the software and the reality is that ‘their DAM’ is shared with all the vendor’s other clients.  For this reason, when these all-too-frequent obscure requests come up, many DAM vendors will respond with something like “we can’t do that, this is a SaaS platform we can’t change this just for you” (or words to that effect).  To try and work around these problems, modern DAM systems have huge swathes of configuration settings, but even then, they still don’t cover every eventuality, for all the reasons discussed.  End-users are often forced to just wait and hope the vendor’s roadmap catches up with what they need their DAM to do.

As regular readers will know, at one time, I used to be in the DAM systems business (and even further back I used to develop them too).  About 11-12 years ago, when my employer was still offering product we were running into this problem even back then, it is not a new one.  Ideally, we wanted to have just one platform that could be used by everyone rather than maintaining many different editions (while still having the flexibility to apply customisation which was ring-fenced from the rest of the core DAM).  In this way, we could upgrade everyone but the custom functionality would be unaffected – which is an identical problem to what vendors and their users have now.  As is so often the case in DAM, the actors and scenery may change, but the underlying plot remains the same.

We devised a very simple technique which enabled us to do that and this will work equally well with Cloud DAMs also.  I have seen something like it on a very small number of DAM systems, but too many that don’t, or if they do, the vendors have made it unnecessarily over-complicated.  I shall describe how this works in the remainder of this article.  I will endeavour to keep the descriptions as simple as possible but this is somewhat low level and technical in-nature.

Firstly, this depends on having a DAM with an API (and ideally a comprehensive and fully featured one).  An API-First DAM is perfect for this and there are numerous reasons why these platforms are preferable to those that are not, but even a conventional DAM with an API that has been retro-fitted this can still work, albeit with less flexibility in terms of what can be achieved.

Fairly early on into the development of our web-based DAM, we worked out that we needed to keep the branding element of each instance separate from the core of the application so it was easier to add in custom graphics, change stylesheets etc. to cope with the demands of the corporate marketers and brand managers we were increasingly encountering.  We kept a folder called ‘brand’ where all this stuff could get stored.  When a general upgrade was deployed, the ‘brand’ folder got left alone and was not touched so the branding of each edition did not get overwritten.  Our solution to allowing customisation for each client was to add an empty file which got ‘included’ in every page of the DAM application.  This was stored in the ‘brand’ folder.  If a client needed custom functionality, it was implemented client-side using a combination of the API and JavaScript/JQuery, which allows the layout and presentation of web pages to be manipulated after they have been loaded.  I gather there are a few alternative options available these days and JQuery is not quite as ubiquitous as it once was, however, the basic principles are the same irrespective of what library gets used.

Below is a conceptual diagram of how all this worked:

With the above model, we could neatly separate the custom part for an individual client from the rest of the application and update the latter without affecting the former.

This technique proved to be incredibly useful and allowed not only ourselves to cope with a lot of different client requirements without customising the core DAM, but also gave our more tech-savvy clients access to a lot more flexibility also.  For example, we had a design agency who had in-house client-side developers, they built a corporate style guide for on top of the DAM and it carried on working with no issues, even though we upgraded them to a new edition numerous times.  They didn’t need to wait for us to add corporate style guide functionality to the DAM.  More or less every custom requirement where it would have been impractical (or impossible) to modify the core platform we were able to work around using this technique.  This included everything from user interface changes to complex integration tasks where data had to be fetched from third party systems and dynamically inserted into the DAM user interface.

As is to be expected, there were still issues to contend with.  One client was a museum who were using our DAM as a Collections Management System with a lot of third party integration and there were some upgrades that caused these to break, but compared to the pain of an entirely custom solution, these were manageable.  The other issue was security and accessing the API, but we were able to successfully solve this without exposing clients to unnecessary risks.  Our API used a temporary session token which would work for a set period of time before the user had to get a new one.  We bound the session token into each page (server-side) and added a client-side JavaScript function call which could be used to retrieve it.  This avoided the need to store passwords and persistent tokens in the client-side page code (which would have compromised security).

This was functionality developed over a decade ago (circa 2008-09) in an era of files and FTP clients.  There is no reason why with a modern SaaS/Cloud DAM these ‘include’ files could not simply be fields in a database (with a unique one for each client instance).  Administrator-level users (or any other specified user type) could then modify these areas by simply copying and pasting their code into text area fields and saving them.

I don’t have an exact recollection of the development time required to build this feature, but it was of the order of about a day, including testing.  For those DAM vendors who make extensive use of implementation partners, this method offers considerable potential to allow their products to be modified, but in a fairly low-impact and straightforward manner.  Even for those that do not, rather than having to tell clients “no we can’t do that, we’re a Cloud platform’, this offers a fairly simple workaround and potentially permits the client to organise these customisations themselves, which is simply not feasible currently with many Cloud DAMs.

I have seen some far more advanced and complex methods of achieving the same outcome as I describe above and to be fair they offer a range of other capabilities that this very basic technique does not, however, as a baseline that could be implemented by virtually every actively maintained web-based DAM system currently available, I believe it offers some compelling benefits.

If any vendors would like to talk further about this, either leave a comment below or get in touch with me.