Ralph Windsor and Naresh Sarwan of DAM News have published an excellent article: The Digital Asset Management Value Chain: The Future Direction Of DAM In 2013 And Beyond describes the current market, with literally dozens of similar vendors “commit[ing] major proportions of their development team’s time […] replicating functionality that a section of their competitors already offer so they won’t be seen to be falling behind in RFPs and pitches”. They think that this situation might change when platforms emerge that allow combining software components from different vendors: These “value chains” would allow customers and integrators to “review, select and assemble custom applications using a variety of component choices available”.

I agree with their market analysis (isn’t the Web CMS market similar?), and the “value chain” theory sounds good. It reminds me of social networks, a market with a small number of competing platforms: Your “social” application or feature will have to integrate with at least one of Facebook, Google+, Twitter or LinkedIn to be broadly adopted.

As a DAM software programmer (or “software architect”, if you’re into fancy titles), I’m wondering how this would turn out in practice: Would there be a “Facebook of DAM systems”, a hosted, ready-made application with basic features, and full control over the APIs and UI integration points that others may plug their code into? Or rather a Lego-like toolbox, a development environment, where you start building UI and features from scratch? (Box is an example of the former, Nuxeo IDE of the latter.)

For the vendor willing to go the “value chain” route, it’s not as easy as it sounds: Integrating and reusing software is actually a lot of work. Non-technical people often take it for granted that software components can be, and are, reused. But dependencies on other code, on the data model, storage layer and user interface make it hard. Often so hard that it’s not worth the effort, so you rewrite from scratch or copy and paste and modify instead. (Additionally, software can usually only be reused in applications written in the same programming language.)

Integrating software that runs as a self-contained executable is a lot easier – that’s why many DAM systems already make use of Solr, Tika, ImageMagick, Ghostscript, FFmpeg, ExifTool, dcraw and the like. Maybe there’s something to learn from this list: Open source software and open standards are much more likely to be adopted. Not just because of the price tag, but also because being dependent on commercial software often seems the bigger risk (might be abandoned by the vendor, evolve into the wrong direction, become much more expensive, be badly-supported). And a competitor might not even be willing to sell to you. (All of this has happened to us at one time or the other…) Adobe being one of the exceptions, they’re large enough and are trusted by the DAM market (although quite a few of their integration offerings promised too much or were later abandoned).

Software integration can happen on several levels (see my old post on the five faces of a web application). Here’s some thoughts on web services, data models and UI components:

Web service APIs are an important part of integration work (mostly backend to backend, sometimes user interface to backend). CMIS promises to standardize APIs for ECM and DAM use cases, although I personally don’t like it – it seems too complex; I believe standards can and should be simpler, otherwise they won’t be broadly or fully adopted. (Software development went from C-based SDKs to complex SOAP services to the RSS-like AtomPub, each step a great and successful simplification. Let’s not go back and overcomplicate things.) But I think backend API integration is the area that is most easily covered. IFTTT is a nice showcase of what’s already possible. (By the way: In addition to a web service API, our DC-X software comes with a host of Unix command line tools for easy data import/export/manipulation. The Unix pipe is the grandfather of software integration.)

The data model is a bigger problem: Each application has its own data format and metadata structure. (Examples: Which metadata fields mean the same, do they support rich text, multiple values, additional attributes?) This is usually not a problem for a one-way export to another application, just reformat and drop the information not supported by the receiving system. But a full two-way integration can cause a lot of headaches. (At least a common structure should be doable: I imagine a future where each web application makes all of its data available through RDFa in HTML. This offers both a nice human-readable representation of the data, and complete, machine-readable data that you can peek into via “view source”.)

Finally, customers will want to combine different components in the same user interface. Web-based applications make this technologically possible, but to be usable as a UI widget, features must be specifically programmed with this use case in mind. And web widgets aren’t standardized yet. But things like Mashups, Portlets, the Google Gadgets API and Web Intents point in the right direction. Our bigger customers already express interest in getting or building their own custom user interfaces, a lightweight integration in the browser, powered by JavaScript.

This is very interesting territory. I think of it as the “consumerization of software integration”. I hope there will be enough inventiveness, courage, and incentive for interoperability, that some of the energy poured into duplicating features can be spent improving the user experience instead. I’m looking forward to how this will play out (and what role our company will play), and to the follow-up posts promised by DAM News (there’s already one on Asset Manipulation).

P.S.: The book What Would Google Do? by Jeff Jarvis gives the advice to not offer a product, but “become a platform” instead (to help users create their own products)… Recommended reading.

Update (2015-04-29): See my blog post Web app interoperability – the missing link.

Update (2016-03-08): My follow-up blog post System architecture: Splitting a DAM into Self-Contained Systems.