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.
08448380779 Call Girls In Greater Kailash - I Women Seeking Men
Content Oriented Architectures: Putting Content at the Center of CM Projects
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
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
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