Bookmark and Share
My Photo

Oxford England

  • The End of the Road
    These photos are separated from my Travels album because Oxford is something of a second home. I still manage to visit it several times a year. So the pathway between Manotick and Oxford is well trodden and I can likely do it with my eyes closed - and probably have on more than one occasion.

Royal Roads University

  • Hatley Castle
    This series of photographs was taken over the last few years. I have stayed at the campus of Royal Roads on several occasions and I have been repeatedly impressed by the grounds. They are in many ways a little-known treasure.

Travels

  • Kafka Statue
    Here is a selection of pictures I have taken during my travels over the last few years. I am very obviously an amateur photographer and it is not uncommon for me to forget my camera altogether when packing. What the pictures do not convey is the fact that in these travels I have met, and gotten to know, a great many interesting people.

Manotick Ontario

  • Springtime in Manotick
    Manotick Ontario Canada is the part of Ottawa that I call home. Much of Manotick stands on an island in the Rideau River. Interestingly, the Rideau Canal, which runs through and around the river, was recently designated a World Heritage Site by the United Nations. So this means that the view from my backyard is in some way on a similar par with the Egyptian Pyramids - although the thought strikes me as ridiculous.
Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported

« The Fusion of Business Analysis and Technical Communications | Main | The Reason and Passion of XML »

May 29, 2011

Comments

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.

The comments to this entry are closed.