Tim’s Weblog Tim's Weblog
Tim Strehle’s links and thoughts on Web apps, managing software development and Digital Asset Management, since 2002.

Alexia Tsotsis: The Enterprise Cool Kids

Alexia Tsotsis at TechCrunch – The Enterprise Cool Kids:

“The enterprise world evolves from a sales-driven to a product-driven approach. 'The user is now the buyer, and the center of gravity is no longer in IT, it’s actually in the line of business themselves,' says Christian Gheorghe.

[…] [They] focus on intuitiveness and design, awareness of mobile and fresh approaches to decades-old problems. 'The existing enterprise players are building software people tolerate,' as Rosenstein concisely puts it. 'The future players are building software people love.'”

Mon, 28 Jan 2013 08:57:41 +0000

This is your Anti-Productivity Pod

I just discovered this article from 2004, which I can strongly relate to (having worked with headphones for years now)… Jeff Atwood – This is your Anti-Productivity Pod:

“'Staying late or arriving early or staying home to work in peace is a damning indictment of the office environment.'

[…] Changing your work environment, however, is easier discussed than done. I think the only way I could change mine is if I actually quit my job.

[…] It may not be beyond human capacity, but it's hard to envision change when only managers have offices.”

Thu, 24 Jan 2013 21:43:35 +0000

My thoughts on DAM value chains

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.

Tue, 15 Jan 2013 22:23:19 +0000

The Digital Asset Management Value Chain: The Future Direction Of DAM In 2013 And Beyond

Ralph Windsor and Naresh Sarwan of DAM News – The Digital Asset Management Value Chain: The Future Direction Of DAM In 2013 And Beyond:

“As a buyer, you can’t pick and choose features from one and plug them into another, you have to sift through reams of potential options and try to select the least worst choice that has more of what you want and less of what you don’t for a price compatible with your ever-shrinking budget.

[…] The DAM system market when viewed collectively is highly inefficient. Most vendors commit major proportions of their development team’s time (and their own profits) replicating functionality that a section of their competitors already offer so they won’t be seen to be falling behind in RFPs and pitches. ”

Tue, 15 Jan 2013 22:50:26 +0000

Your life's work

David Heinemeier Hansson – Your life's work:

“In an industry so focused on the booms and busts, I find myself a kindred spirit with the firms of old. Places where people happily reported to work for 40 years, picking up a snazzy gold watch at the end as a token of life-long loyalty.

Committing myself to this long-term focus has led to a peaceful work atmosphere and an incredible clarity of purpose.”

Thu, 10 Jan 2013 07:42:52 +0000

D3.js – Data-Driven Documents

D3.js is a JavaScript library for manipulating documents based on data. D3 helps you bring data to life using HTML, SVG and CSS. D3’s emphasis on web standards gives you the full capabilities of modern browsers without tying yourself to a proprietary framework, combining powerful visualization components and a data-driven approach to DOM manipulation.”

Wed, 09 Jan 2013 09:23:47 +0000

fiddleware Subtitles

Subtitles by fiddleware: Easily create subtitles for your videos directly in your web browser.”

Wed, 09 Jan 2013 09:26:41 +0000