Author’s Note: Considering the subject matter and length of this particular article, I’ve decided to split it into two separate articles.

Related Articles:

1. How to Fix Your Broken CMS: Part 1
2. How to Fix Your Broken CMS: Part 2

Background

In Part 1 of this series, I wrote at length about the current state of CMS software in general, and proposed a dramatic shift in our attention from features to user experience. At the end of the article, I offered a possible direction in terms of how to build a better CMS, and how we might better fulfill end user expectations (needs vs. wants).

In Part 2 of this series, I’ll be addressing the elements of what I feel would make a truly effective CMS.

Read on…

A Recipe For a Truly Effective CMS

Rather than approach a CMS as the alpha and omega of managing content, we need to approach it fundamentally: as tools to support people (and their myriad flavours of an editorial process).

Keep it simple. Keep it lean. Keep it efficient.

Ingredients

We need a few ingredients:

1. A system to facilitate the editorial workflow
2. A system to act as the delivery mechanism (loosely coupled with the presentation layer)
3. Enhanced user-profiles to determine access levels and the end user experience

Profiles

Let’s begin with the last ingredient (the element that binds all others together): the user profile.

The fundamental need here is to deliver a user-experience designed for a wide range of end users without becoming homogenous, meaning that the interface with which an editor performs her job can differ dramatically from that of an content author.

Generally speaking, a single individual can act in one or all of the following capacities:

1. The physical author of a piece of content
2. The reviewer of a body of content
3. The one delegated with the authority to promote content into another process

Note: these are fairly general roles, and granular capabilities/responsibilities/access rights should be introduced to reflect the organization’s needs.

The goal of a profile is to allow users (and those governing the process) to determine their desired user-experience based on both their role in the workflow, including selecting or customizing the interface that is ideally suited for their job function.

Everything else can be considered excess unless it promotes efficiency or enables productivity.

Example:

For simplicity’s sake, let’s assume that we’re talking about a content author—we’ll use Karen McNally as our archetype—whose only responsibility is to craft a piece of information and then promote it into the workflow.

Karen’s profile grants her access to a collection of her work (material that is still considered a work-in-progress, e.g. a “draft”), which she can edit or revise as necessary. When the piece of content is crafted and ready for review, she promotes it into the workflow.

Karen Smith has now fulfilled her fundamental role and responsibility as a content author. It is now up to another person—Michael Bloor, our ‘editor’ archetype—to review and make suggestions that she can implement.

Michael will then review Karen’s recent draft, suggest changes, contribute to the subject matter, and later promote it back into the system where it is then promoted further into the production chain.

What Karen likely sees in terms of an interface is a streamlined set of screens that:

• Allows her to quickly access her work
• Allows her to manipulate and edit her work, likely including suggestions for supporting material and media
• Allows her to “check-in” her work into the editorial workflow

In the example above, we know that Karen only needs a certain set of screens and features in order for her to fulfill her responsibility as a content author. At this point, the material is then subject to an editorial process that might repeat once or several times before it is then delegated to someone else in the workflow.

In her role, Karen has little interest in formatting for final presentation—that is someone else’s responsibility. She does care about ensuring some basic formatting to communicate the subject matter, and it’s likely that she does have an interest in providing other source material to support her work.

As for Michael, he likely sees a set of of screens that:

• Allows him to quickly access one or several drafts submitted to the editorial workflow
• Allows him to make modifications and re-assign the draft back to the original author
• Allows him to promote the draft into the production chain

In Michael’s case, he has a narrow set of responsibilities; however, his profile provides him with similar screens as Karen along with a series of screens that she would not otherwise see. On top of this fundamental difference, Michael has enhanced privileges that allow him to promote content or delegate content for other systems/processes.

The Delivery Mechanism

It’s a fundamental truth that a website will undergo change at some point—it might not be today or tomorrow—but it will likely evolve either through the introduction of new content or other factors like a redesign.

In the case of a redesign, many aspects of a website are affected: the underlying architecture, the look and feel, and in all likely hood—the content.

Considerations:

• Most CMSs tend to be focused on short-term execution, e.g. getting a website developed and running
• Most CMSs promote data-warehousing—a concept that is both dangerous in terms of potential liabilities for the organization, and inefficient in terms of productivity for the long-term users
• Most CMSs are developer-centric and unfriendly to those who are not familiar with the developer’s philosophy around content management and the resulting methodology applied to the system in question

What we’ve experienced are systems that are designed for short-terms success for a small group of users and long-term frustration for the intended users (Karen McNally and Michael Bloor in our previous example).

What we want is is a system that is still intended to facilitate the production of a website, but is a process that is loosely coupled with the task of managing content. This means that our once feature-bloated CMS should now be an efficient tool for developers and web-designers to execute the website’s look and feel and features without having to juggle data-entry at the same time.

Essentials:

• Integration with the editorial workflow
• Light replication of data in the form of content instances that can be modified according to the rules of the presentation layer (the website)
• A role-based interface for web-designers to execute the Information Architecture (IA) and Interaction Design (IxD) of the website, and apply presentation rules to content instances
• A role-based interface for developers to visually access an manipulate data specifically related to the features and functionality of the website
• An API for developers (font-end and back-end) to interact with content for enhanced presentation purposes or develop features for content dissemination

The marketers behind most CMSs tend to advertise the ability to manage all of a site’s information in one place, but they forget that information does not begin and end with the CMS. Content needs to live on in a universally accessible and secure location and should in all likelihood be subject to both the organization’s information governance policies and content strategy.

Given the above, we must now assert that a website should not to be used as an organization’s information warehouse, and that the concept of a content management system is most definitely a misnomer.

The solution that manages the nuts and bolts of a website is a system designed to do exactly that (and perhaps a little bit more if you need it to), but it should not be responsible for the long-term management of content.

This now leaves us with answering the workflow issue.

The Editorial Workflow

The editorial workflow is a system designed to support the creation and governance of content. All of the objects that comprise content (subject matter, media, resources, etc) are managed and governed by this system.

We can expect that a system like this can get convoluted and complex very quickly, but let’s distil things down to essentials before we start thinking about the additional requirements that are needed to support the essentials.

Essentials:

• Integration with desktop systems/software (e.g. minimum: importing documents into the workflow; ideal: leveraging existing software like word processors to provide a familiar interface)
• Version control and revision history to track the changes that are applied to a single unit of content
• The ability to apply a strong taxonomy with support for folksonomy
• The ability to link a unit of content with a collection of [supporting] source material (resource management)
• The ability to promote a unit or collection of content from one user to another
• Ensure access to the workflow is governed by user-profiles
• Ensure that interfaces for the workflow customized according to roles and preferences
• The ability to audit the collective content inventory (reporting)
• The ability to provide data mappings

The above list address both process and the need for flexibility for organizations that might have a strict or collaborative workflow.

Some considerations:

• Not all content is created equal, meaning that while text is the easiest to manipulate and consume, the method of presentation for the subject matter is what people experience; organizations will produce content in many forms—text being the most common—and the workflow is there to track and move it along from one process to the next. Assembly and integration into the presentation layer should handled elsewhere, e.g. promoted to another process.
• The workflow overlays the repository and it’s complexity, meaning that while content is still created by people it needs to reside somewhere and in some mutable form—a database for all intents and purposes; however, that does not mean that the complexity of the database be reflected in the user-experience. Quite the opposite is needed.

Sounds like a tall order? It’s not—the only thing that makes software complex is our unrealistic expectations. But we still need something to bridge the gap between the delivery mechanism and the editorial process.

The Secret Sauce: Data-mapping (aka, our “bridge”)

What is it?

Data mapping* is the process of creating data element mappings between two distinct data models. Data mapping is used as a first step for a wide variety of data integration tasks including:

• Data transformation or data mediation between a data source and a destination
• Identification of data relationships as part of data lineage analysis
• Discovery of hidden sensitive data such as the last four digits social security number hidden in another user id as part of a data masking or de-identification project
• Consolidation of multiple databases into a single data base and identifying redundant columns of data for consolidation or elimination

* Source: Wikipedia: Data Mapping

The point that we’re most interested in here is: “Data transformation or data mediation between a data source and a destination”

What we want to do is map content that resides in the editorial workflow to areas in the presentation layer (the website templates, pages, parts, elements, what-have-you). This means that we are only referencing the source content, storing an instance of that content, and applying presentation rules derived from the presentation layer (the website).

Let me re-iterate that: the intent is to avoid directly handling and manipulating the source material.

Further considerations:

• Instances of content are loosely-coupled, such that changes made to the source content do not necessarily affect the instance in the presentation layer until explicitly updated—we do this to preserve workflow and ensure governance
• Content changes are one-way, meaning that instances of content are just that—modification of the instances, such as formatting, do not necessarily affect the source content—we do this to maintain the integrity of the source content and ensure compliance with governance policies
• Instances are disposable, meaning that an instance of content might have a limited shelf-life; once decommissioned, the instance does not disappear completely. It still exists in it’s raw form in the editorial workflow

The reason we implement data mapping is simple: A CMS is a tactical system and should be decoupled as much as possible from the workflow, which is an operational system.

Effecting Change

For the record, this is why I think this approach would work:

1. The approach aligns with user’s needs (not wants)—we focus only on what the end user needs, and build only the features and systems that will help that end user be productive and efficient.
2. The approach bridges a fundamental gap between software and process—that is, it brings people back into the equation.
3. We are not re-inventing the wheel—that is to say that traditional models and workflows have continuously proven to work, and we can learn a lot from the hard lessons others have had to struggle through.

I originally wrote this segment of the article to reflect the top three reasons why this approach would work. Instead, I changed my mind half-way through to reflect the crux of my argument: Content begins with people and ends with people.

That is the single fundamental that we need to understand.

I wish I could simply say that the only reason why this approach would work is that, “We need it to,” but that would be pure fantasy. In the real world we’re faced with an infuriating mess of business requirements, politics, and budget constraints.

If we’re going to effect change, we need to build an effective business case that brings people back into focus, and only you—yes, you—can do that. If you’re a consumer, developer, or in a position to make these kinds of critical decisions, you have an opportunity (and responsibility to yourself and the people who work with you) to choose a better way.

What’s Left?

I’ll round this off with a challenge to the industry and to consumers. My hope is that someone with enough patience to have read through this rather long-winded series of articles, will embrace the fundamentals and concepts proposed here and evangelize them.

A Message for CMS Developers & Marketers

I am not alone in feeling that software falls short of our expectations when it comes to managing content; after all, we see content published everyday and in all manner of forms.

It should not be this painful.

As a response to the overwhelming volume of poor implementations of content management software currently being marketed, I say this:

Forget the bloated features. Forget about development paths and methodologies; spare us the complexity. The act of managing content should not be obfuscated by deep click-paths or radical dependencies upon development skills or fanatic devotion to technology—it should begin and end with the end user (we, your true customers) in mind.

We want software that helps us do our jobs better, not by imposing what you feel should be our workflow and methodology—we’ll determine that, thank you very much—but by supporting our processes with tools designed to promote efficiency and with productivity in mind.

A Message for CMS Users

We are part of the problem and we need to make a full stop. We need to re-assess our current expectations of a CMS are and what is realistic.

Forget the marketing crap. You’ve been misled.

Your CMS is broken. You know it. I know it. But does your company’s leadership—the decision-makers who bought into the CMS know it? Does your IT group resent you for having to do your job on top of dealing with their own?

You need to speak up.

You need to find a way to clearly articulate why your CMS is broken, and influence your decision makers to move in the right direction: not by wasting more time and money on trying to fix what was broken from the beginning, but by stepping back and re-evaluating expectations.

You know that you hate wasting time and feeling incompetent and frustrated—its especially frustrating when you see it done so well in other forms. You want that. And by ‘that’ you mean the process(es) that help traditional media get their content from concept to publication.

Adopting a better approach begins with knowing what you really need and tempering your expectations with pragmatism. You need to build a compelling business case for change.

Author’s Note: Considering the subject matter and length of this particular article, I’ve decided to split it into two separate articles.

Related Articles:

1. How to Fix Your Broken CMS: Part 1
2. How to Fix Your Broken CMS: Part 2

In recent weeks I’ve been fielding a number of questions from prospective clients and visitors to my site regarding criterion for selecting the right CMS for their website. More often than not, I tend to direct them to an article I wrote previously on this particular subject: Top 3 Myths of Content Management Systems – Feb. 6th, 2009

The article offers some recommendations on selecting the right CMS for your organization, and some insights into common myths surrounding CMSs in general; however, the article does not necessarily provide the desired criterion for determining what makes a good CMS (or not).

The reality is that they are all pretty much the same—big (and getting bigger), feature-bloated, and a serious impediment for efficiency.

In short: your CMS can most certainly be considered a serious productivity killer.

From my perspective, the issues I’ve mentioned above stem from a series of false expectations on the part of CMS consumers that exploited by CMS developers by and large.

Read on…

Background

In my previous article I ranked the following as the number one myth surrounding CMSs:

“Myth No. 1: A CMS Should Manage Everything”

The statement asserts what I feel to be one of the most misleading notions of CMSs—the ability of a single software solution to manage every aspect of a website. After further consideration on this particular myth’s origins, I’ve come to realize that most of this stems from aggressive and misleading software marketing. And we—the consumers—are partially to blame for this.

Why?

For some absurd reason, we have this strange notion that a single solution is all we need, and in response, software vendors develop and market to that notion. The current market is saturated by systems both open-source and licensed and all of them tend to suffer from the same problem: feature-bloating.

Feature-boating is one of the tell-tale signs—to me—that a solution is trying to be too many things for too many people. The solution in question is trying hard to manage too many things when really it should only manage a handful of tasks or better: support a well thought out workflow that is tailored to the organization.

It seems to me that the software vendors—CMS developers in this case—tend to forget the end user and their experience.

The Tired Debate(s)

There are several ongoing debates about the merits and flaws of content management systems and content management in general. Chief amongst these debates are the following:

• Content Management Systems are for IT only:
  The notion of managing the assets and objects of a website are the sole responsibility of IT for the simple fact that it is seen as a technical task and not an operational responsibility.
• Distribute the responsibility of managing content:
  The notion of decentralizing content management and enabling “content owners”—those seen to be subject matter experts or authors—to take responsibility of conceptualizing and publishing their content.

These are diametrically opposing views serve to illustrate the chasm dividing opinion as to how to circumvent the issue of poorly implemented CMSs. There are strong advocates of better practices and better approaches to managing content, with some strong arguments and proposals in favour of better processes.

The Perspective

For the most part these debates only touch the surface of the issue. The typical approach/solution is to look at the the type and makeup of the organization, its stakeholders, and their particular roles/responsibilities as it applies to the website’s business requirements. At that point, whomever is in charge of making the ‘big decision’ then selects a solution with enough features to address 80-90% of these business requirements.

The selection of a CMS is almost as politically driven as the content that it is supposed to manage.

The resulting solutions places the organization back into the same vicious cycle created by lack of infrastructure, inhuman methodologies, and an understandable fear of technology. As a result, expectations are not met and the organization falls prey to its old habits, falling back into old patterns.

And the familiar debate begins anew.

A Different Approach to The Problem

What if we’re looking at the issue from the wrong perspective? What if it’s not enough to simply circumvent the issue with more systems and software?

It seems to me that given the emphasis on trying to become software agnostic by re-focusing on process alone, or attempting to become software-gnostic by relying exclusively on the software, we overlook the fundamental problem: the software we choose is still broken.

What we should be doing is focus on the following:

1. A sound editorial process—a tailored (read: organization specific) workflow for getting content from concept to creation and eventually online.
2. A better understanding of what is content vs. resources—the difference between the subject matter of a website and the assets and objects that help to communicate the subject matter.
3. A shift in software development from Features to User Experience informed by Content Strategy—a fundamental movement by software vendors to move away from creating yet-another-CMS-with-identical-features-as-it’s-predecessors (accepting that the market will buy into software that addresses a fundamental need rather than a perceived notion).

The last two points—previously mentioned—are perhaps the two most underappreciated facets of building a better solution.

Resources vs. Content

In 2005 Adam Mathes published an interesting paper titled, “Source vs. Resource Ontology”. In his paper, Mathes attempts to present a better definition of resources in the context of electronic documents on the web.

There are some interesting insights in his work, and I particularly appreciate his pragmatic view of what resources are perceived to be in the real world.

A significant issue is that even pages we often refer to as being static are not in a strict sense, static, complicating things. “Small” edits over time, for example spelling corrections, change the resource content depending on your perspective. In many cases a “base” of static content is surrounded by dynamic content. For example, a news article that contains advertising. The “article” in one sense doesn’t change, but it is a dynamic resource in an important sense as the advertisements change. Other examples of small amounts of dynamic content in generally static resource include having the current day and time displayed on a page, even if the rest of the page is unchanged. Adam Mathes, 2005

This brings me to my point: we’ve been led to believe—through pervasive feature-focused marketing—that CMSs are able to effectively manage all aspects, assets, and objects of a website, e.g. “the content”. Resource are not Content. Resources are resources, and a CMS is little better than a crippled operating system sitting on top of a very complex database.

“Content” in the context of a CMS is both erroneous and problematic. It is erroneous for the fact that the fundamental experience of web is still text-based, and this is evidenced by:

1. Continued emphasis on producing text-based content first and media later;
2. Reliance on text-based search
3. Ease of access

The notion is problematic for the following reasons:

1. Content is abstracted to the point that a single piece of information cannot be distinguished from another by the fact that the “system” sees all as being equal. And often we see CMSs without strong implementations of a Taxonomy or Folksonomy solution to give the resources any meaning.
   Note: abstraction is necessary where software is concerned—after all, defining meaning and purpose is a human’s task and not the sole province of the the software; however, you still need your software to support that fundamental task.
2. As we incorporate more resources to communicate the subject matter of our content, the software intended to manage the resources requires a proportionate amount of systems or features to “connect-the-dots”—meaning that a a software’s complexity can be directly linked to the degree of abstraction as previously described. What we end up with is more “power tools for developers” and less productivity for those responsible for the long-term management of content (read: real people).
   Victor Lombardi’s article on Boxes and Arrows is an excellent resource that presents a good case for managing the complexity of content management systems.
3. CMSs emerge on the market with nearly identical features and with only small variations on their approach—and yet again, we still experience the emphasis on short-term development and less on long-term strategy and governance.

Emphasise “User Experience & Content Strategy” vs. “Software Features”

So far, I’ve made reference to several sources that go back as far as 2004—what that simply indicates is that serious issues with CMSs are not an emerging trend. They are in my observation, a continuing trend. And we continue to support that trend.

We the consumers—being a fundamental contributor to the problem of CMSs—have made it acceptable for software vendors to saturate the market with products that miss the mark completely when it comes to addressing a fundamental aspect of content management: Content begins with people and ends with people.

The Impact of Poor CMS implementations

If I am to sum up the impact of a poor CMS implementation it would be, quite simply: Frustration and Abandonment.

Both Erin Kissane, and Jeff Cram blogged about their particular frustrations and perspectives on CMSs and CMS implementations and their impacts on the organization. What’s interesting in both articles is that we see the continuing trend of the CMS getting in the way of efficiency and productivity. While Cram’s article nicely illustrates the frustrations of a poor CMS implementation (are there any good ones?), Kissane urges us to refocus on workflow.

…Create a workflow that works for your organization. Make sure your CMS supports that workflow. Erin Kissane

Users don’t care about the technology; they take it for granted that the technology will be there to support their jobs, but the sad reality is that the technology gets in the way. Again.

What users do care about is their experience with the CMS. Was it a good experience? Was it a bad experience? These are questions that influence decisions as to whether or not they will repeat the experience or abandon it.

When we talk about “user experience” in the context of a CMS, we’re talking about aspects like productivity, efficiency, and overall comfort level with the system in question. It is pretty clear to me that the vast majority of CMS developers take it for granted that their particular methodology of working with content (ahem, resources) is The Way To Go with little consideration for reality. And reality in this case is the end-user’s experience.

On Software Features

Software developers have proven that their ability to build pretty much anything in terms of systems to facilitate getting data into and out of a database. The feature lists of many of the available CMSs alone are enough to illustrate that point. But features alone do not make one CMS better than the next.

Unfortunately for the rest of us, those feature-bloated systems fall short in fulfilling expectations—one expectation in particular is that: I as a subject matter expert or content author should be able contribute to the creation of a body of information, without getting lost in the nuts and bolts of my CMS or without fear of liability (read: breaking the system).

Packing more features into the CMS compounds the issue. Stop. Take a good look at the audience—the people—who end up with the task of actually using the CMS after the development team has implemented it.

When it comes to audiences, it doesn’t matter if it’s an individual, a small business, or an enterprise-level organization that is using the CMS—they all have at least one thing in common: the end users are people who have jobs to do, not a heck of a lot of time to do it, and likely don’t have the patience to tackle the learning curb for that nifty new Cadillac of CMS [that is supposed to make their lives easier].

And when it comes to enterprise—there’s just a whole heck of a lot more of the same folks who share those same traits.

On Content Strategy

When it comes to the user experience with Content Management Systems, it has become increasingly difficult to discuss the topic without bringing Content Strategy into the conversation. And for good reason.

You cannot effectively implement a CMS solution without the Content Strategy to inform its use or role in the process.

There are some refreshing forward-thinkers out there like Kristina Halvorson, who make a compelling case for the necessity of a Content Strategy to help organizations effectively define and identify their priorities for content, and to teach better/pragmatic ways of approaching content for the web. In her book, Halvorson addresses the concept of a strong workflow to audit, capture, and produce better content through several phases.

What is compelling about her argument is that it is once again focused on people, not software.

Halvorson’s book, Content Strategy for the Web, does not cover—in full—CMS strategy (Software selection, design, and implementation)*

* Content Strategy for the Web, Kristina Halvorson, 2010, “What this Book Is Not”

Fundamentals First

Before we can start to improve the software we must also examine other models that have implemented a solid combination of software and process to provide a productive and efficient workflow that, well, works.

Case Study: The Traditional Editorial Process (aka Publication Production):

In an traditional news publication, the responsibility of conceptualizing/determining what is news worthy is left in the hands of the editors and may also be subject to a schedule [in the case of features].

It is the responsibility of the writing staff to develop the stories and craft them into something appropriate for the readership. Stories are then subject to editorial review and approvals, after which, it is promoted to the production cycle.

It is the responsibility of the production team to format the content into a presentable form—ready for mass consumption.

In the above example, we might see a single story evolve from concept to creation, and further evolution through review, contribution, and editing until it’s ready for publication. This is one flavour of the traditional editorial process, and may be present in more intricate or rudimentary forms in other organizations.

What’s notable about this example:

• A single story goes through a process and is handled by more than just one person (editorial process)
• A single story is always subject to a form of governance (editorial responsibility)
• The resulting story is then delegated to another process that shapes it according to the requirements of the medium (presentation)
• The system described above is a collection of several processes—the system of Publication Production.

What is still amazing to me is the fact that despite the evolution of software and the emergence of technology, the editorial process is still relevant. And they’ve been doing this every single day for decades without pause.

That begs the question: why—with all of the technology and knowledge at our disposal—are the content management systems unable to effectively replicate the efficiency and scalability of a traditional publication system?

The answer: software is the impediment—we the consumers and developers—expect software to do anything and everything with our content, forgetting that first and foremost that content begins with people and ends with people.

What we want is a solution (or set of solutions) that enables people to contribute to an organization’s collective knowledge, and ensure that the responsibility of disseminating content is left in the hands of people who [should] know where it goes and how best to present it.

A Little About the End Users

We need to recognize a few things about the typical end user:

1. Software developers have proven—ad nauseum—their ability to manipulate data in all kinds of interesting ways—the typical end user doesn’t care.
2. The typical end user doesn’t care about the fact that your CMS uses stored procedures or that you’re using ORM for database modeling.
3. The typical end user doesn’t care a wit about the technical marvels you—the software developer—have pulled off in order to make your CMS function the way it does.
4. The typical end user is concerned largely with the fact that they have a job to do and very little time to do it, but instead are starring dumbfounded at a screen loaded with all kinds of strange and confusing doodads that require a user-manuals thick enough to break windows.
5. Lastly, [most] people care about people—human interaction is essential in organizations, and the reason workflows, work, is due to human interaction that drives the workflow.

Considerations

This leaves us with a fundamental question to answer:

Q: If the goal is to de-emphasise feature development and emphasise developing better user-experiences for the end user, how do we do that?

A: We start by clearly establishing expectations (wants vs. needs) of what a CMS is and what it should do for us—the end users, and stop letting the software dictate our limitations.

A Unifying Concept

All of this talk about state-of-the-market and fundamentals is all well and good, but putting it to practice—truly developing and empowering CMS—is another thing altogether.

What we need is a unifying concept: the flux-capacitor to transcend the barrier of… well, you get the picture.

What this means is:

1. If we’re going to start with the user, we need to ensure we address the end user’s fundamental expectations by providing an experience that is designed for them, and not a homogenized user experience that is meaningless—one size does not fit all.
2. Content should not be managed in a silo but as part of a collaborative workflow—informed by strategy*, regulated through governance, and supported by technology.
3. The system should not enforce workflow through strict methodology or present technical barriers but provide flexibility—allowing greater access to the process/system to effect productivity and promote efficiency.

* I wrote earlier about the necessity of a CMS being driven by strategy—forgive the double-speak—but when I talk about strategy in the context of a CMS, I do mean both the Operational Strategy (the workflow, logistics, etc) and the Content Strategy (the heart and soul of Content).

Let’s summarize what we’ve been talking about so far into a set of actionable principles:

1. A CMS should not be the start-point and end-point of a content creation process (the editorial workflow), in fact managing content should be considered an on-going process.
2. A CMS should be a system that allows instances of content to be formatted and manipulated according to the requirements of the presentation layer (the website). Instances by nature can be disposable.
3. A CMS should be—at the very least—a set of loosely coupled systems: the first to facilitate the editorial workflow; and the second to facilitate production/publication for the presentation layer

With these concepts in mind, let’s focus on what’s needed executing the concept…

Cont’d, How to Fix Your Broken CMS: Part 2