As I covered in my last post, Implementing an ECM Strategy without a Platform, you don’t need an Enterprise CMS Platform to implement a successful Enterprise Content Management Strategy. That doesn’t mean that you can’t use one or that using one would be the wrong approach. Just like there is no one-size-fits-all CMS, there is no single way to define and implement an ECM Strategy.

I am going to look at this in two stages. The first is going to focus on the purpose of and foundation for an Enterprise CMS Platform. The second is going to look at what capabilities a CMS needs in order to be a Platform.

Why a Platform

Let’s start by looking at the ECM definition so we can use it as a reference.

Enterprise Content Management (ECM) is a strategy for the coordinated management of all content throughout an organization, allowing for people and systems to find and use content from within any business context.

For the purposes of defining the goal of an Enterprise CMS Platform, let’s pull out a few key pieces.

• Coordinated management: Not all content might be located in the platform, so talking to other Content Management Systems is important.
• All content throughout an organization: If we are going to potentially put everything into one platform, it needs to have scale, security, and enough features to meet differing business requirements.
• Any business context: The system has be able to work with other systems and become part of the everyday business of an organization.

So there are some goals for a Enterprise CMS Platform to meet, but why a platform at all? Why not a specialized CMS for each business specialization and just integrate in the backend. Complexity.

Assuming that they are all CMIS compliant, which isn’t too  risky of an assumption for the current versions of most products, you can have them share information. Of course, if you have a lot of systems, you almost need an Enterprise Service Bus (ESB) to manage it all. Perhaps an Enterprise Content Bus? (Note to self: Stay on target topic)

Assuming you are able to manage the myriad connections, you still have all the different technologies from each CMS. That is a lot of specialized expertise to keep in-house.

Using a platform allows you to maintain one skill-set, reduce integrations because some business solutions can reside on the same system, and you have only one vendor to track down. You also won’t have the Account Manager from each vendor banging on your door telling you why they should handle all your content and not just a subset.

Suffice to say, there are pros and cons. If it is determined that an Enterprise CMS Platform is the right way to proceed, what do you look for from the vendors? Luckily, there are some answers.

Oh the Features!

What I am presenting here are a list of capabilities that are a minimum to look for in a platform. This does not mean that some organizations won’t require more from their platform. I am simply saying that if a CMS cannot provide these capabilities without a third-party add-on or custom code, then it isn’t a good choice to use as a platform to implement your ECM strategy.

1. Be a CMS: Seems obvious, but this is important. Last April I asked, What is a CMS? In that post I covered some basic features. A platform needs to provide every single one of them. No exceptions.
2. Advanced CMS Features: These are features that weren’t covered but would be required in a platform. Simply put: Relationships, LDAP directory support (not just Active Directory), composite documents, and renditions. There are probably more, but those are key.
3. Scale: Every organization has a different definition how much content is a lot of content. For some, a terabyte is a lot. For others, that is achieved several times a month. No system scales without effort, so I’m not saying that you don’t have to plan or architect. There is a simple measuring stick to determine if a CMS will scale. If I have to modify my business-focused logical design in order to have the system scale, that is a failure. For example, if I have a lot of correspondence and I should not have to create a new repository every year to accommodate a physical limitation.
4. Full Application Programming Interfaces (APIs): Simply put, I should be able to access every single function, with the possible exception of some administration/configuration features, through a documented API. Hard to tie the platform into the larger business system if one of the features that I need is missing.
5. Service Oriented Architecture (SOA) Interface: Be it RESTful or Web Services, these days a loosely coupled interface is required. This capability can meet the need for a Full API.
6. Standards Support: Standards are great and they simplify things blah blah blah. You know this. What this also shows is a commitment to play nice with others which is critical. The list of standards includes more than CMIS, such as SAML and XACML for identity management, and evolves over time. The list of standards is a post unto itself.
7. Workflow: This isn’t necessarily full-fledged BPM, but the platform needs to have more than just Lifecycles and simple approval routing. Complex processes with support for automated steps, rejection paths, and conditional routing needs to be out-of-the-box. That means I don’t have to write any code to create a workflow consisting of manual steps. None.
8. Collaborative Interface: This is the tricky part. You need an user interface for people to use for basic collaboration, not one that looks like Windows Explorer. Sure, you can leverage a newer Enterprise 2.0 community-type system for collaboration, but there will likely come a time when people may need to access the system directly. That interface should be collaboration focused, not be overwhelming, and allow access to any/all features of the system. Sounds daunting, but it can be done.
9. Records Management: While I am not suggesting full DoD 5015.2 support (unless you want that easy validation), a platform must  be able to lock content for retention, apply holds, and allow for different dispositions. This also entails complex security models and more audit trail capabilities than your standard CMS.

That is it. It may seem like a lot, but it isn’t. In fact there are more features that I look for in a go-to Enterprise CMS Platform vendor.

The Rest of the Story

There are specialized needs that aren’t uncommon. While you wouldn’t need to have all these capabilities to be an Enterprise CMS Platform vendor, it will limit you in the “ECM” market.

• Digital Asset Management (large file support/content streaming).
• Federated search
• Native XML support
• Forms (built-in or go-to partner)
• Content Analytics (built-in or go-to partner)
• Email Management (store email and attachments)
• BPM including specialized user interface (built-in or go-to partner)

I’ll tell you right now, there are only a few vendors that can really do all of this reasonably well. There are also a finite number of companies that really need everything in the primary list, much less items from this secondary list. For instance:

• If I use Active Directory internally, a vendor that doesn’t support other LDAP systems is still in play.
• If I’m not going to do any complex integrations, I can probably live without the full API.
• I can almost always work around the lack of standards support.
• Scale is in the eye of the beholder.
• I may decide that I don’t need a good user interface because only administrators will use it and they complain about everything anyway.
• As for Records Management, maybe I’ll just take away everyone’s right to Delete, keep everything, and trust upgrades in technology to keep the system scaling well.

The point being that just because a CMS isn’t a complete Enterprise CMS Platform, it doesn’t mean that it can’t serve as one for an organization with less rigorous needs. SharePoint fails on at least two of the basic capabilities, but it is good enough for many organizations.

And that is part of the art of ECM. You have to understand the needs of the market, the capabilities of the products, but realize that what is important at the end of the day is that people need to use the system. Make it too complex, expensive, or hard-to-use, then it will fail.

That is why people are pushing back on ECM as a concept. The problem isn’t the concept. The problem is that while there is a lot of prognosticating among analysts and consultants, the users just needs to get the job done.