Publishing from a Content Hub

Web CMS

Working as part of a sales team, one of the questions that I’m asked again and again – by my management as well as the Marketing department – is “who are your biggest competitors?” For a Web content management system or text analytic tool (Nstein’s WCM and TME respectively), that’s a fairly easy question to answer. In the DAM space, however, because of Nstein’s particular focus upon the Publishing industry the answer is less clear.

A simplified publishing workflow.
A simplified example of a publishing workflow.
Content Hub workflow

With assets stored in a central repository all systems and processes have direct access to them.

In fact, over the last couple of years Nstein has been positioning its DAM offering as a strategic centre-point for publishing workflows – Content Hub seems to be the prevailing (if slightly uninspired) label for this kind of system. Essentially, a Content Hub is a DAM with integration points so that all assets which come into the wider system (the company, publication, etc) are ingested straight into it; all content which is created internally is written directly into it; and then, all systems which utilize, display, edit or distribute content do so from the Hub directly. This is not a new model – it is sometimes referred to as a single version of the truth – however it often represents significant change and significant challenges in environments which have naturally developed around a (fairly) linear workflow. Magazines, in particular, as well as any breaking news publications, tend to have a from A to B style workflow which involves filtering incoming media, bring it together as a publication of some description and then publishing it out. By repositioning the processes and applications along such a workflow around a central Hub, dependencies and bottlenecks are broken down and assets, and access to them, become standardized. As a symptom of this shift, efficiency improves, asset re-use is encouraged and assets, their rights and usage information are better tracked. And by creating packages of content, independent of both source and output channel, features can be efficiently published on multiple channels (such as Print and Web) and new properties can be created cheaply with lower risk.

So, coming back to the original question, the DAM space doesn’t present that many competitors for Nstein (although there are, of course, a few) as few DAM systems have the out-of-the-box capabilities required by the vertical – handling extended metadata, transforming images, re-encoding video, printing contact sheets, managing page content, &c. In fact, the biggest competition in these cases comes squarely from Print Editorial System vendors who would, like us, endorse a Content Hub approach except with their CMS at the centre of the publishing universe.

In some ways both sets of vendors – DAM and Editorial System – are using the same arguments. One version of the truth, certainly. Single workflow and security. To some extent the multiple-channel publishing argument would also be used by both, certainly most Print Editorial Systems come with some option to publish a Web site as well.

These two approaches to the same Content Hub strategy raise a couple of key questions: what is the difference between the two solutions and how do those differences affect the buyer?

The former question is the simplest to answer: A DAM based Hub disassociates itself from the editing and creation of products whereas an Editorial System is strongly tied in to the production process. Take the creation of a newspaper, for example. The collaborative effort needed to construct a modern edition in an efficient and reliable manner relies heavily upon Editorial Systems to manage the agglomeration of the content and design in real time. The question is; should that System be the hub or a spoke?

How do these differences affect the buyer? What are the relative merits of the approaches? These questions are the ones which are being debated and rely upon strategic visions that the publisher may just not share. However, from my point of view, here are the main points.

On the plus side for the Editorial Systems, as they are so connected to the production process, they  can offer advanced and specific functionalities, tying in closely with DTP tools and offering collaborative working features which a DAM cannot compete with.

That strength, however, is also the biggest weakness for the Editorial Systems. By abstracting themselves from the production process the DAMs become far more agile. We can look at a fairly simple example of this in publishing the same content to both print and the Web, a process which should, by now, be a commodity. At its simplest this task should work smoothly in any Print Editorial System; text and images from a print feature are transformed into Web pages and published online. What happens, though, when other media is introduced? Most Print Editorial Systems that I have seen struggle to (or cannot) display and edit video. Maybe they can store them but the advanced features available for print content are gone, as are many simple features such as previewing and usage tracking. Now in many cases, the Print Editorial System may be coupled with a Web CMS (potentially from the same vendor) which does feature better handling of video but in that scenario there are now two production points. That means compromised security, more staff training, more convoluted audit trails. Then when you take audio, Software Flash, or any other format of content that the publisher may use – online or elsewhere – and the problem is magnified.

One solution for the Editorial Systems would be to develop the extra functionality required to handle these formats with the same level of functionalities as the print content which they are familiar with. The obvious problem with that is the effort and available resources required to build and maintain such a suite. So by steering clear of the production process the DAM based systems can handle content in a channel-ambiguous fashion.

Particularly when one looks at the creativity in digital media these days, the strength of agility should be clear. There are the obvious ones: Facebook apps, QR codes, iPad channels, etc. There are also some less well adopted mediums.

In October 2008 Hearst released a special edition Esquire (sponsored by Ford) featuring an e-ink, animated front-cover. Bauer last week released an issue of Grazia featuring Florence (and the Machine) dancing in an augmented reality world activated by pointing your webcam/iPhone at the cover. While this was pretty disappointing in comparison with many other AR examples (such as the great GE ones) due to the fact that the real page was not displayed – more on that in a future post. While neither of those examples where particularly well implemented they definitely show signs of what could become mainstream technologies in the future. The question about adding the functionality to manage the production of publications including these kinds of technologies into Editorial Systems is a far-fetched one. Not only is the investment significant and the road to maturity slow but if a technology ultimately fails to gain mainstream accessibility the investment becomes a wasted one. For that reason companies that rely upon an Editorial System at the core of their business have to wait until new technologies reach general acceptance to embrace them and lose the ability to stay ahead of the curve – at least without excessive risk. In those cases, as with more mundane ones, the channel ambiguous and content ambiguous DAM systems project their flexibility directly on to the publications which use them.

That’s not to say that there are not downsides to using the DAM as the Hub. In particular, collaborative working cannot be handled to the depth that the Editorial Systems manage without their level of detail and understanding of the specifics. And in both cases there are overlaps in functionality; most Editorial Systems have some kind of repository, for example, and many top tier DAM systems integrate well with DTP tools.

Inevitably, those two questions, drive towards the ultimate conclusion of the debate: “Which would make a better Content Hub, an Editorial System or a DAM?” I won’t attempt to answer that directly as I’m obviously biased towards the solution I sell and know the most about but will encourage debate from those who have an opinion…

3 Responses to “Publishing from a Content Hub”

  1. Good explanation of the content hub concept. I, however, would contend that neither an editorial system nor a what we traditionally call a DAM are good at serving as a content hub. Even though both is technically possible, it is often a mistake to combine tactical systems with strategic systems.

    Editorial systems are tailored towards print professionals for the creation, management and publishing of print-oriented (and sometimes electronic) content. They need to have features, data fields, and functionality to support those processes. DAM systems generally are tailored to serve graphics professionals. They are often deployed in order to help manage and transform these assets with interfaces and functionality tailored towards graphics professionals.

    Take an average user who are not deeply involved with these two functions in an organization and turn them loose in either of these systems. The workflows, buttons, labels, etc. are likely to be confusing at best to the untrained user.

    To me, it is important to carve out a new category of software in an organization to serve as a content hub. This should have a very straightforward interface, straightforward workflows, and straightforward functionality so that anyone in an organization can find and distribute content regardless of its origin. In this way, you keep novices out of systems that necessarily are focused on the needs of a technical group in the organization. Users of a content hub should not become lost in the arcane tactical details of creative, print or Web professionals. This also makes the overall IT infrastructure more management. You do not have to implement complex, error-prone “views” on tactical systems suitable for untrained users.

    If you try to drop all of your users into a tactical production system, you usually find anyone not directly involved in that tactical process eschewing the system because there is too much “noise” between them and the content. A content hub creates a lower-common-denominator version of assets in tactical systems that should be readily accessible by anyone in the organization, preferably with a simple, clear interface that requires little or no training to use.

    • chris says:

      I completely agree with the strategic vision of a Content Hub you’ve defined in your post, Chris. I think the reason that a DAM (or Ed System) is still valid in the case of the kind of publishers we work with is that they need the specific tactical functions that an idealistic strategic content repository would avoid. For example, if the centre of the content hub doesn’t handle cropping of images and printing of contact sheets then you need to add another spoke application, a digital picture desk, into the system. If the Hub cannot extract stills from a video then a new workflow is required to make a request back to a video server/service and then to transfer the image back, referencing the original and keeping the two linked (which may not even be possible in the video system).

      Apart from the additional complexity of the system described above in terms of integration points, etc, it adds many more points of failure – a huge no-no for mission critical publishing systems – and, presumably, a significant cost implication with all of the extra licenses. So, while I do agree with the panacea view in you post for most organisations, I think that the publisher’s DAM approach is more pragmatic for many publishers.

Leave a Reply

Your email address will not be published. Required fields are marked *