Enterprise Engineering Series | ECM Practice | Lab 01 of 26
By Ewing R. Samuels III | Samuels Enterprises, LLC
Enterprise Content Management is often described in terms of documents.
That description is accurate—but incomplete.
A document is only the visible artifact. Behind it may be a customer, transaction, contract, claim, engineering drawing, invoice, application, approval or business decision. Around it are people, systems, permissions, processes, metadata, versions, relationships and governance requirements.
Once information reaches enterprise scale, the engineering challenge is no longer simply:
Where do we put the file?
The questions become more consequential.
What is it? Who created it? Which version is authoritative? Who can see or change it? What process does it belong to? How long must it be retained? What other systems depend upon it? Can someone retrieve and trust it years later?
Those are not file-storage questions.
They are systems questions.
And that is where my Enterprise Engineering story begins.
My Introduction to EDMS
My introduction to Enterprise Content Management began in 2004 in Orange County, California, when I started working with a close friend who introduced me to EMC Documentum—and, through it, to the broader Electronic Document Management Systems, or EDMS, information technology industry.
At first glance, document management can sound straightforward: capture information, store it digitally, make it searchable and retrieve it when needed.
Working with enterprise content systems reveals something much larger.
A document is not merely a PDF, Word file, image or scanned piece of paper. It is an information object existing within a business system.
It can have an owner, type, metadata, versions, permissions and relationships. It can participate in workflows, move through lifecycle states and become subject to governance requirements. It might originate in one application, move through several others and need to remain understandable years later.
The question changed from:
Where should this document be stored?
to:
What does this information represent, how does it move through the organization, who and what depends upon it, and how do we maintain control of it throughout its useful life?
Documentum was my introduction to that problem.
The Document Is Not the System
Imagine a company receives a signed contract.
Someone saves it to:
Contracts/Customers/2026/Final/
Then someone creates Final_v2.
Then Final_v2_REVISED.
Eventually somebody creates FINAL_FINAL_SIGNED_CORRECTED.
The example is humorous because the underlying problem is real.
A filesystem knows that a file exists.
An enterprise information system needs context.
The contract may need to be associated with a customer, contract type, effective date, expiration date, business unit, jurisdiction, approval status and retention classification.
Some employees may read it but not change it. Legal may require different access. A process may begin when the contract becomes effective. Another may need to occur before expiration.
The content itself is only one component.
The surrounding information architecture gives that content meaning.
This was one of the first major lessons ECM taught me:
Information without context becomes increasingly difficult to trust as an organization grows.
Repository, Metadata and Classification
One of the foundational concepts behind Documentum is the repository.
It is tempting to think of a repository as a sophisticated folder structure. It is more useful to think of it as a controlled information environment.
The repository manages content while maintaining information about that content.
An engineering drawing, for example, might carry a project identifier, drawing type, revision number, engineer, approval status, facility, security classification and effective date.
That descriptive layer is metadata.
Metadata is not administrative decoration. At enterprise scale, it becomes part of the operating architecture.
It allows systems to classify information, locate it, secure it, route it, govern it and connect it to business processes.
Classification determines how different information should behave.
An invoice is not a contract. A contract is not an engineering drawing. An engineering drawing is not an employee record.
Each can require different metadata, permissions, workflows and lifecycle rules.
Good information architecture therefore begins by asking:
What kinds of information does this organization actually have—and how should each kind behave?
The technology has to understand the business.
Search Begins Before the Search Box
Search is often treated as an interface feature.
Enter some words. Click Search. Receive results.
But reliable enterprise retrieval begins much earlier.
If information was poorly captured, inconsistently classified or inadequately described, no beautiful search interface can completely repair the underlying problem.
Retrieval quality is partly determined at ingestion.
If the system knows that something is a contract—and knows its customer, effective date, jurisdiction, status and relationships—retrieval becomes much more powerful than searching filenames.
The repository can begin answering questions about information rather than merely locating text.
Security, Versions and Trust
Enterprise content introduces another fundamental problem:
Access is contextual.
The real question is not simply whether someone can log into the system.
What information can that person see? What can they modify? Approve? What should they never access? Does authorization depend on role, department, project, geography or classification?
Security therefore intersects directly with information architecture.
The same is true of versioning.
When several people collaborate on important information, the organization needs to know which version represents the current state—and may need to preserve what existed before it.
Who changed it? When? What was changed?
The deeper objective is not simply version control.
It is information integrity.
Businesses make decisions using information. If the underlying information cannot be trusted, the processes built upon it become questionable as well.
Workflow Turns Content Into Process
A document often exists because something is happening.
An invoice needs approval.
A contract needs review.
A claim needs processing.
A drawing needs sign-off.
Information moves because business moves.
Workflow connects the information object to that movement.
Who receives it first? What must happen next? What happens if it is approved or rejected? Does another system need updating? Is there a deadline? Who needs notification?
At this point, we are no longer primarily managing documents.
We are modeling business behavior.
A great deal of enterprise technology ultimately comes down to three questions:
What happened? What should happen next? Who or what is responsible for making it happen?
Lifecycle and Governance
Enterprise information changes over time.
Something can begin as a draft, become active, be approved, later superseded, retained and eventually become eligible for disposition.
The same information object can therefore require different behavior at different stages.
The important engineering principle is:
State matters.
A system may need to understand not only what an object is, but where it currently exists within its lifecycle.
Governance follows naturally.
Organizations cannot simply keep everything forever, nor can they arbitrarily delete information when storage becomes inconvenient.
Retention, records classification, auditing, legal requirements and disposition must participate in the architecture.
For those controls to work, the system first needs to understand the information.
Metadata matters.
Classification matters.
Identity matters.
Lifecycle matters.
Everything begins connecting.
That is systems thinking.
No Enterprise Platform Lives Alone
A content repository is rarely the entire enterprise.
Organizations have financial systems, customer platforms, databases, websites, identity systems, email, scanning environments and specialized business applications.
Content can originate in any of them.
This makes integration fundamental.
The objective is not to force the business to revolve around the content-management platform. It is to make governed information available to the applications and processes that need it.
That requires interfaces, authentication, data mapping, synchronization, error handling and an understanding of system dependencies.
It leads to another enduring principle:
A system can work perfectly by itself and still fail the organization if it cannot work correctly with everything around it.
The enterprise is the larger system.
Capture Is More Than Scanning
In the EDMS world I entered in 2004, paper remained an enormous part of business operations.
Scanning was useful.
Understanding what had been scanned was more valuable.
Documents needed to be identified, indexed, validated and routed. Information might be entered manually, extracted from forms or supplied by another application.
The content then needed to arrive in the correct repository with the correct metadata so downstream processes could use it.
That distinction remains important:
Digitization and digital transformation are not the same thing.
Turning paper into an image digitizes it.
Redesigning how the information enters, moves through and serves the organization transforms the process.
The Engineering Behind the Interface
Users experience enterprise systems through screens.
Engineers learn to look behind them.
Behind Search may be indexing, metadata, repository queries and security filtering.
Behind Approve may be workflow state, business rules, audit history and integration.
Behind Check In may be version control, locking and lifecycle behavior.
The interface is only the visible layer.
The engineering exists underneath.
Working with enterprise platforms taught me to keep asking:
What has to happen behind this button for the result to be reliable?
That question extends far beyond ECM.
From Principle to Practice — Explore Lab 01
The concepts discussed here are not intended to exist only on the page.
Enterprise Engineering Lab 01 provides a working environment for exploring the architecture and engineering principles behind enterprise content management—from repositories and metadata to document lifecycles, security, search, workflow and information relationships.
The Lab is part of the Samuels Enterprises Enterprise Engineering portfolio and serves as the practical companion to this article.
LAB 01 — EMC / OpenText Documentum
Enterprise Content Management + Information Architecture
[ LAB 01 INTERACTIVE EXPERIENCE ]
EMC DOCUMENTUM/APPLICATION XTENDER
The Problem Has Not Disappeared
The technology has evolved considerably since my introduction to Documentum in 2004.
But the fundamental enterprise problems remain recognizable.
Organizations still need to capture information.
Understand it.
Classify it.
Secure it.
Find it.
Move it through processes.
Integrate it with other systems.
Govern it.
And determine which information can be trusted.
The interfaces change.
The architectures evolve.
The underlying systems questions persist.
Artificial intelligence makes that foundation even more important.
If an intelligent system is going to work with enterprise information, we still need to know what information is authoritative, what is outdated, what is confidential, who can access it, where it originated and what business context surrounds it.
An intelligent interface sitting on top of uncontrolled information does not magically create trustworthy knowledge.
Before information can become intelligent, it must first become understandable.
What Documentum Really Taught Me
Looking back, my introduction to Documentum in Orange County in 2004 was not simply an introduction to a software platform.
It was an introduction to a way of looking at organizations.
I began seeing relationships underneath the technology:
Content → Metadata → Identity → Security → Process → State → Integration → Governance → Retrieval → Delivery
Change one component and something else is often affected.
Enterprise engineering is rarely about installing an isolated piece of software.
It is about understanding relationships, dependencies and consequences across a system.
The document was simply where that lesson began.
From Managing Content to Connecting Content
A repository can bring structure and control to enterprise information.
But another question naturally follows.
What happens when employees need that governed information inside the business applications and processes where they already work?
What happens when the repository needs to become less of a destination and more of an information service woven into the enterprise?
That takes us to the next engineering problem:
NEXT — ENTERPRISE ENGINEERING LAB 02
OpenText Content Management / xECM
The repository taught us how to control information.
Next, we examine what happens when that information must meet the business where the business actually works.
Enterprise Engineering Series
Ewing R. Samuels III
Samuels Enterprises, LLC
Lab 01 of the 26-Lab Enterprise Engineering Series.
