Loading articles
Core path · 18 of 34
Understand how to organize, manage, and govern Content Fragments as an AEM implementation grows from a small set of content to an enterprise-scale repository.
Chapter 18 focused on reuse and composition.
We established that the same business content can support multiple experiences without duplicating the underlying content. Content can be composed from smaller reusable pieces, and different consumers can use only the parts they need.
That solves one problem.
It creates another.
As the number of Content Fragments grows, finding, owning, reviewing, updating, and eventually retiring those fragments becomes harder.
A small project can survive with a few folders and informal naming conventions.
An enterprise cannot.
Once hundreds or thousands of Content Fragments exist across products, regions, brands, languages, and teams, content organization becomes an architectural concern.
The challenge is no longer simply:
It becomes:
How do we make reusable content understandable, discoverable, maintainable, and governed as the repository grows?
Content Fragment reuse works well when the content repository is small.
Imagine a project that starts with a few product fragments:
The repository is easy to understand.
Over time, the content repository may contain:
AEM can store all of this content.
The difficulty is managing it.
Authors may not know where new content belongs.
Developers may find multiple models representing almost the same business concept.
Content teams may create duplicate fragments because they cannot find an existing one.
Editors may not know who owns a fragment.
Teams may continue using content that is no longer maintained.
A fragment may be technically valid but no longer relevant to the business.
These are not storage problems.
They are organization and governance problems.
A common first approach is to create a folder structure and consider the organization problem solved.
For example:
Products/
Category-A/
Category-B/
Category-C/
The folders provide physical organization, but they do not answer several important questions:
A folder tells us where content is stored.
Governance tells us how that content should be managed.
This distinction becomes important as the repository grows.
A well-structured folder hierarchy can still become difficult to operate if there are no rules around models, ownership, naming, permissions, lifecycle, and discoverability.
The same principle used for Content Fragment modeling also applies to content organization.
Content should not normally be organized around the frontend that happens to consume it.
For example, a structure like this may look convenient:
Mobile/
Web/
App/
But it encourages teams to think about content as belonging to a particular channel.
A better organization starts with the business domain.
For example:
Products/
Product-A/
Product-B/
Support/
FAQs/
Troubleshooting/
Marketing/
Campaigns/
Promotions/
The exact folder structure depends on the organization.
The architectural principle is more important than the folder names:
[!important]The repository should describe the content domain, not the implementation details of individual consumers.
If a mobile application is replaced by another application tomorrow, the underlying product content should still have a meaningful place in the content architecture.
Folder structure alone is not enough.
Names also become important when many people work with the same repository.
Consider these fragments:
Product1
Product1_new
Product1_final
Product1_final_v2
Product1_latest
The repository may technically contain valid content, but the naming gives very little information about which fragment should be used.
A naming convention should communicate enough information to make content understandable without opening every fragment.
Depending on the organization, naming may include concepts such as:
For example:
product-1001
product-1002
product-1003
is generally easier to reason about than names based on authoring history.
The important rule is simple:
[!important]Names should describe the content, not the history of how the content was created.
Avoid names such as:
These names describe temporary authoring decisions rather than business meaning.
Once content is consumed by APIs and multiple applications, poor naming also makes operational support harder.
Content Fragment Models are not only technical definitions.
They can also establish boundaries around what a particular type of content is allowed to contain.
Suppose an organization defines a Product model with fields such as:
The model establishes a common structure.
Without that boundary, different teams may create their own versions:
Product
ProductDetails
ProductInformation
ProductData
ProductContent
Some of these may represent almost the same business concept.
The result is model duplication.
Model governance therefore becomes important.
Before creating a new model, teams should be able to answer:
[!important]Does this business concept already have a model?
If the answer is yes, creating another model should require a clear reason.
This does not mean every organization should have one universal model for everything.
It means model creation should be intentional.
A useful governance process can define:
The goal is not to slow down authors.
The goal is to prevent multiple teams from independently defining the same business concept.
Folder structures become more important when multiple teams or business domains share the same AEM environment.
A large repository should have understandable boundaries.
For example, an organization might separate content by:
The correct choice depends on the organization.
There is no universal folder structure that fits every AEM implementation.
What matters is that the structure reflects a meaningful ownership or business boundary.
For example:
Products/
Marketing/
Support/
Corporate/
provides a different type of organization than:
React/
NextJS/
Mobile/
iOS/
Android/
The first structure describes what the content is.
The second describes how content is consumed.
Tags provide another way to organize content.
They are useful when content needs to be classified across dimensions that do not map cleanly to folders.
For example, a product might belong to:
Trying to represent every one of these relationships through folders quickly becomes difficult.
A fragment cannot physically live in multiple folders at the same time.
Tags can provide additional classification without changing the physical location of the content.
For example:
Product Fragment
Tags:
The exact taxonomy depends on the organization.
The important distinction is:
Folders provide structural organization.
Tags provide classification.
Tags should not become an uncontrolled replacement for repository structure.
A taxonomy with hundreds of inconsistent tags can create the same discoverability problem as a poorly designed folder hierarchy.
Reusable content creates shared responsibility.
That also creates a potential ownership problem.
Consider a product fragment used by:
Who is responsible for that content?
If the answer is unclear, maintenance becomes difficult.
A content architecture should define ownership at appropriate levels.
For example:
The important principle is:
[!important]Reusable content should have a clearly defined owner.
Without ownership, shared content can become everyone's responsibility and therefore nobody's responsibility.
Permissions should reinforce the ownership model.
Not every author needs access to every Content Fragment.
For example, a marketing team may manage campaign content while a product team manages product information.
Giving every team unrestricted access to every content domain creates unnecessary risk.
Permission boundaries can help enforce:
This is especially important for structured content that is consumed by multiple applications.
A small content change can affect several consumers.
Therefore, access to shared content should be treated as part of the architecture rather than as an afterthought.
Content does not exist only in two states:
created and published.
Enterprise content usually has a lifecycle.
A typical lifecycle might include:
The exact process depends on the business.
The important point is that reusable content needs lifecycle ownership.
Consider a product that is discontinued.
The Content Fragment may still exist in the repository.
It may even still be published.
If nobody owns the retirement process, applications can continue consuming outdated information.
This becomes particularly important in headless architectures because the content is no longer necessarily visible only through one AEM page.
A fragment may be consumed by several independent applications.
Retiring content therefore requires understanding its consumers.
Good organization is not only about putting content in the correct location.
Authors and content teams must also be able to find existing content.
This becomes critical when reuse is one of the architectural goals.
Suppose an author needs product information.
If they cannot find an existing Product fragment, they may create another one.
Now the repository contains:
Product A
Product A - Updated
Product A Information
Product A Details
The technical platform has not failed.
The content architecture has.
Discoverability therefore becomes part of reuse.
A good governance strategy should make it easy to answer:
The easier these questions are to answer, the less likely teams are to create duplicate content.
Content Fragment sprawl usually does not happen because one team deliberately creates a bad architecture.
It happens gradually.
A team needs a new content type.
They create a model.
Another team needs something similar.
They create another model.
An author cannot find an existing fragment.
They create another fragment.
A temporary folder becomes permanent.
A temporary model remains in production.
Over time, the repository becomes difficult to understand.
The solution is not to prevent teams from creating content.
The solution is to establish lightweight governance.
Before introducing a new model or content structure, ask:
If yes, reuse the existing model where appropriate.
Different field names do not necessarily mean a different business concept.
Every shared content structure should have an owner.
Understanding consumers helps determine the impact of future changes.
Content that has no retirement strategy tends to remain indefinitely.
A technically correct structure that nobody can discover will eventually produce duplicates.
Governance can easily become excessive.
If every small content change requires several approvals, teams may start creating workarounds.
The goal is not to create a process around every action.
The goal is to protect the parts of the architecture that have a wider impact.
For example, changing a product description may be a normal editorial operation.
Changing the Product Content Fragment Model is different.
It can affect:
The governance level should therefore reflect the potential impact of the change.
A useful principle is:
[!important]The wider the impact of a change, the stronger the governance around that change should be.
At this stage, Content Fragment architecture has moved beyond simply creating structured content.
There are now several separate concerns:
Modeling
What does the business concept look like?
Organization
Where does the content belong?
Classification
How can it be categorized and discovered?
Ownership
Who is responsible for it?
Access
Who can change or publish it?
Lifecycle
How is it created, maintained, and retired?
Consumption
Which applications and channels depend on it?
These concerns should not be solved with one mechanism.
A folder cannot replace a model.
A tag cannot replace ownership.
A permission cannot replace lifecycle management.
A Content Fragment Model cannot replace content governance.
Each mechanism solves a different problem.
Content Fragment architecture should be designed for more than content creation.
It should support the entire lifecycle of reusable content.
The objective is not to build the largest possible content repository.
The objective is to build a repository where teams can understand:
This becomes increasingly important as AEM moves from being primarily a page authoring platform toward being a content platform consumed by multiple experiences.
Chapter 18 established how Content Fragments can be reused and composed.
Chapter 19 adds the operational layer required to make that reuse sustainable.
The key principles are:
Reuse without organization eventually creates confusion.
Organization without governance eventually creates sprawl.
A scalable content architecture needs both.
Get an email when I publish the next chapter. No spam — just new technical deep-dives.
Comments
Share feedback or questions about this blog post.
No comments yet. Be the first to share your thoughts.