Contented Management laughing buddha logo

Contented Management

Contented Management

Suitable content for a CMS

One of the biggest challenges for organisations with complex web architectures, particularly those trying to implement SOA, is deciding just what is appropriate for a content management system and what goes into AN Other application. Oscar Berg has had a stab, but I thought I’d try to give a few guidelines.

An indication that a project may be a good fit is if it meets any of these criteria:

  • Written (as opposed to numerical) content to be published within or outside the organisation and administered through a web browser.
  • Documents to be published internally or externally.
  • Digital assets used in conjunction with web or document publishing.
  • Information aggregated from other sources that subsequently needs to be edited by staff before it is published to an internal or external website.

An indication of a poor fit would be a project with the following requirements:

  • Structured numerical databases: this is more appropriate to a bespoke database application.
  • Draft, unpublished information that belongs to an individual, rather than to the organisation: this can be achieved with a file server.
  • Loose, collaboratively-created content, such as blogs, discussion forums and wikis, that don’t require peer review. This content is usually best managed through dedicated collaboration technologies.
  • Aggregated content that can be presented “live” on websites without editorial intervention. This can be achieved through a portal or an application server.
  • Integration of back-end applications to be presented through a common, browser-based interface. This can be achieved through a portal.
  • Archiving records to less expensive data allocations based on frequency of access or age of assets. This is a feature of a more advanced records management system.
  • eCommerce sites requiring automated cross-sell functionality.

There are some grey areas which might combine a CMS with another technology:

  • “Advanced” personalisation, where a website has to remember who you are while you’re on the website and deliver different content to you based on your profile. This is pretty straightforward in a CMS when applied to the homepage using cookies, but anything beyond this requirement is going to be complex to implement, particularly if your CMS is stateless.
  • Streaming media will require an additional dedicated server.
  • Single sign-on functionality would benefit from an identity management tool.
  • Web-based applications such as polls that need to be included on a website but are unlikely to be managed through the CMS.
Philippe Parker on 29 October 2007

Contented Management

Identifying online and offline workflow

It’s all very well me asking if your workflow is effective, but not much use without a practical example.

In enterprise content management, workflows are often deployed to represent the full content lifecycle, as in the diagram below (click on the image to get a full size version).

Example of a full content lifecycle.

These steps could all be recreated in your content management system and managed in an online environment, with notifications being sent via email to the relevant users at each step in the process. You’d need to ask, however, who would benefit?

This sort of workflow is likely to be less effective to implement in an online environment with comments flying around via email than a bunch of relevant people sitting down together and discussing the subject in question. Yes, there probably needs to be an audit trail with a clear indication of who changed what when, but this is only at certain stage gates. In fact, you could probably constrain almost any workflow to something along the following model:

Author creates draft → Internal review (reject or approve) → External review (reject or approve) → Publish → Archive after 6 months.

All the intermittent issues of who should comment on what kind of detail at what stage are tacitly understood, rather than made explicit online. But the review processes can only be instigated once the previous stage gate is complete, so you still have control over publication and, depending on your CMS, you have a more or less robust audit trail. Why over-complicate matters? Enterprise 1.01 will usually do.

Philippe Parker on |

Contented Management

Is your workflow effective?

I was recently working for an investment bank trying to flesh out compliance requirements and reconcile these with the needs of the marketing team.

- As someone in marketing publishes a new piece of content, I asked, do you need to check it’s compliant?- Yes, responded the compliance officer.- So do you need to be alerted by email when new content is ready to go live?- No.- How will you know when the content needs your approval then?

- They’ll come and talk to me.

- This is a large organisation. Do all the marketing people know who you are and how to get hold of you?

- Yes, they’re used to it for print materials.

- And is this how your colleagues prefer to act too?

- Yes.

- So you wouldn’t find any efficiencies in being able to login to the CMS to preview content before it’s published?

- We don’t really mind what format it’s in: a hard copy or transcript, or we’ll sit and watch a video or listen to a podcast. Everyone publishing marketing material knows the basic compliance rules, it just needs us to give the document a quick once-over before it goes out and that’s best resolved by chatting about it.

- The content may be going out in many languages and to many different geographies, should they all operate this way?

- There are slightly different compliance rules in different countries, but generally the compliance officers in each country work in the same way. They’ll just review the translation, ensure it doesn’t breach any special cases and trust the marketing people they work with.

- What about other content contributors, such as researchers? There’s a fair amount of churn in those areas so they’re less likely to know the rules.

- Research gets published to our subscribers only, so doesn’t follow the same compliance rules. We don’t need to review it.

- So as far as you’re concerned, the technology doesn’t need to enforce any workflows other than the reviews specified by the marketing department and their relationship with each operational area.

- No, we’ll just discuss everything face to face.

Increasingly we see CMS implementations focusing on how to translate business process improvement into CMS workflows. Content management systems are particularly adept at providing compliance rules around publishing rights and version management so should be ideally suited to enforcing and improving the publishing process. But wherever I go, I find resistance to enforcement of workflows by the technology. Why is that?

Part of the reason is of course general resistance to change. Another is transparency: everyone needs to know what it takes to push a piece of content live. They need to know that once they’ve made their amendments, whether this means the public can view their content or if someone else needs to approve. Some CMS workflows can obscure this. Another reason is fear of over-engineering: it’s far too easy to create overly complicated and unmanageable workflows that users then try to circumvent.

But the main reason is that many technologists conceive that we should always interact through technology, that IT automatically means efficiency, even where offline processes, however informal, can be even more effective. We don’t always need global collaboration software to publish a web page.

The key for the business analyst is to identify where the CMS can make real process improvements and provide value through its audit trail, rather than forcing authors into activities that hinder when they should be making lives easier.

Philippe Parker on | 25 October 2007

Contented Management

Projecting failure

There are countless reasons why project fail, which you’ll doubtless be able to Google if you haven’t experienced them for yourself already. Poor requirements definition, lack of leadership, weak controls, over-ambition and poor communication are among the reasons cited. But the real reason that many projects fail is because they are projects.

They fail because they’re difficult; that’s why they’re projects.
You don’t create a project for things that you know are easy. Maybe if you started creating projects for each person to start-up their PC each morning, you’d have some impressive project KPIs… This isn’t about being flippant, however, it’s about setting expectations. You run projects to exercise some degree of control so that you understand when something will be delivered, at what cost and who needs to be involved in delivery. Other work can be written off as business as usual, but a project needs its own attention. So you already know that it’s going to be tricky, that you’re not sure how best to address the problem… why then do you think that by putting in some kind of methodology everything would be hunky-dory?

They fail because the controls you have in place tell you they’re failing.
What the methodology does provide you with are the controls to monitor the work you’re doing. You should be able to monitor effort, milestones, risks and then manage these. But more importantly, if things are going wrong, the controls should be telling you sooner rather than later, so you know your project is slipping. With business as usual where the controls don’t exist, you don’t know things are going wrong until it’s too late: for example, you’re losing market share.

So the fact that it’s a project means that it’s more likely to go wrong and it’s more likely to tell you that it’s going wrong. So why are we so surprised when it breaches tolerance?

It’s not about defeatism: we have worked on successful projects. But let’s challenge the expectations before the blame-storming begins. Could we have implemented the system without running a project? Did we get any benefits from running the project at all? What can we learn from this project that went well, that we can implement in future?

To run your projects successfully you need honesty, clarity and experience. The first step is to be honest, clear and experienced enough to recognise that it ain’t easy, and that decent project management will tell us just how tough it is.

Philippe Parker on 18 October 2007

Contented Management

Devolution, or the origin of pages

You have the software, you have the infrastructure, you have the business process… now where’s the content?

All Creative Commons on flickr: monkey by babasteve, donkey by wollombi, beaver by laszlo-photo, bee by fotodawgThe knowledge chain
Content management depends on a technical knowledge chain rather like the food chain you see in the animal kingdom. The first link in the chain are your drones, doing the bulk of the content harvesting and compiling in your CMS. You then get the eager beavers in your editorial team who control the flow of the content by slowing its course and discarding anything that doesn’t serve the common purpose. There’s also a need for a great deal of donkey work: general tasks like administering users and braying at the drones and beavers who try to buck the system. Finally, you have the code monkeys, the tech geeks who seem to spend their entire time fooling about and gawping, but who still consider themselves primates because they can use a mouse with an opposable thumb.

The problem with this technical knowledge chain is that in many organisations, each layer is of an equal size. This means that there aren’t enough people contributing content and but too many people performing administrative functions, while the technology layer spends time fixing things rather than making enhancements. If you could delegate the simpler daily tasks further down the chain, reserving the few meaty tasks for the more technically skilled species higher up, you could ensure that only the fittest content survives to be published on your website. These CMS animals need to devolve.

The case for devolution
Devolution isn’t just a theory: it’s founded on solid evidence. Many organisations have thought in the past that by spending half a dozen days creating a CMS training programme they can then rest and everything will take care of itself. But the reality of your CMS world is a little different. Over time, the technical team will have adopted a position as alpha male. They dominate the environment to suit them, which means that it may be over-engineered and difficult to change. The authors and editors will have had comparatively little impact on the CMS world around them: they tend to be more dependent on the resources that their environment affords them.


Environmental impact
But if your CMS ecosystem is going to succeed, it needs these authors to break their symbiotic relationship with their super-users so that they can cross-pollinate content and allow the world to flourish. To achieve this, your CMS environment must evolve to meet its inhabitants’ requirements.

People with fewer technical skills outnumber each layer above: contributors, editors, administrators, technical.

The end result is a skills pyramid, where you invest the least effort in the people who contribute the most, because the resources are there for them to prosper. When your contributors are comfortable with the system, this makes it easier for the editorial team to assess content quality. They don’t need to focus on administrative tasks, but can refer these to a dedicated team of first-line support as required. And the technologists aren’t bugged by the mundane concerns of lesser species, but can get on with doing more important things instead.

Intelligent Design
Devolution is supported by intelligent design. Your CMS environment should be technically simple with transparent publishing models and familiar editorial interfaces. If you can focus on adapting the environment to help your users rather than training your users to fit with your software, then the technically meek but editorially able shall inherit the earth.

Philippe Parker on | 17 October 2007

Contented Management

Is it “what” or “how” that broke it?

A typical question I get asked when assessing failing CMS implementations is whether there’s a fundamental flaw in the product or in the way it’s been implemented. Some products are more difficult to implement than others, but businesses can be hasty in wanting to throw technology away when the implementation has failed to meet expectations.

While you can make any product do anything if you have an endless supply of time, money and ingenuity, it’s useful to have some idea about whether you need to throw your core product away to achieve your goals feasibly. So I thought I’d list a few typical warning signs that might prompt you to initiate a technology selection project:

  • Wrong technology stack — You’d have thought this would be obvious; but if you’re living in a Java world and you have a .Net, ColdFusion or LAMP product, you’re in trouble. This also applies to legacy systems coming out of support.
  • Unfriendly URLs — You could get around this with some clever rewrite rules, but it’s extremely tricky to do this in a really scalable and cost-effective way.
  • Incompatible workflow — If your CMS doesn’t allow you to implement your online publishing processes, you have a serious problem. Integrating a distinct workflow tool could be more trouble than it’s worth.
  • Running Active X components on a Mac — This is a way to alienate your user base. Don’t use anything that relies on Active X. Even if you’ve locked down all your editors’ PCs to use the same version of Windows, these components can be a headache. There’s plenty of tools out there that use cross-platform, browser-based technologies, so why give yourself this burden?
  • Auto-generated non-compliant mark-up — Many portals (including MOSS Sharepoint) provide you with default templates into which your content is published. Trouble is, they rely on HTML table layouts and JavaScript that are a long way off best practice for being well-formed and accessible. If this is important to you, it can take a lot of effort to fix. You have to weigh up this level of effort against the advantages the product gives you, or against simply throwing the tool away.
  • Poor security — A requirement that’s more obvious to some organisations than others. Some CMS (dynamic-delivery products tend to be more susceptible than those using static delivery methods) are prone to brute force attacks, so if you could be vulnerable to DDoS you should get this evaluated. You should also ensure that your product doesn’t suffer from SQL injections.
  • Lack of integration standards — If your CMS doesn’t work with your LDAP directory, you’re in for a world of pain…
  • Poor version comparison — As with workflow, does the CMS provide you with versioning and audit capabilities that match your business processes? If not, there are tools you can integrate with no little effort, but why wouldn’t you just pick a CMS that does all the red-lining and version comparison for you?

This isn’t an exhaustive list. What characterises these issues is that while you could address them with some outside-the-box thinking, the problem is likely to be so ingrained in the product that dumping your current technology is a more viable approach. And at that stage, when you look to select a new technology, all the points listed above should be the technical prerequisites you have when inviting suppliers to tender. During the selection process, you can then concentrate on organisational fit. This is a subject I’ll return to later.

But what if the reason your implementation is struggling isn’t listed above? It could well be down to the implementation. Most common things people blame on the product, but are actually a problem with how the product has been implemented are:

  • Performance — Hardly ever down to the product, in my experience. Can almost always be improved, if not completely solved, by improving infrastructure (not necessarily more licences) and information architecture.
  • Unfriendly WYSIWYG editorial interface — There are lots of free or cheap tools out on the market which provide friendly and standards-based ways for editors to add rich content to your CMS.
  • Poor classification systems — Products have limitations about implementing taxonomies and classification systems, but typically if you’ve trouble managing these in enterprise products, it’s more likely to be because of how you chose to do it rather than a fundamental flaw with the product itself. It may well require some bespoke work, but doesn’t mean abandoning your entire system.
  • Having to publish in multiple places to generate a single piece of content — This problem is more often found with component-based content management systems, such as Tridion and Percussion. Editors have to publish blocks of related content that then go through independent workflow processes only to be assembled on the same page. There’s an advantage that these are re-used elsewhere on the site, or translated into other languages more efficiently, but the big disadvantage is that editors are confused by what needs to be published in order to make one simple update. In my experience, the business blames the technology when it’s just down to how it’s been put together.

Hopefully this will steer you down the right path when you need to decide whose arse to kick: software supplier or systems integrator / design agency. But more than that, it should give you an idea about where to focus your energy for new requirements: do you need to run a technology selection project or can you build on the platform you have currently? We all know that things break, but if you know whether it’s the what or the how that’ll do it, you should be able to put some contingency in place, saving some blushes and some money.

Philippe Parker on , , | 16 October 2007

Contented Management

Ajax: hero or zero?

As yet another vendor introduces AJAX to their WCM offering, it’s worth considering what benefits these interfaces bring you. Last year, Jonathan Downes and Joe Walker at CMS Watch provided a great introduction to the subject of Ajax in content management systems, but there are a couple of other points you should consider.

Firstly, in the last year or so, users have become much more familiar with these kinds of interfaces. Most webmail systems make use of the tool and there are countless portal-type sites and map applications that use JavaScript to create smoother browser-based interfaces. This should mean that people will be more comfortable with richer interfaces than with simple web forms.

Secondly, Downes and Walker tell us that Ajax generally equates to better performance. While the interface may give the end-user an impression of efficiency, this isn’t necessarily the case for the server. Remember that with each interaction, you’re sending a request — albeit small — to the server. Given that most CMS licences run on a per CPU basis and many environments have as a consequence been under-specified, introducing these tiny rapid requests could put some serious strain on your hardware and your budget.

These interfaces can be more user-friendly than some client software, but as with any CMS selection process you just need to be wary, size your environment appropriately and test with real editorial users to see if they get the desired usability benefits. It’s pretty safe to say that the smaller the number of users, the more benefit and least risk in deploying these kinds of tools.

A final word of caution: in the Iliad, Ajax was certainly mighty. But he was passed over by his peers for a hero with more guile and ended up destroying himself. Is this the sort of technology you want to unleash in your CMS campaign?

Philippe Parker on , , , | 14 October 2007

Contented Management

Introducing taxonomy

Lots of people talk about taxonomy in content management, but its meaning and importance can be confused, so I’m going to try and provide a more concrete definition.

Taxonomy is about classification. It describes ways of naming, arranging and ordering things within a system. Those things may be books in a library, or plants and animals in biology.

Taxonomies are usually hierarchical and based on restricted terms. In biology, for example, there are a limited number of kingdoms, phyla, and classes. In the Dewey Decimal System, these restricted terms are based on numbers: Phonology (414) is an element of Language (400). These relationships are often described as ontological.

Dewi Decimal taxonomy: 400s as a subset of Language

Some things can belong in more than one place in certain classification systems. For example, a dish on a menu may be available as both a starter and a main course. These ways of looking at the item are often termed “facets”; so a Greek salad is both a type of dish (salad) and a course (starter).

Image showing Greek salad as a side and starter, while Russian is available as a starter only.

The “thing” in question may also have one or more synonyms which form part of a taxonomy. There is some overlap here with the functions of a thesaurus.

A recent innovation brought to the fore by websites like del.icio.us and Flickr is the concept of “folksonomy”. This allows participants to “tag” any page, image, or document according to their own vocabulary. As more people tag pages, these become related by shared terms, building up the classification system. This taxonomy is unrestricted: what one person calls design, another may call art, creativity, or even Photoshop.

How are taxonomy and content management related?
Content management typically addresses a number of key areas:

  • Production: providing the tools to enable people to create content.
  • Authorisation: ensuring that only relevant people are able to view and amend content.
  • Workflow: delivering content to people within the system once it passes through certain stage gates.
  • Storage and retrieval: providing a mechanism to store, find and re-use content held in the system.

Content management systems (CMS) can make use of taxonomy for authorisation and workflow, but they are dependent on taxonomy for storage and retrieval. Each page, document, or other asset held in the CMS is stored according to a predefined classification method.

There are different metaphors for this method. The taxonomy may be represented as types of document (e.g. contract), as departments with their own document silos (e.g. legal, marketing, human resources), as folders that represent some other business function (e.g. project start-up, initiation, execution, closure), or flagged with a value from a predefined list. Most CMS will use a combination of these classification systems so that content can be retrieved more easily.

Taxonomy vs. metadata

Taxonomy is often applied as metadata: that is data about data. Office documents have metadata assigned to them such as author and revision date. (To see this in your Office application choose File >> Properties and click on the summary tab.) Web pages also have metadata. There are a number of ways to view this, but the simplest is to choose View >> Source in your browser menu. Close to the top of the page you’ll see some HTML tags beginning meta name=”". The name attribute is the type of metadata they describe (description, copyright, keywords, author, etc.) while the content attribute holds the metadata itself. Metadata is often assigned from pre-designated classifications, so is an important part of any taxonomy project.

Where can I see taxonomy on the web?

In its simplest form, taxonomy on the web is represented as website navigation. Many of the techniques applied to develop taxonomy are used to develop more user-friendly websites. This includes activities like card sorting.

More complex taxonomies can be found at dmoz.org (a directory of websites) or, for medical research, GoPubMed.

Philippe Parker on , | 9 October 2007

Contented Management

Solid architectural foundations

I confess, I’m a sceptic when it comes to architects, for two main reasons.

1. What qualifies someone to be an architect in the first place?

If you meet an architect in the construction world, you know they’ll have studied the minutiae of building design for many years. But if you meet a user experience architect, an information architect, a system architect, or indeed an enterprise architect, what qualifies them for that role? How do you know if they’re any good?

There are some recognised models for “enterprise architecture”, provided by the Zachman Instititute for Framework Advancement or The Open Group Architecture Framework, but these don’t actually tell you whether your architect is sufficiently clued up about your CMS publishing model that s/he can get it to work with a proprietary HR system.

2. What use is someone who designs your project then walks away from it when you actually start implementation?

I think I’d like to be a project architect. I could come up with all the tasks, dependencies and deliverables to design a project, then hand it over to someone else and say “deliver that”. I’d know what all the tasks are likely to be, identify risks, assumptions and approach, but someone else could own delivery post initiation / inception. Anything goes wrong, it’s not my fault: I told you how to do it, so if the project goes wrong then it must be your fault.

It’s just the same for development. How many projects have you seen where the technical architect needs to be called in to resolve an issue because the development team couldn’t apply the technical design?

These days, Service Orientation is the order of the day, which makes having an architect a prerequisite for any web CMS project. So how do I overcome my scepticism and define what an architect should do and if they’re any good or not?

Pranshu Jain provides some insights into what you should expect from your architect: fundamentally the role is about picking the technologies that enable the business to meet its objectives. But this approach has led to some organisations having less technical architects who understand what various software packages do, but who don’t understand the in depth technical details of how the architectural components relate. This spells project disaster.

So my message to architects out there is get your hands dirty. Get involved in the project development and take ownership if things start to go wrong. It will help you to design better systems in future.

And my message to project sponsors and managers is that if you’re recruiting an architect and they don’t know what a reverse proxy is, they’re not going to be much use to you.

Philippe Parker on 8 October 2007

Contented Management

The mirror stage in content management

If you’re considering whether your organisation needs collaborative software or a CMS to fulfil its content management needs, you’re doubtless being confronted by a bewildering range of products that all seem to provide the tools to meet your requirements. So how do you decide if you need a wiki, a portal, or ECM?
It’s down to psychology, not technology.

Psychologist asks PC: So tell me about your relationship with your father.

Let’s refer to the Mirror Stage, a psychoanalytical concept developed by Jacques Lacan during the 1940s. The concept describes how infants imagine themselves to be at one with a mother who satisfies their every need. When a child cries, its mother will feed it, change it, put it to bed, or comfort it. When a child reaches between six and eighteen months old, it starts to realise that its identity is separate to its mother’s. It recognises itself in a mirror, has to learn to feed itself and will be told off by its father. In short, it enters a symbolic order where it now has to conform to social constraints in order to get what it wants. The early imaginary state provides gratification without context, while the symbolic order provides context but imposes boundaries.
Which psychological order do your contributors belong to? Do you want or provide an environment for them to express themselves freely, or do you need to contextualise them and the content they produce?
Collaborative tools assume a shared identity. Just as an infant considers its mother to be an extension of itself that responds to its every whim, users look to collaborative software as a personal tool that instantly fulfils their need for self-expression. In this imaginary order, contributors “write out their question in their blog and look for their community to respond and help them“. Compare this to a content management system, where you have both context and boundaries: contributors recognise that their content can only be published if it meets predetermined social criteria.
Some examples:

  • Folskonomy vs. Taxonomy: The most obvious difference between imaginary and symbolic orders in content classification. In folksonomy, users enter terms that help them understand their content and they imagine that other users understand these terms. In taxonomy, these terms are given a context and only predefined terms can be used according to a preordained structure.
  • Intranets: Is your intranet an environment for generating knowledge or enshrining it? If your staff use it to discover what’s going on across multiple locations and projects, they assume that content is representative of the work they do. If the intranet holds authoritative information that employees want to refer to (for example, HR policy), you need a tool that confirms their place in the organisation and that reasserts social context.
  • Web 2.0 vs. Web 1.0 sites: People who use social networking sites subconsciously assume that what is valid for them is valid for others: that their tags make sense, that their ratings (of YouTube videos for example) are relevant, that people will follow their myspace page. These assumptions may well be right, but context is limited to these assumptions. If I put a photo of Sophie onto Flickr and tag it accordingly, this tells me that there are other photos of people called Sophie on the site, but doesn’t tell me that it’s Sophie Marceau and I’m interested in pictures of French film actresses. It’s not clear of course that this is the information people are looking for, but a content managed system would presume this in its design. So if you go to a report on a football match on the BBC news website, it will provide links to more news about each club involved, league tables, fixtures, weather forecasts for that area and so on. The contributor doesn’t elect to have all this correlated information: the CMS provides the context automatically and imposes an authoritative order.

Of course, collaborative environments aren’t completely without context: any user who logs into the system has a distinct identity within the organisation. But the mirror stage in content management comes when you start to impose structure and workflow. If you need your contributors to put content in a specific place for easier retrieval, or to have their contributions approved before they’re viewed by a wider audience, then you’re imposing a symbolic order.
So when choosing your approach, ask yourself are you a mother or father to your users? Are you coaxing them, encouraging them to express themselves freely, or are you imposing a paternalistic authority?
If your organisation is essentially the same thing as your contributors, then an unstructured wiki is a viable option. This covers social networking sites, or collaborative research intranets. But if your organisation represents something more than the people it comprises, in line with a Gestalt psychology, then you need a content management system that enforces a shared identity rather than assumes it.

Philippe Parker on | 4 October 2007
Older Posts »