Recently I’ve been trying to walk a narrow path. I have all but pronounced Enterprise Content Management (ECM) dead, and yet I have expressed a belief that Content Services need to be embedded into business applications.

The question is two-fold. How can you serve Content Services without a platform? Isn’t that ECM with a different name?

Yes and no.

Let’s dissect this apparent contradiction.

ENTERPRISE Content Management

The goal of ECM was to build one system that provided every Content Management application for an organization. You would build every application on the ECM platform, integrating tightly with other systems as needed. It was meant as a single monolithic system.

ECM failed.

ECM was all about buying licenses for everyone, creating a massive infrastructure, and forcing everyone to use the system for everything. It was great for the organization as it gave them the illusion of control. The problem was that users didn’t adopt it, found ways around it, and in the long-run, organization had only succeeded in creating one more location to look for content.

Content Services

So why are Content Services different?

The primary “Content” solution is collaboration. People create Content and share it with others. Presentations, strategy documents, budgets, and just about anything you’ve created and shared with people works well in a collaborative environment.

What happens when that Content is needed elsewhere? What happens when that Content is part of a business process?

Simple. That Content should be served to the systems where those business needs are addressed. If that presentation was given to a customer, it should be served to the CRM system.

Think about resumes. They should be in the HR system for recruiting, the CRM system to track who might be proposed on a customer project, and in a project website to help managers. Ideally, one copy of the resume would be served to the systems.

So how is this different than ECM?

We are providing services to one application. It could be multiple applications, but that isn’t the purpose of content services. We just want to have a way to say, “I need to manage Content in this business application. How can I solve this problem without reinventing the wheel?”

There is a concern that this might lead to more silos, but it won’t. With the growing support of standards like CMIS among vendors, the needed business applications can consume Content from multiple providers and surface it as needed within the appropriate business application. Federated search can be readily implemented to help users search across repositories readily.

I know this because a few years ago, I created just such a prototype using CMIS in my spare time. It took one hour to add vendor four to the search application. CMIS is VERY feasible.

What Vendors Need to Provide

What do we need when looking for a provider of Content Services? Well, we need a vendor to start. Random Open Source projects might work, but if you are building a business solution, you will want support from a vendor to help out when something goes awry.

Something ALWAYS goes awry. Hopefully in a few years that will no longer be true.

The solution needs to heavily support standards. They need to leverage Open Standards like CMIS, SAML, OAuth, and other interoperability services. Rewriting an interface for each vendor is a lot of work to create and support.

There needs to be a healthy supply of services built into the solution. CMIS is great, but an additional API that allows access to deeper functionality when needed is essential. While most items work just fine in CMIS, every now and then a business solution needs to do just a little bit more.

There needs to be a way to access and create content directly in the system. There is a lot of content that is created outside of business solutions. There needs to be a way for people to simply create, share, and collaborate on content from their native tools.

Finally, the solutions need to be able to readily scale. When I say “scale” I don’t mean I can create a 16-node cluster to handle my workload. That is important, but it should not be needed on day one. Scaling is really the ability to start small and to grow as needed without having to rewrite or rebuild the entire system.

Think of it as flexible architecture. When you are living in the cloud, it is called elastic architecture.

A Services Mindset

When you break it down, it is really a mindset. It isn’t trying to capture all the content for use in the organization. It is about providing Content Services to the business, wherever they may be needed.

Forget the tool. Provide the solution.