Presented by Joe Gollner at Documentation and Training East, October The most common mistake found in content management projects is rather surprising. The reason most CM projects falter is that the project team, and frequently its stakeholders, become unduly enamored with some piece of technology and assume, or hope, that one or two applications will erase all of the challenges surrounding the creation, management, reuse and delivery of content. When a particular collection of applications fail to deliver on the expectations, the usual response is to insert even more applications. With each new application that is introduced, a number of connectors and patches are also added so that one tool can work with the others that are already in place. This continues until, with seeming inevitability, these projects crumble under the weight of growing system complexity. These projects fail, in short, because, in becoming fixated on technology, they essentially forget about their content. This presentation will use a number of project cases studies, some older and some exceedingly current, to illustrate the downward path that most CM projects follow. While this might sound ominous, this journey will actually arrive at a hopeful conclusion. If CM projects place content at the center of their solution designs, adopting in effect a Content Oriented Architecture (COA), it becomes possible for projects to use technology, even exploit it, in ways that emphasize helping authors, publishers and content users. Under this model, the quality and usefulness of the content assets becomes the overriding focus and where automation is introduced it is to either further improve the quality of the content or to reduce the cost and effort needed to achieve the desired results. Examples of successful projects will be used to prove that Content Oriented Architectures are not really new and that they do deliver results that endure over time.

1. Content Oriented Architectures
Putting Content at the Center
Joe Gollner
of CM Projects jgollner@stilo.com / www.stilo.com
Vice President, Enterprise Solutions
Stilo International

2. Deer in the “Application” Headlights
Problem 1:
Implementation of repository Problem 2:
& authoring tool made Processing of instances
content reuse difficult exceeded the capacity of
publishing tools
Product
Data Management
Repository
Structured
Authoring
(Book Orientation)

3. Topics
The Perils of
Application Orientation
Case Study: An Unhappy Tale
The Attractions
of Application Orientation
A Tale of Three Projects
Saved from Destruction
Content Oriented Architectures

4. The Perils of Application Orientation
Application Application
Authoring Printing
Application
Each application introduces constraints on Printing
the content inputs / outputs and these are
frequently incompatible with each other
Application Application Application
Importing Indexing Viewing

5. The Nature of Software Applications
Software Applications Applications are tools
share a number of traits that amplify the
skills of people to
Developed to address a enhance performance
Purpose
specific purpose
Predicated on data inputs Application
with predictable structures
and values
Purpose
Guided by “definitive”
algorithms through which
a result can be determined
or
Applications depend on
Strict control Conditions Satisfied
Fixed scope
Limited timeframe

6. The Limits of Integration
Application Application
Application
Viewing
Web Publishing
PDF Publishing
Application Application
Failure Threshold
Application
Authoring
Importing
Indexing
Application
Application Application
Exporting
Loading Storing

7. Case Study: Electronic Regulatory Filing
National Energy Board (NEB) of Canada
Regulatory Agency governing the Canadian Energy Industry
“Court of Record” (Convenes Hearings & Makes Judgments)
1993 – Vision articulated of
an electronic regulatory
filing process
Based on Open Standards
Put in place a solution
To be shared across the industry
Management repository
Publishing services
Authoring tools
Validation & interchange tools

8. ERF Content Model
The ERF Content Model proved
to be substantially more complex
than could be realistically used

9. Electronic Regulatory Application Architecture
Recipe for Disaster:
- Complex DTD
- Customized authoring tools
- WordPerfect
- XMetal
- MS Excel
- Over-burdened repository
- Astoria
- Over-burdened publishing tool
- FrameMaker

10. Project Outcomes & Lessons Learned
Project was a Complete Failure
Project Managers ignored early warnings
The solution was too complex to be feasible
Technology architecture was fundamentally flawed
Application components were pushed beyond their capabilities
Application components were heavily customized
Version upgrades in platforms had to be avoided for:
Content repository, publishing engine, authoring tools
Practical constraints on content markup became outrageous
Standardized formatting was not acceptable to stakeholders
$10 Million investment was lost when the project
was cancelled by executive management after 10 years

11. The Attraction of Applications
Applications hold great attraction
Especially for management
Not entirely unreasonable as they:
Make specific knowledge
executable & efficient to leverage
Provide repeatable benefits
Offer the potential to “scale”
Application Investments
Tend to have a mixed implementation track record
Tend to have a relatively short lifespan
Underlying knowledge is invalidated or superseded
Changing business environment reduces effectiveness
Inflexibility leads to “barnaclization” of application investment

12. A Tale of Three Projects Saved from Destruction
Software Engineering Solution
Scenario: Metropolitan Area Network equipment supplier finds its
core business strategy threatened by application limitations.
Global Case Management System
Scenario: Massive project to integrate a variety of content services
into a global CRM platform threatened to become an even bigger
project due to fundamental application incompatibilities.
Multi-national Defense System Project
Scenario: Large system acquisition project threatened to be halted
due to the cost and complexity of the application integration tasks,
made more challenging by extremely onerous security requirements.

13. Software Engineering Solution
Situation
Optical Networking venture building a new product suite
Distributed, multinational development team
Speed of software adaptation core to their “value”
Needed to wholly control and own their work environment
Existing CASE application could not meet these goals
Solution
Required a complete Software Engineering Platform
Core System: design environment and code generation system
Supplemented the original CASE tool with an extensibility layer
Permitted all stakeholders to participate in the design process
Delivered enhanced quality, improved productivity &
contextualization of the output software components
Delivered dramatically improved system documentation

14. Software Engineering Solution
Key Points:
Exposing design
content in an
“intermediate” XML
format permitted a
variety of “content
processes” to be run
that extended the
core system behavior
by enhancing:
- Quality control
- Online collaboration
- High precision
content publishing

15. Global Case Management System
Situation
Large-scale solution for an Immigration and Citizenship
Case Management system supporting global user community
Content Management dimension of the requirements were
both very challenging and absolutely essential
Initial concept was to integrate a COTS DM / CMS into the
enterprise CRM package and to deploy a hybrid environment
Forecasted cost of this integration ran to over $50 Million and
serious integration & deployment risks were identified
Solution
Rigorous requirements discovery & distillation effort undertaken
Numerous alternative architectures were evaluated
By focusing on the core requirements, introducing a content
specification governing interfaces & adding effective content
processes – the $50 Million budget was effectively eliminated

16. Global Case Management System
Key Points:
Addressing the integration
challenges using an
extensibility model
addressed all of the core needs
and permitted a wide range of
parallel requirements to be
accommodated at no
additional cost.
The solution embedded
content intelligence into the
underlying database and
network layers that allowed
sophisticated content services
to be delivered using existing
commercial applications.

17. Multi-National Defense System Project
Situation
Very large NATO Defense System Project
Design & development work to be performed across 13 countries
Original Collaboration environment depended on a large
investment in security applications to facilitate direct access to
PDM environment
Expenses, incompatibilities between different PDM platforms, and
security concerns all became an issue
Solution
Content architecture established for content interchange
Simple CMS developed to act as a “master repository”
Content exported from source PDM to repository
Interchange protocols / collaboration processes put in place
Multi-level security including content-based measures

18. Multi-National Defense System Project
Key Points:
Content exported from
Product Data Management
system and an interim
master repository established
for working content.
Multiple strategies leveraged
to enhance security levels.
Stakeholders
Master
Repository
Secure
PDM

19. Secrets of Success
In each of these three cases:
A workable solution emerged by exposing the content being
managed and processed within applications
A workable solution emerged by exposing the system logic
governing the applications as content that could be
highly parameterized
Supplemental components processed the exposed content and
effectively bridged the gap between different applications and
between applications and requirements
The end solutions were very simple to implement and maintain,
and provided for ongoing adaptation to address other needs

20. The Common Ingredient
Content Integration
Exposing the “content” is analogous to reverting to first principles
or finding the common denominator when solving a problem
Any impedance between the paradigms governing applications
can be addressed by analyzing and processing the exposed
content and logic
The content integration interfaces become
independent components that can be used to address
parallel requirements as they emerge
The common form used to expose all content –
informative and processable XML

21. Content Oriented Architectures
Plug &
Service Play Service
Application
Array
Service Service
Service Service
Dynamic
Content
Services
Business Domain Content
Store
Content Domain Independent Open
Representation Standards
Application Domain Multiple Application Sources

22. The Benefits of Content Oriented Architectures
Application Filter
Application
Indexing
Simplify Markup
Importing
Validator Application
Filter Application
Validation Viewing
Filter
Update Metadata Exporting
Application Achieving application
Filter Content
independence, increased
system flexibility, improved usability, ...
Authoring …by exposing content &
adding transformation
filters & validators
that solve
incompatibilities

23. Enterprise Content Oriented Architecture
Controls
Specialized
Models
Integrate
Rules

24. Conclusions
There are many reasons
to look more closely at
content technologies
One of these is to find
better ways to integrate &
leverage application
investments
… this can save precious
time & money for both
people & organizations
Parting Thought
It’s not so much about managing
content with technology as it is about
managing technology with content