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...

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...

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.

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.

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.