Cleve Gibbon

Content models come in various shapes and sizes.  They can get quite large.  New content types get added, others modified, as well as those get removed. We can manage this by introducing content modules.

Some content types naturally belong together because of their relationship with other content types are stronger than with others.  This natural tendency for families of content types to come together into modules is the way for managing large content models.  We should allow content types that exhibit higher levels of cohesion – strong relationships – to live together withn the same content module.

A content module is a collection of highly cohesive content types.

Why Modularise?

Content is communication. We are continually disassembling and reassembling content to better engage with consumers, across multiple channels and multiple devices.  We need modular content in order to communicate with customers wherever they may be.

Fortunately, we have been doing this for years in the software industry.  Software has grown from the simple (calculators) to the very large (AI).  Modularity is about managing the very large as a society of well mannered smaller parts.  We are now embarking on a similar journey with content but the same rules apply.  The aim is to shoot for high cohesion content types within modules and a loose coupling between modules.  Geting this right gives us modular content.

Zooming In

So far, when we have been speaking about content models, we’ve been working with very simple examples, containing only a few content types.

Consider this simple content model.  It has a magazine that owns a bunch of articles.  Each magazine has a a publisher, and every article has an author.  The whole/part relationshp (the solid black diamond) between magazine and article tells me that these articles belong to the magazine, and only a magazine.  If the magazine is destroyed, so too are all it’s associated articles. Or another way of putting it, an article can only belong to a single magazine.

The article and magazine have an aggregration relationship (the solid white diamond) between author and publisher respectively.  This breaks the owner lifecycle so that when an article is destroyed, the author lives on.  Why is this important?  It allows an author to create multiple articles.  This is good because we don’t authors to disappear just because one of their other articles expires. These additional semantics we design into our content models makes them clearer from business folks to agree on, designers to present to custoemrs, and developers to build authoring tools to support content production processes.  If you’re new to content relationships, it’s worth brushing up on them.

Most importantly, given the strong relationships that exist between content types, or high cohesion, we may decide to put them together in the same content module and call it Division.  Our content model would now consist of a single content module called Division and inside that module, we have the four content types with the aforementioned content relationships.  And boom, we have our first content module.

Zooming Out

Typically, when people talk about a content model it’s just one big list or page of content types.  We need to break these up into content modules.  We do this by putting similar content types into a single content module.  There is no automated way of doing this.  It requires humans walking through what you have and thinking.  So we have articles, magazines, authors, and publishers right.  Let me put them into the same content module and called that Division.  You may then move on, creating more content modules for Distribution, Assets, Rights Management, and Film and arrive at a content model that looks something like this:

It depends upon how you organise the information space within your business.  The lines between the content modules indicate that the content types within them are related somehow.  The trick is to keep the relationships within content modules fast and furious (high cohesive) and inter-relationship few and far between (loose coupling).  That is all we’re trying to achieve with modular content.  Simple to say, a little harder to achieve 🙂

So, you can appreciate now that no two content models are the same.  They are completely dependent upon your business domain.  About how you organise your information space. Let’s go back and revisit our definition of a content model:

A formal representation of structured content as a collection of content types and their inter-relationships.

When you zoom out and add content modules, the above definition still holds.  But now your content model will have content modules and they themselves will have content types.  Content modules are organising vehicle for content models that have larger numbers of content types.

Content Modules

We’re nearly done but how do you approach this? What comes first, content modules or content types?

It’s not an either or position.  We progress both top down and bottom up.  The more we learn about  content types, the better informed we are about which content module they should live in.  If one does existing already, create one.  If it does, add it.  Or maybe it no longer feels right in an existing module, so move it.

Going top down, we may start with a well-understood business domain structure for content modules that we populate with content types over time.  I’ve found that people tend to feel comfortable starting top down or bottom up.  That’s okay, so long as to progress by doing both.

Just to leave you with a piece of advice, there is nothing rigid about content. Structure does not equate to rigid.  Don’t be fooled by that.  Content module names will get modified.  Content types will move between content modules.  Relationships between content types and content modules will change.  Nothing stands still with content.  Getting comfortable with that reality will see you valuing content modelling over the content model itself.  The later is a key output but the former is the outcome you really want for sustainable business change.

Where next?

• Content Modelling Home
  
  • Content Types
    
  • Content Items
  • Content Packages
  • Content Relationships
  • Content Modules (you are here)