The unification of content management

As we have previously discussed on this blog, the term “CMS” can mean different things to different people.  In our experiences working with publishers, both through our consulting services and in developing RSuite CMS, we’ve found that, generally speaking, publishers employ four types of CMS products:

• A general purpose CMS that serves as the authoritative source of content and often interacts with other publishing and delivery systems (e.g.  RSuite, Documentum)
• An editorial and production system (E&PS) that is geared towards print production (e.g. K4, Woodwing)
• A DAMS for managing digital assets (e.g. Media Beacon, Cumulus, Artesia)
• A Web CMS (or WCMS)  that is strictly geared towards running a web site (e.g. Ektron, Vignette, Drupal, Percussion)

Some publishers have a product to help with each of these areas and others use one or two systems with other tools to make things work.  But there is sometimes an unnatural division of these systems within a publishing environment considering the changes that are happening now. When Lisa Bos presented at a recent IDEAlliance function, she included two graphics to illustrate where things once were and where they are moving.

This first graphic represents where things were not too long ago.   For the most part, the systems, in terms of functionality and how they are used within a publishing environment, were separate and for traditional print publishers, the E&PS, was the main focus.

But things are changing.  The circles, and the systems they represent, are moving closer together and changing in size in relation to their importance in the publishing environment.   The graphic below represents where the industry is moving.

These changing and overlapping circles represent the oncoming unification of content management systems within publishing environments (as always, our take is from within the publishing industry.   For example, DAMS systems serve unique purposes for corporate marketing departments, but our focus is on publishers).   

This is not to say that the individual systems are necessarily going away, but rather that there is going to be more crossover between systems both in terms of the functionality offered, but more importantly, how a publisher places these tools into their environment.

What is driving these changes?

• There has always been overlapping functionality among these systems.  A DAMs for digital assets and a CMS for textual content provide some of the same basic CMS like functionality.    An individual publisher might need one or both to meet all of their needs.    But you can’t get by the fact that all of these systems at their core are “managing content.”
  
  
• Generally speaking, DAMS and CMS are running into each other and are the growing circles.  They are growing because they are the primary methods for gathering, storing, finding, re-purposing, and delivering content – the heart of the publisher’s success. In some ways, they are already the same thing, but with each optimized for slightly different usage and content (documents and XML vs. non-textual media assets). The marketplace already reflects this, with some systems that try to provide it all and some that maintain a distinction and are clear in saying they will continue to do so.   It is getting even more confusing for publishers as some certainly do require the high level of sophistication of a specialized DAMS product, while others could probably make do if their document/XML CMS provided 50% of the capabilities found in a DAMS product.   And in the end, it is all content, regardless of type, and there are some real benefits in classifying, retrieving, and reusing content in a centralized environment.
• The centrality of print- or web-specific systems and process is waning as CMS/DAMS increase and as publishers remove their internal organizational distinctions between print and web publishing.   Neither the WCMS or EPS are the permanent home for content; they are where it is produced and both offer specialized tools in easing the production process.   We expect to see a range of solutions from high-end (those niche tools integrating tightly with a CMS/DAMS, or a CMS/DAMS that tries to do it all) to lower-end (limited media-specific capabilities directly in the CMS/DAMS). Which is most appropriate depends on the publisher’s need and on the availability of desired features in commercial products and the choices vendors make in the next few years (building vs. strategic partnerships).   This is also driven by the internal organizational changes that merge once separate print and web production groups .  I have not kept it up to date as I once did, but I’ve tagged articles that discuss the merging of print and web operations (mostly from the newspaper and magazine markets). 
  
  
• Related to the above, there is a need for tighter integration between systems.  The WCMS circle is getting smaller as automation is increasingly used to publish to the web, but it is also moving close to CMS, indicating a need for tighter integration to facilitate automation and a reflection of the fact that, as mentioned above, many publishers are not treating print and web publishing as two different activities.  It also reflects the fact that most WCMS products on the market today are not geared towards the needs of publishers.  Too many times, when representing one of our clients, I asked WCMS vendors to speak to the abilities for large volume publishing, and the vendor came in and showed the “edit the About Page” demo.

The industry is not at the point when one system serves all of the needs represented here.  And I don’t know if we ever will or even ever should be.  Some organizations will have very sophisticated needs for managing digital objects.  Even with what is said above, print is different than web publishing.    But the key takeaway is that the organizational processes that interact with a CMS are merging and the tools themselves will follow suit.

Comments

[Bob DuCharme]

Hi Ed,

You touched on an issue here that I'd like to see you expand on: you present the future directions mostly in terms of customer needs, which is a good thing, but an important vector in the direction that these circles move is vendor intentions. Do you think many of the vendors in each circle understand the opportunities (I almost wrote "see the opportunities," but realized that "understand" is a much more accurate term) in the publishing world enough to efficiently implement the overlapped parts of your diagram? How many of them, on a circle by circle basis, "get" it? (Or care--did Interwoven give up on XML content management because they saw a lot more small fish to sell to than big fish, especially considering that the big fish weren't that big?)

Bob

[Ed Stevenson]

Hi Bob

Thanks for the comment and question. The one thing about vendors in the three specialized circles is that they are understandably focused on very specific content types and functions, not the publishing environment as a whole. So while the product may be very good at one type of thing, the vendor’s focus is not on how the organization, especially the publishing organization, does those other things. In some cases, that may be fine, especially if the publisher has very sophisticated and specialized needs in one of those areas. But the publisher has the burden of overlapping the circles.

Just for an example, being in the publishing world, I was somewhat surprised when I went to the Henry Stewart DAMS conference and saw how much emphasis was put on supporting large marketing operations, not publishing. Sure it makes sense and I was a bit provincial to assume everything is about publishing, but the point is there are not many vendors in these CMS spaces that I know of who solely focus on the publishing industry, and I would therefore guess will have difficulty overlapping the circles.

I don’t even know if E&PS vendors, who you could argue are the most focused on the publishing market, understand enough beyond the print production processes to bring these circles together. Obviously one way to bridge these circles is partnerships and last year I posted on two announcements between E&PS and WCMS vendors. I don’t know enough about those partnerships to know if it is a real integration or simply throwing the finished print content over the wall to the WCMS.

And as for the WCMS circle, I’ve never really thought they were as much about content as they were about the delivery channel and managing the web site. They would probably be the least able to help overlap the circles. But that makes sense – why would they want to get involved with print production! I wouldn’t if I were them.

But to get a plug in here, I should say that I think we (Really Strategies) with a history of consulting in the publishing industry, understand the publishing world enough to move our product RSuite in this unified direction, either through integrations with other tools and products or adding the features into the product.

Ed

[ann michael]

Ed -

Two questions:
1) what about an LCMS - where does that fit in?
2) is another valuable distinction to look at this in terms of WIP (work in progress), finished goods, and delivery mechanisms?

I think if we do then the unification becomes even more apparent on some level. For example, having an easy way (central repository?) to get to everything you've ever produced is pretty valuable for ongoing operations and new product development. In fact, it could become the basis for user generated customization (meaning I, the customer, get to pick what I want from your content - you just need to price it!).

Great post, btw!

Ann

[Ed Stevenson]

Ann

On your second question, yes, I think that is a valuable distinction. These other CMSs are about certain types of content and/or certain types of packaging and delivery. Mike Edson makes some good points on this in his post that followed this one.

One your first question, although I know others at Really Strategies have had experiences with LMS, I am unfortunately not one of them. With limited knowledge of those systems, I think I could say they are specialized content and delivery systems and the argument made here is still valid. At the very least there needs to be some coordination and integration between an organization's content-centric CMS (to use Mike's term) and any other CMS within their environment, whether that be a E&P, WebCMS, or LMS.

[Shahir Kassam-Adams]

Ed -

Interesting post. Sorry to join the discussion later than the others.

If you look far enough out, there is another constellation of circles moving towards this space - the relationship management domain.

There is no denying there were/are many functional and logical overlaps between (the original "LMS" for us old timers) physical Logistics Management Systems and current iterations of E&PS and content delivery systems. Similarly, the need to integrate who is doing what, why, where, when, and how in the CMS environment is growing. The demand to mine and link RMS and CMS is going to be a larger part of the future than most people anticipate. I'm already seeing cobbled solutions for such needs. Very much like the early days of CMS when people swore that all you needed was LaTex and shell scripts. :)

Regards,

Shahir