The Fusion of Business Analysis and Technical Communications
The Reason and Passion of XML

Content Management at the Crossroads

Railway Exchange

For a number of reasons, I have been thinking recently about the state of the Content Management industry. These ruminations took me back to one of my posts from the summer of 2009 called The Trials and Tribulations of Content Management. In this post, I declared that historically the content management industry, as a whole, has under-performed. I continued with the supposition that one contributing factor to this under-performance was the apparent absence of any shared understanding of what indeed we were trying to manage. We did not, I felt, have a common definition for what we meant by the term “content”. No wonder then that the various players in the industry only occasionally, and in all likelihood accidentally, coordinate their activities and investments in a way that makes a positive difference for business stakeholders, aka the customers.

I promptly set about writing a series of posts that sought to lay down some definitions and to summarize some of the trends that are discernable in the last 20 years in the life of the content management industry. While I am reasonably pleased with the conceptual integrity of the definitions being sketched out, I am also quite certain that these efforts have made no appreciable impact on practitioners and players in the industry.

Undeterred I am returning to the topic and this time I will approach it from a more practical, and hopefully more accessible, angle. This time I will focus on a different shortcoming in the content management industry: the generally poor state of the shared resources available to assist content management practitioners, product vendors and customer organizations in demonstrating meaningful content processes (i.e., that run from "end-to-end" in a value chain) that will make concrete sense to business stakeholders. Such demonstrations, in addition to communicating the benefits of content management, also provide real-world scenarios that can be used to facilitate improved interoperability across products boundaries.

Train Yard

At a number of recent industry events, I have made a point of reviewing the demonstrations that various vendors use to illustrate the capabilities, and presumably the value, of their respective product offerings. In almost all cases, the content being used, and the business scenarios being demonstrated, are almost ludicrously simplistic. Without a word of exaggeration, most demos consist of one or two short documents, with obviously bogus content, being modified, stored, retrieved and rendered so as to showcase one or two product features. How, it should be asked, would this help a business stakeholder, who is confronted with very serious content challenges and even more serious business problems, understand the potential value of any one of these content management tools? The answer is simple – they don’t help at all.

I would submit that without shared demonstrations that illustrate how a number of content management tools can interoperate to address real business problems, there can be no genuine improvement in how the industry as a whole performs. Quite simply the business requirements that need addressing exist at a higher level than any one content management tool. Demonstrating the features of any one tool does not actually demonstrate any value to the prospective business customer.

Indeed I have an even more deep-seated concern. I worry that in the absence of any shared demonstrations, the chances are that the product teams for the many individual content management tools are in fact working towards partial, or worse invalid, requirements. Product plans for any given tool that do not take into account the larger business needs will be intrinsically flawed. When I see the laughable state of most product demos I can’t help but wonder what will happen when these tools run into real requirements embedded within real business processes. What happens when these individual tools actually need to interoperate with other tools to support people doing real work? From bitter experience we probably all know the answer to this question. As implementers we have to hack and patch the various products together so as to realize a working solution.

Railway Bridge

It is my belief that the content management industry exists for a very good reason and that businesses around the world in fact desperately need help in managing and leveraging their increasingly valuable content assets. It is also my considered opinion that as an industry we have fallen short in our efforts at collaborating together to provide these customers with more tangible examples of how content management tools can interoperate to deliver value. More to the point, I believe we have collectively fallen short in evolving shared resources, what I will hereafter call “content scenarios”, that can be used to facilitate the evolution of better content management tools and improved integrated behaviour across these tools.

There are standards bodies that were in fact formed in large part to do just this very thing – to facilitate cross-industry coordination, in particular between vendors and customers – and it must be said that these standards bodies have not performed this service particularly well at all. There are several reasons for this but they deserve separate treatment.

Different Directions

The fact remains that without such coordination the content management industry will remain trapped in a state of perpetual under-performance. This is bad news for all members of this community. It is even worse news for the many organizations who need better content management support than they are getting and who will continue to get by with the working solutions they manage to assemble from the piece-parts available from vendor shelves. The good news, as a little light at the end of the tunnel, is that the industry is more than capable of making improvements in this area and thereby heading down a better path. In fact, there are signs that this has already begun…

Railway Tunnel


Feed You can follow this conversation by subscribing to the comment feed for this post.

Milan Davidović

Are there examples of "shared demonstrations" and coordination in other industries that content management might look to for inspiration?

Joe Gollner

Hi Milan

A good question - in equal measures obvious and interesting. What is really peculiar is that the best example I know of, or at least with which I have direct experience, is in fact a specialized part of the Content Management industry (although perhaps from a dimly remembered past).

In the defense sector back in the late 1980s and early 1990s there was an initiative called "CALS". The acronym had a number of translations with the most recent being "Continuous Acquisition and Lifecycle Support". Yes, this is where the CALS Table model comes from along with several other things the heritage of which has long since been forgotten. It was something of a sprawling initiative and that ultimately was its undoing. I wrote a chapter in the recently published book, Information Management Best Practices (Volume 1), and this chapter specifically addressed one particularly successful CALS activity (see TIMAF.ORG).

What I specifically remember participating in (on several occasions) was an annual undertaking known as Roadmap 2000. Now this was before the year 2000 became shrouded in inflated concerns about computer vulnerability. Roadmap 2000 was an effort to mount joint demonstrations that would run across multiple vendors' platforms and that would be accessible to "military brass" who didn't really care how it worked but who were very interested in what it could do. These integrated demos were hard work, make no mistake, and especially when we were doing them just as the Web was being born. Integration in those days was even harder than it is today. A lot harder, in fact, and this is what made the integrated demonstrations so important.

I participated in several of these annual undertakings, which led to actual demos that would run between booths at the yearly "industry steering group" expos, and I did so in a number of guises - supporting product vendors as well as being part of National CALS offices trying to coordinate "national" demonstrations. These efforts were highly effective in a number of ways. One was that the integrated demos could be used to engage real business stakeholders - in this case people with lots of medals. The second was that it forced out into the open all sorts of integration challenges, some minor and some not so minor.

Now this is only one example and a rather distant one at that. However, these experiences left a very positive impression on me. I will never forget getting to the end of one integrated demo and seeing the look of understanding spread across a General's face. You could almost hear the coins dropping - figuratively and actually.

Another example is also from within our own industry - OASIS (the Organization for the Advancement of Structured Information Standards) or as it was originally termed "SGML Open". Among the foremost reasons behind forming this industry consortium, at least as originally envisioned by the great Yuri Rubinsky, was that it would be the mechanism for facilitating improved interoperability across the entire industry and for pooling resources to help the industry as a whole to market its value. This organization has made some contributions in this direction but only a few. But many of the areas that were of initial interest, such as improving the value proposition of the entire industry (what we might today call component content management although I am not the biggest fan of that particular label), have received only occasional and at best marginal attention.

One thing these two examples remind us of is that the shared resources that I am advocating do call for a significant amount of work. Even more relevant is the fact that this work entails collaboration across sometimes sensitive corporate lines. I suffer from no illusions that establishing and evolving such shared resources would simply require a few late nights. It calls for something more sustained than that. Perhaps an existing mechanism such as OASIS can be reinvigorated in its original calling. Or perhaps there is another way to find the sustaining energy that will doubtlessly be called for...

Milan Davidović

The Wikipedia article describes CALS as a DOD initiative. Can I read that as being driven by the customer rather than the vendor?

Perhaps the sort of thing you're calling for needs to be driven by wider spread customer demand for a higher standard of backing for vendor claims.

Joe Gollner

Again I think you are on the right track, Milan.

CALS was very much a "customer-driven" initiative and these integrated demonstrations were very much intended to set a progressively higher standard for the community of vendors providing the supporting technology (as well as for the weapon system suppliers and support contractors). It was also part of the initial concept behind OASIS (SGML Open) that it would create a forum within which customers could interact with vendors to establish a clearer picture of the requirements to be met and the levels of interoperability to be achieved.

In the case of CALS, the scale of investment made by the DoD, as well as by parallel and coordinated efforts throughout the main NATO allies (CALS needed to be an international effort if its vision of an integrated supplier network was to be realized), was very significant. This underscores the point that this type of effort is real work and it calls for real investment.

When we look at various standards bodies, or consortia such as OASIS, we see this illustrated in another way. The hard and not entirely glamorous work of building up "functionally realistic" demonstration scenarios, as well as technically rigorus test suites, is not something either vendors or customers seem willing to invest much effort in. We see this often in open source projects as well. Parts of the development work that are topical receive good levels of attention. The less exciting, but equally critical, parts like documentation and rigorous testing and functionally realistic demonstrations often get passed over.

I myself have not quite "squared the circle" on this problem (of how to stir up adequate attention, effort and investment) but I have a few ideas brewing...

Milan Davidović

It might be interesting (I'm making no claims of utility) to describe the problem in a generic way (that is, removing specific reference to content management, with the aim of making it more accessible), and then to take that description around to participants in other industries and see if it resonates. We might get two things out of such an exercise:

1. A list of industries that are similar in this one respect (perhaps they're similar in others?).

2. Some ideas (good? merely interesting?) that we might not have come up with by just playing in our own sandbox.

Joe Gollner

Hi again Milan

I like this suggestion and it has me thinking about how to describe this problem in a generic way. I believe it boils down to the need to share content / data amongst a number of organizational participants in such a way that all parties can choose what software they use and how they wish to conduct their business. What we would be trying to capture is a sampling of the business scenarios (use cases if you will) that help give this generalization some tangibility.

I would be interested to see how different industries have tackled similar problems. Certainly there are precedents in areas such as EDI or therefore in various aspects of supply chain integration efforts. This reminds me that it might be worthwhile to look again at what ebXML did in this area, or UBL. I recall spending some time with a group called Web Services Interoperability (WS-I) which is now a part of OASIS and I recall being impressed with their work at the time (it was in and around the time when it was launched).

Now in these cases the compelling need for different vendors to have their products interoperate was pretty inescapable. If you tool didn't play well with others you were pretty much run out of the market (or you effectively ran yourself out of the market). In the cases of EDI and Web Services, interoperability is everything.

Now in the content management space we do have efforts around Content Management Interoperability Services (CMIS) which seem to be fairing better than any of the preceding attempts to establish some interoperability standards and protocols for CMSs.

My primary consideration would be to look at business scenarios and the collaborative construction of demonstrations that can help to promote both individual products (in being able to tackle part of one or more scenarios) or interconnected collections of products working together to help customers envision how they will work more efficiently and effectively in the future.

We have most of the brute interoperability issues worked out in our industry, or at least we are all very familiar with the usual workarounds. With more recent standards (for example DITA and the most latest incarnations of S1000D), we do still run into patchy or divergent product support. So the need for collaboration on conformance as well as demonstration suites is still present.

Back to your suggestion, I will give this more thought and perhaps do a little looking around. I am certain that if we manage to go further afield than variations on content interchange - to other types of standardization efforts (some of which have been wildly successful) - I am sure we will learn from useful and interesting lessons.

Jacquie Samuels

I love it when I find something that gestalts my thinking to a whole new level, and this article did that for me. I've been up to my elbows in CMSs for the past few years: using, training, and submitting recommendations for improvements based on actual use cases. I've never thought of the whole mish-mash experience as being fundamentally flawed, but that certainly struck a chord with me.

The demos, are, as you say, laughable. Many CMS vendors tend to view many parts of the entire workflow as being outside their area of responsibility. At this time, I agree that the process of adding a CMS to your content lifecycle becomes a battle of tools and customizations. However, it's heartening to see that some CMS vendors are very much interested in closely integrating with XML editors, sometimes with very good results. What's often missing is someone to train the authors on using the combination of tools together; it looks like that's a role I'm starting to participate in more and more. So I hope I'm part of the larger picture solution you're envisioning, if even only at a very small level so far: DITA best practices, XML editor training, and CMS training. Writers come away knowing how they will create, maintain, and update documentation, using whichever combination of tools they chose.

But I wanted to say that it's this small beginning of tight integration between editors and CMSs that I hope will really start catching on so that content creation and management becomes more seamless (and less fraught with workarounds and limitations). If we can then add in planning tools, translation tools (not just workflow, which can be a real pain), and publishing tools (that last being the most important at this time), I think we'll start to see end-to-end solutions available. But I'm left wondering who will provide those suites of tools? The CMS vendors seem a little tentative. Consultant-type companies who can manage the partnerships between all the other companies? It's just not clear to me who we're expecting to step up to the plate.

I have to admit that the entire question of developing CMS standards is, as I see it, unlikely to happen until the field thins out a bit. I'm hoping that, by the fact of simply NOT satisfying customer requirements, some vendors will have to bow out of this contest, leaving only the best tools. (How are they staying in business?) At THAT point, I can see them establishing some standards, if only to prevent start-ups from offering sub-standard products (it would then be both possible and in their self interest).

On the other hand, maybe I'm just a raging optimist.

Joe Gollner

Hi Jacquie

Thanks for your input - it raises some important questions and none more important than who will step up to the plate and initiate some progress in this area. And I am also very happy to get all the corroboration I can - and so far I have been getting an earful on many parallel channels.

It is my inclination at this point to think that there are some things that can start now and that, more as a process than an end-product or standard, establishes a better and more constructive interaction amongst CM tool vendors and their current and prospective customers. The truth is that there is plenty of blame to go around when it comes to considering why it is that "content management" has been progressing so gradually, and healthy servings in fact can be allocated to customer organizations who have not been very clear-headed or rigorous in how they tackle the challenging of managing and leveraging content. But it is my contention that we can, and indeed must, improve on this very front.

Again on the topic of who is going to step up and at least initiate some of the activities that seem to be needed, if I am not careful I am going to hear what we used to say in the Military whenever someone ranted too loudly about a problem: "Sounds like we have a volunteer!" In truth, some of the feedback I have been hearing on other channels effectively amounts to this.

Mark Pepper

Hi Joe,
Great article. In the beginning of your post you highlight what I think is the core of the problem: defining 'content'. It really does come down to semantics, especially since different organizational silos define content in their own unique ways. We have marketing communications, business communications, technical communications, and others that vary depending on who is using them.
Perhaps part of that solution is finding the common language, or touch points, between each of the different content silos. A method I have used to help facilitate this discovery is the tracing of information which flows through a system. A marketing plan may define certain pieces of information in its content. Some of this information is then repackaged in the business plans, which eventually feeds into the technical docs. This can be conducted as a content audit, or in designing a system around information to be used in content.
This process of course requires a shared definition of what me mean by content, and information, and that more granular piece, data.
The interesting thing with this is that it is independent of tools. Certainly tools make the process easier, but you could do this, to a degree, with a bunch of sticky pads and a wall.
From what I have seen, tools are often sold as the solution, but they are of little use without the planning and defining how everything fits together.
Which comes back to definitions. In the absence of clear goals, perhaps we can start with the goal of defining the pieces we need for content management. This is the realm of the standards bodies, which you point out are not living up to hopes, so perhaps this is an opportunity?

Joe Gollner

Hi Mark

This is bringing us very close to the central issue that I was really trying to tackle - how to we put some real meat on the bones of a shared understanding of what content is and how we can improve how we handle it?

On the definition side of things, I have taken a few runs at the question namely with posts such as The Truth about Content and Architecting Information and Engineering Content among others.

In the former of the two posts referenced here, I propose that we should look at content as "potential information" and I have since found this distinction to be more and more useful. In effect, this definition allows us to look at content a little differently than we do about information. In another post, Managing Information, I elaborate on what this distinction means for our considerations of information and its management.

Information, under this model, becomes "transactional" so it does very much something that can be studied as signals connecting entities and events. But our distinction then introduces a nuance in that we suddenly realize that information does not really flow as each informational transaction is an event. What does flow though is content which a recipient of a transaction takes from the information being received (or constructs based on the information received) and then formulates and enacts new information transactions. Where we have certain types of information transactions, such as we might associate with "publishing" events, we also see why it so important to look at the content (the potential information) as a separate thing that we need to understand, manage, optimize and capitalize upon.

And to pick up on your reference to the fact that how information transactions are expedited is less important than the fact that they are expedited. The Japanese Kanban card in manufacturing is the classic example. Your other point that the content ultimately needs to be independent of any one technology is a critical. The content on the Kanban card has been expressed in a specific physical form for the purposes of transacting business. However efficient this might be, if this is how the content is also going to be managed and modified then we can see how the system will soon collapse.

We can also pick up your other example, of the character of content as it exists within different parts of the organization - marketing communications, business communications, technical communications. In each domain, there will be stores of content that really should be reused in the stream of information transactions that are being emitted. And perhaps more critically, there will be a pool of common content that all areas and all transactions should share.

In a conversation I was having with one company yesterday, I was describing how to approach organizations so as to identify where they could start to make improvements in how they handle content. Although a slightly dark analogy, I referenced the famous saying of fraud investigators "follow the money" and turned it into "follow the content". I think that this is where we are heading with discussions of shared demonstrations. As you say, we should really be looking at scenarios that illustrate how all these boundaries (disciplinary, organizational, technological) can be traversed if your content exists in certain forms and is managed in certain ways.

In some of the online communities inhabited by people working in Content Management, a number of questions have been raised about whether it is possible to create "shared demonstrations" that are sufficiently specialized to be relevant to specific groups of prospective stakeholders (say in an industry vertical) but at the same time sufficiently generalized to be broadly useful and economical to develop.

Though I immediately concede that finding a suitable balance between the specific and general is a challenge, I would also insist that this challenge cannot stop us from making progress. At the end of the day, some shared demonstrations will still be better than no shared demonstrations (content scenarios) - which is basically where we are today.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment

Comments are moderated, and will not appear until the author has approved them.

Your Information

(Name and email address are required. Email address will not be displayed with the comment.)