Moving from Content Management to Information Management

At what point does “content management” become “information management”? Put another way, at what point do you start using a CMS for managing information that’s not intended to be published anywhere?

We usually look at content management as managing stuff that’s going to be published somewhere. But if you have a good enough system that lets you model data well, why couldn’t you use it for about anything else?

Here’s an example that a Documentum sales guy told me when they were trying to sell the system to me. It may be a complete fabrication, but it makes for a good example. (And we bought the system, so apparently I fell for it.)

Ford Motor Company supposedly has Documentum installed on 40,000 desktops. They have a thick-client – VB6 at the time – and this example was done with that, but it could have been done with the Web client too.

Ford has an XML document for every single part in any of their products. Obviously, they have millions of them. This XML document describes all the features of the part – the price, the supplier, the dimensions, the weight, etc.

Documentum will let you combine content into “assemblies,” which are collections of multiple pieces of content. You can make new assemblies out of smaller assemblies, thus creating a big content tree of stuff.

Supposedly, Ford has assemblies for all the major subsystems of a car. Like this:

1. A bunch of XML part documents are combined into an assembly to represent the speedometer…

2. which is combined with other assemblies to represent the dashboard…

3. which is combined with other assemblies to represent the interior of the car…

4. which is combined with other assemblies to represent a Ford Five Hundred.

So, using this system, Ford can produce one big mother of an XML document that represents every single piece of anything that goes into a Five Hundred, which is pretty powerful. Since it’s in a native content management system, they get versioning and workflow and all the other stuff that makes managing this information easier.

Again, let me stress that this is all second-hand and it was coming out of the mouth of a salesman, so it may be complete crap, but the example holds true. There’s no reason you couldn’t do this.

Here’s another, more practical, example –

When you do Web development long enough, you get a big list of sites you’ve worked on. For each site, you need to remember a lot of things:

1. Name

2. Domain names (there can be multiple)

3. FTP username

4. FTP password

5. Which server it’s on

6. What platform it runs on (ASP, PHP, eZ publish, static HTML)

7. Who was the primary developer

8. Multiple notes explaining various things about the site so that when you sit down in front of it to make a change, you don’t have to follow code for 20 minutes wondering why so-and-so did this, that, and the other thing (you know, because everyone comments their code so well…)

We really need to put something like this together for our company, and I got to wondering what platform we could build it on. Then it hit me: eZ publish could do this beautifully.

That system models data with the best of them, and it would be trivial to outline this data. And given that the “admin side” of eZ publish is also a publishing side (see this post for a long explanation of this), why couldn’t we do it this way?

Have you ever been tempted to manage your contacts in a content management system? Ever liked a system so much that you wanted to use it inventory the contents of your home for your insurance company? Have you thought once that you could put your employee information in a system and then spit out XML to share it with your payroll service?

So, at what point does a content management system move beyond just managing publishable content, and start managing…general information? And is this good, or is this it the sign of a system that’s gotten bloated and lost its focus?