{"id":1601,"date":"2013-01-15T00:00:00","date_gmt":"2013-01-14T23:00:00","guid":{"rendered":"https:\/\/wwwneu.strehle.de\/tim\/weblog\/archives\/2013\/01\/15\/1548\/"},"modified":"2013-01-15T00:00:00","modified_gmt":"2013-01-14T23:00:00","slug":"1548","status":"publish","type":"post","link":"https:\/\/www.strehle.de\/tim\/weblog\/archives\/2013\/01\/15\/1548\/","title":{"rendered":"My thoughts on DAM value chains"},"content":{"rendered":"

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<\/a> describes the current market, with literally dozens of similar vendors \u201ccommit[ing] major proportions of their development team\u2019s time [\u2026] replicating functionality that a section of their competitors already offer so they won\u2019t be seen to be falling behind in RFPs and pitches\u201d. They think that this situation might change when platforms emerge that allow combining software components from different vendors: These \u201cvalue chains\u201d would allow customers and integrators to \u201creview, select and assemble custom applications using a variety of component choices available\u201d.<\/p>\n

I agree with their market analysis (isn\u2019t the Web CMS market similar?), and the \u201cvalue chain\u201d theory sounds good. It reminds me of social networks, a market with a small number of competing platforms: Your \u201csocial\u201d application or feature will have to integrate with at least one of Facebook, Google+, Twitter or LinkedIn to be broadly adopted.<\/p>\n

As a DAM software programmer (or \u201csoftware architect\u201d, if you\u2019re into fancy titles), I\u2019m wondering how this would turn out in practice: Would there be a \u201cFacebook of DAM systems\u201d, 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<\/a> is an example of the former, Nuxeo IDE<\/a> of the latter.)<\/p>\n

For the vendor willing to go the \u201cvalue chain\u201d route, it\u2019s 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\u2019s 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.)<\/p>\n

Integrating software that runs as a self-contained executable is a lot easier \u2013 that\u2019s why many DAM systems already make use of Solr<\/a>, Tika<\/a>, ImageMagick<\/a>, Ghostscript<\/a>, FFmpeg<\/a>, ExifTool<\/a>, dcraw<\/a> and the like. Maybe there\u2019s 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\u2026) Adobe being one of the exceptions, they\u2019re large enough and are trusted by the DAM market (although quite a few of their integration offerings promised too much or were later abandoned).<\/p>\n

Software integration can happen on several levels (see my old post on the five faces of a web application<\/a>). Here\u2019s some thoughts on web services, data models and UI components:<\/p>\n

Web service APIs are an important part of integration work (mostly backend to backend, sometimes user interface to backend). CMIS<\/a> promises to standardize APIs for ECM and DAM use cases, although I personally don\u2019t like it \u2013 it seems too complex; I believe standards can and should be simpler, otherwise they won\u2019t 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\u2019s not go back and overcomplicate things.) But I think backend API integration is the area that is most easily covered. IFTTT<\/a> is a nice showcase of what\u2019s already possible. (By the way: In addition to a web service API, our DC-X<\/a> software comes with a host of Unix command line tools for easy data import\/export\/manipulation. The Unix pipe<\/a> is the grandfather of software integration.)<\/p>\n

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<\/a> in HTML. This offers both a nice human-readable representation of the data, and complete, machine-readable data that you can peek into via \u201cview source\u201d.)<\/p>\n

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\u2019t standardized yet. But things like Mashups<\/a>, Portlets<\/a>, the Google Gadgets API<\/a> and Web Intents<\/a> 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.<\/p>\n

This is very interesting territory. I think of it as the \u201cconsumerization of software integration\u201d. 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\u2019m looking forward to how this will play out (and what role our company<\/a> will play), and to the follow-up posts promised by DAM News (there\u2019s already one on Asset Manipulation<\/a>).<\/p>\n

P.S.: The book What Would Google Do?<\/a> by Jeff Jarvis gives the advice to not offer a product, but \u201cbecome a platform\u201d instead (to help users create their own products)\u2026 Recommended reading.<\/p>\n

Update (2015-04-29):<\/em> See my blog post Web app interoperability \u2013 the missing link<\/a>.<\/p>\n

Update (2016-03-08):<\/em> My follow-up blog post System architecture: Splitting a DAM into Self-Contained Systems<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

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 \u201ccommit[ing] major proportions of their development team\u2019s time [\u2026] replicating functionality that a section of their competitors […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_share_on_mastodon":"0"},"categories":[1],"tags":[],"class_list":["post-1601","post","type-post","status-publish","format-standard","hentry","category-weblog"],"share_on_mastodon":{"url":"","error":""},"_links":{"self":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1601","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/comments?post=1601"}],"version-history":[{"count":0,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1601\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/media?parent=1601"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/categories?post=1601"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/tags?post=1601"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}