When should something become an object?

When discussions about implementing an ECM system begin, a lot of the talk is about documents.

• What metadata should they contain?
• What workflow should they follow?
• Who should have access to them?

However, there is another crucial consideration: Is everything we need a document?

Or should it be something else?

• Customer
• Supplier
• Contract
• Complaint
• Invoice
• Project
• Product

In a traditional document management mindset, we tend to think about everything as a file.

• A contract is a PDF.
• An invoice is a PDF.
• A project plan is an Excel file.
• A customer request is an email.

But the file is often just one representation of something that exists in the business.

This is where the concept of objects becomes interesting.

Knowing when to turn something into an object can change the way you design an ECM solution fundamentally, so let’s take a look at it!

The document-centric way of thinking

Let’s start with a familiar example.

Imagine a company that manages supplier contracts.

You might have documents such as:

• Supplier_Agreement_ACME.pdf
• Supplier_Agreement_Contoso.pdf
• Supplier_Agreement_Fabrikam.pdf

You then add metadata:

• Supplier
• Contract type
• Contract number
• Start date
• End date
• Responsible person
• Contract status

This is already much better than a shared folder. The document is no longer just a file. It has context. However, something is still missing.

In this case, the supplier is treated as metadata attached to the document.

That might be perfectly fine. But what happens when the supplier becomes important in many different business processes?

The supplier has:

• contracts
• invoices
• contacts
• certificates
• purchase orders
• quality documents
• complaints
• audits
• correspondence

Suddenly, “Supplier” is doing a lot more work than simply describing a document.

It has become a business entity.

And that is usually the point where I start asking: Should Supplier become an object?

Metadata describes, Objects exist

This distinction is at the heart of the question.

Metadata answers: What is this?

An object answers: What exists in the business?

For example:

A document might have metadata saying:

Supplier = Nordic Components

That’s useful.

But if “Nordic Components” is an object, we can start saying:

Contract → relates to → Nordic Components

Invoice → relates to → Nordic Components

Certificate → relates to → Nordic Components

Complaint → relates to → Nordic Components

Now “Nordic Components”is no longer just a value in a metadata field.

It becomes a piece of the information model, offering a fundamentally different way of thinking.

Use metadata to describe an object. Use relationships to connect objects.

Not everything should become an object

This is important.

Once you discover the concept of objects, it can be very tempting to treat everything as one.

But that’s a mistake.

You don’t need an object for:

• document language
• document type
• creation date
• priority
• confidentiality level
• department
• status

These are characteristics, they describe something.

They don’t usually need an independent identity.

Creating objects for every piece of information can make your ECM model unnecessarily complicated.

So the question isn’t: Can I make this an object?

Almost anything can be modeled as an object.

The better question is: Should this be an object?

So, when should something become an object?

There isn’t a single universal rule. But I use a few questions to make the decision.

Does it exist independently from the document?

Consider a customer.

The customer exists even if there are no documents associated with them.

You can have a customer with:

• no contract yet
• no invoice yet
• no correspondence yet

The customer still exists.

Compare that with the confidentiality.

Confidentiality does not exist in isolation; it is an attribute of something else.

That’s a strong indication that:

Customer → object

Confidentiality → metadata

Is it referenced by many things?

This is probably one of the strongest indicators.

Suppose you have: Supplier = Nordic Components

attached to 200 documents.

You could store “Nordic Components” as a metadata value on every document.

But now imagine you want to know:

• Which contracts do we have with Nordic Components?
• Which invoices came from Nordic Components?
• Which complaints are associated with Nordic Components?
• Which certificates are about Nordic Components?
• Who is responsible for Nordic Components?
• When does our relationship with Nordic Components need to be reviewed?

The supplier is no longer simply describing documents.

It is becoming a central point of reference. That’s where an object starts to make sense.

Does it have its own lifecycle?

This is another important question, if we consider a contract.

A contract might have its own lifecycle:

Draft → Review → Approval → Signature → Active → Expired → Archived

The document representing the contract also has a lifecycle.

But sometimes the business entity has a lifecycle that is larger than the document itself.

For example, a project might move through: Initiation → Planning → Execution → Closure

During that lifecycle, hundreds of documents may be created.

The project isn’t one of those documents. The project is the thing that connects them.

This is a strong argument for making Project an object.

Does it have its own attributes?

An object usually has information that belongs to the object itself.

Take a customer.

You might want to store:

• Customer number
• Name
• Address
• Country
• Customer type
• Account manager
• Status

These aren’t really properties of a particular document.

They are properties of the customer.

If you keep them as metadata on every document, you introduce duplication.

And duplication creates another problem:

Which value is correct?

If Nordic Components changes its address, do you update:

• 10 documents?
• 100 documents?
• 10,000 documents?

Or do you update the customer once?

This is where object-oriented information modeling starts to provide real business value.

Do users need to navigate to it?

This question is often overlooked. Consider how users actually work.

A user may not start with: I need to find a document.

They might start with: I need to work on this customer.

Or: I need to see everything related to this project.

Or even: I need to understand this supplier.

The document is then only one part of the information they need.

If users naturally think in terms of an entity, that entity may deserve to be an object.

Instead of navigating through folders:

Customers → CustXYZ → Contracts

you can have a relationship-based information model:

CustXYZ

• Contracts
• Invoices
• Certificates
• Complaints
• Correspondence

The difference is subtle. But the user experience can be completely different.

The object should have a reason to exist

As mentioned above, there is one rule that I find particularly important:

Don’t create an object just because you can. Create one because the business needs it.

This sounds obvious. But it is surprisingly easy to create overly complex information models.

For example, imagine a project document with:

• Project
• Customer
• Country
• Department
• Manager
• Product
• Business unit
• Region
• Cost center

You could potentially turn all of these into objects.

But should you? Not necessarily.

If “Region” is simply used to classify documents, a metadata property might be enough.

If “Product” has its own lifecycle, documents, specifications, certifications, and relationships, then perhaps it deserves to be an object.

The distinction is not technical. It is about business meaning.

Objects connect information

This is where the model becomes much more powerful. An object isn’t valuable simply because it is an object. Its real value comes from what it allows you to connect, reuse and understand.

Imagine you have:

Customer

↓ has

Project

↓ governed by

Contract

↓ generates

Invoice

↓ supported by

Documents

Now the information is no longer a collection of isolated documents. It becomes a connected business context.

The question is no longer: Where is the document?

It becomes: What does this document relate to?

But what about the document itself?

This is where things get interesting!

Sometimes, the object and the document are closely related.

Take a contract, for example.

Is the contract an object? Or is the PDF the contract?

In many cases, you actually need both.

The contract object represents the business entity. The documents represent the content associated with that contract.

For example:

Contract 2026-001:

• Contract number
• Customer
• Start date
• End date
• Status
• Contract owner

Related documents:

• Proposal contract
• Signed contract
• Amendment #1
• Amendment #2
• Renewal letter

The contract now has its own identity and context, while the documents provide the actual content.

This distinction is particularly valuable when a business entity is represented by multiple documents over time.

A contract doesn’t disappear just because the initial PDF is replaced by a signed version.

Similarly, the customer doesn’t disappear just because a contract expires.

The project doesn’t disappear just because the project plan is updated.

The object represents the business entity.

Documents represent the associated content and evidence.

Once you start thinking this way, relationships become much more than a technical feature. They become a way of representing how the business actually works.

And this is where ECM becomes information management

This is, for me, one of the most interesting evolutions in ECM.

Traditional document management starts with: Where should I store this document?

Metadata-driven ECM moves to: What is this document?

Relationship-driven ECM goes one step further: What does this document relate to?

And object-oriented information management goes even further: What business entities exist, and how are they connected?

That’s a very different mental model. The document is no longer the center of the universe. The business information is.

The real question

So, when should something become an object?

Not when the technology allows it.

Not because objects are more sophisticated than metadata.

And certainly not because we want to build the most complex information model possible.

Something should become an object when it represents something the business recognizes as existing in its own right.

That’s the shift.

From: Where do I put this document?

To: What is this?

Then: What does it relate to?

And finally: What business information are we really trying to manage?

Because once you stop seeing the document as the center of the ECM world, a lot of things start to make more sense.

The document is only one piece of the information. The real value comes from understanding what it represents, what it relates to, and how it fits into the business. Want to find out more?