In Reinventing Digital Asset Management, David Diamond writes about the miserable state of integration between DAM software and the places we want to use our digital assets – “our apps and anywhere else we happen to be — Google plus, a Disqus comments thread, Facebook, Twitter, etc.” Integration with native applications like Photoshop and InDesign is a special topic that I’m trying to stay away from as a developer (not fun at all). But most of the apps we use live on the Web. How well do Web apps interoperate?

A little story: As an “enterprise software” shop, we do a lot of custom development. Each feature to be developed is described in our bug tracker software, including customer and project name. When the developer starts working on a feature, he changes the bug tracker record status from “open” to “assigned” (so that the project manager gets notified of the progress). We also have separate time tracking software. The developer starts a timer there – and has to manually enter the customer and project name, and a short feature description.

Why doesn’t the bug tracker have a simple “start tracking time” link to the time tracker that prefills the required metadata? And a second link for a “show tracked time” report (even better: show it inline)? How about a link from the time tracker to the bug tracker for the full feature description?

In theory, this functionality should be trivial to implement. Both applications are Web based, they even have APIs – I just need to read some fields from their databases (hoping that the data structures are compatible) and inject an HTML snippet into their pages. Hey, I’m a Web developer. How hard can it be?

Actually, it’s so hard that I don’t bother doing it. Like most software, including DAM systems, these Web apps are not built for interoperability (or integration; here’s the difference). You’re not supposed to mess with their HTML output. Software vendors are control freaks, they don’t want you to add glue and features (in part because there are security and performance concerns). And they haven’t architected their software for it (think abstractions, services, components). For example, had the WordPress guys wrapped the Media Library in a well-documented API, all DAM vendors could have swapped in their software much more easily and in the same way. Now each one has to handcraft their own WordPress integration.

There are generic approaches to this problem, though. The Dropbox Chooser and Google Picker are nice “File Open” dialogs for the Web. Portlets and Google Gadgets let you embed “foreign” mini-apps (and for Sharepoint, there’s Web Parts). Web Components are a promising new technology that will probably replace all of the above. Webhooks and Web Intents allow for clever links between Web apps.

(For completeness, some historical background: Component based native software that allows relatively simple, Lego-like app construction was a hot topic twenty years ago. Remember Visual Basic, OLE, OpenDoc, or Interface Builder on NeXT? In Web technology, early Mashups were promising but they mostly remained one-off, short-lived demos.)

It’s wonderful that most information lives on the Web nowadays. The simple and open HTTP and HTML standards, and especially hyperlinks, allow us to build amazing connections. Let’s make use of that potential and move from DAM silos to a Web of information!

Update (2015-04-29): Related: Stefan Tilkov on Web-based frontend integration. See also my earlier post My thoughts on DAM value chains.

Update (2016-03-08): Stefan Tilkov, again – Embrace the Browser, Architect’s Edition (or watch the video of his talk). Excellent, and suits me well since I never loved the SPA (Single-page Web app).

Update (2016-12-21): The good old iframe and window.postMessage() provide a simple means for Web page interop.