So what are Content Scenarios?
Content Scenarios are functionally realistic illustrations of content resources and process steps that can be used throughout the content solution lifecycle to maximize investment effectiveness.
In the following presentation, delivered at DITA Europe 2011 in Prague, I elaborate a little on what Content Scenarios are and why they are important for all content projects (and not just projects leveraging the Darwin Information Typing Architecture or DITA). Specifically I put forward Content Scenarios as part of a methodological remedy to what I label the core challenge facing Content Management projects - namely the unsustainable postponement of payback.
Essentially, Content Scenarios provide a tangible demonstration of how new strategies for acquiring, managing and delivering content will make a difference to customers, users and business stakeholders. The most important feature of Content Scenarios is that they must be meaningful to Business Executives who do not care about the technology behind the scenes.
The really short version is that a Content Scenario is a “demo on steroids” that can be used for more than just selling the concept, important as that may be. Less accessibly, a Content Scenario is a fully elaborated “content model” that does not just define the structure and meaning of the content, it exemplifies and demonstrates how the structure and meaning drive functional behaviour (aka what it really means).
So what really makes up a Content Scenario?
- Functionally realistic content examples:
- Assembled from real documentation
- Sensitive details removed
- Supported by web friendly media assets
- Supporting details about:
- Business context
- Key users and stakeholders
- Critical business requirements
- Content & Process Models
- Demonstration scripts for key process steps
- Reference implementations for key process steps
Why are Content Scenarios Important?
- Projects benefit from the early demonstration of envisioned capabilities so that all stakeholders can get behind a common vision (that they have been able to see in action)
- They can be used to build a common vision among stakeholders from across an organization and its partners
- They can be used to make requirements concrete & tangible for all stakeholders
- They allow stakeholders to explore future states including new requirements that only emerge as a consequence of the technology innovations being contemplated
- They allow business processes to co-evolve with the capabilities of the tools being deployed thereby ensuring that all technology investments are maximally leveraged
- They allow design efforts to benefit from iterative learning as feedback is harvested from stakeholders through cyclic demonstration
- They provide a validated reference baseline for testing efforts so that the testing focus is placed on functionality that is most important to the supported business needs
- They provide secure ways to engage vendors by providing them with non-confidential reference instances and process descriptions
- They can be combined together to form higher-level business demonstrations that traverse organizational boundaries and thereby be used to flush out integration requirements
- They provide a way to engage business executives in a way that those executives find meaningful and compelling.
Where did the idea of Content Scenarios come from?
The idea for content scenarios goes back several years. In my own history, I gave a presentation in at CALS Expo 1996 titled “Coordinating SGML Projects to Maximize Enterprise Benefits” (CALS stands for Continuous Acquisition and Lifecycle Support). In this presentation, I explored the application of rigorous configuration management practices to SGML content models and this led me to argue that Document Type Definitions (DTDs) could not in fact be managed in isolation from the associated business context and application functionality. One of the key recommendations at the time was that projects should develop comprehensive collections of representative content that could be used to illustrate the business context of the content models and to demonstrate the planned application functionality. On subsequent projects in the defence & aerospace sector, this approach was pursued aggressively and to great effect.
Moving the clock forward to 2000, I gave a presentation at the annual XML conference titled “XML Business Templates”. This session also gave rise to a whitepaper of the same name (available from Whitepapers Old & New). This presentation returned to these same ideas and did so with reference to a number of implementation projects where the same rationale was applied within other industry sectors. Specifically, the value of shareable collections of reference content instances was demonstrated within engineering environments where online interaction across large networks of suppliers was a critical objective. In these projects, it was proven, repeatedly, that projects benefitted significantly from using this combination of shareable content and lightweight application components to explore opportunities for innovation before major investments were made in the software and hardware infrastructure. In these same projects, it was further proven that even after the major outlays were made on licenses and machines there continued to be a major role for the XML business templates in testing the new environment and in providing a fall-back capability that was called upon with remarkable frequency when commercial products were found lacking.
Content Scenarios & Agile Methodologies
On those occasions that I have discussed Content Scenarios with audiences stocked with lots of software development experience one question that immediately comes up is "How is this different than an Agile methodology?" The answer is "None at all". In fact, one very constructive way to see Content Scenarios is as a grounded and practical way to flush out User Stories so that they can be used to inform development tasks, provide substantive testing cases and equip teams with demonstrations that can be deployed to confirm with the stakeholders that what has been implemented concretely addresses a bona fide business need. For any solution that will handle content assets and publish information products for business users, it is difficult to imagine how any project could hope to deliver anything of value without a library of supporting content scenarios. And I would hold this true for any project regardless of the methodology that is being applied. I do feel that an agile approach will be the methodology that is most naturally receptive to leveraging content scenarios as an effective delivery tool and therefore I see no tension here at all.
Content Scenarios Today
All this has led to what I now call Content Scenarios. There are other inputs that should be noted including what is called “scenario-based testing”. The challenges that Content Scenarios have arisen to address are elaborated in more detail in a previous blog post about Content Management at the Crossroads and in a discussion that broke out on the CIDM (Center for Information Development Management) LinkedIn group. At this time, a number of colleagues and I have been investing time, energy and money in developing the kernel for a number of Content Scenarios. This effort is not insignificant, as can be expected, so it is proceeding in parallel with other projects.
The initial Content Scenarios are being implemented using, and for use with, the Darwin Information Typing Architecture (DITA) although that will not be the only content standard that we will tackle. As they achieve a level of completion these Content Scenarios will be made publicly available under a share-alike type license and perhaps under the agreement (unenforceable probably) that organizations using them take steps to provide some contributions to the collection. The goal will be to help the various standards communities by providing resources that can be used to demonstrate the role that they have been created to play. Hopefully the availability of an evolving set of shared Content Scenarios will also assist product vendors in their efforts to integrate their respective offerings so as to support the type of functionality that customer organizations actually need. And finally, it is hoped that these resources will help these customer organizations more directly - by helping them to demonstrate the functionality that they are pursuing and then achieving the types of results that attracts the attention of executive management – and in a good way.
Stakeholders, including vendors, can unite around a good idea that is powerfully expressed