ECM-WCM-Portal
Do you need an ECMS, WCMS, or a Portal?
by Tony Byrne
25-Sep-2007
Sometimes it's hard to know. The lines between all content technology families are notoriously blurry.
This seems especially case among Portals, Enterprise Content Management (ECM), and Web Content Management (WCM) systems, where we see a lot of overlap in vendors, product functionality, and marketing messages. For example, if you're looking to implement Intranet-based document management, you could conceivably use any of those three types of products. Some consultancies will try to sell you all three types of solutions, with the obligatory integration project.
We strongly counsel taking a business approach that solves your most pressing needs first. Distill the core of your business problem or opportunity, then build from there. The reality is that these three different types of products do fairly specific things, and tend to address different problems. By understanding what you're trying to accomplish, you can better identify the types of technology you may -- or may not -- need. That's why we take a scenario-based approach to our research (c.f., WCM and Portals).
Three Sets of Scenarios
Take a quick look at the scenarios by which we review vendors head-to-head in some of our different technology evaluation reports.
As you can see, the WCM scenarios are fundamentally publishing scenarios. The type of website(s) you publish plays a big role in your requirements -- and the suitability of different vendors. Similarly, there are different types of portals that try to accomplish different business objectives. On the ECM side -- as you would expect -- the scenarios become more process oriented. Also, in the ECM space, industry verticals tend to matter more, again mostly because of process orientations, which tend to be industry-specific.
Overlapping Scenarios
Of course, the scenarios also overlap. A WCM tool that excels at "Community-oriented" sites may well look quite a bit like a "Collaboration Portal," which in turn might fit the bill for "Workgroup Collaboration" in the ECM space.
And what, you might ask, is exactly the difference among "Global Intranet" (WCM), "Enterprise Intranet" (Portal) or "Enterprise Web Publishing" (ECM)? Quite possibly very little. On the other hand, you should know that the tools approach the problem in different ways. The WCM solution will likely emphasize semi-structured content and documents with employee-friendly editorial interfaces. The Intranet Portal will bring functional focus to interactive applications (e.g., a people-finder portlet) and other services. The ECM product will likely provide native hooks from the Intranet into its own document and records management repositories. Ironically, our own research suggests that "enterprise-tier" vendors do a comparatively poor job at the kind of multi-website management scenarios you see in large enterprises, but that's another story. Anyway, you get the idea: even when there is overlap, different families of tools are likely to come to the party from different perspectives.
And perhaps more importantly, scenario-based analysis should tell you what type of product you shouldn't pursue. Just because a WCM tool claims it can store scanned documents in its repository doesn't mean you should use it for High Volume Imaging. Most ECM products likely provide a poor platform for a Customer Self-Service Portal. You probably wouldn't use portal software for an Ultra-large Single Website. And so on.
To be sure, vendors will often market the same product for different categories of problems, and sometimes that actually makes sense. The promise (and great frustration) of MOSS 2007 is that it can conceivably play in all of these three spaces to varying degrees, but, like its competitors, Redmond has different ways of getting there, and one SharePoint installation still doesn't want to play too many different roles at once. (Meanwhile, I haven't talked much about Enterprise Search or Content Component Management, but our forthcoming research in both areas suggests still more overlap and differentiation. -- stay tuned to this channel.)
What you should do
If you've been looking at tools at all, you've doubtless noticed that vendors (and many consultancies, and some analyst firms) tell a rather different story. Some use horserace concepts to distinguish solutions, trying to answer the ubiquitous question, "who's leading?" You should in turn ask, "leading at what?" If I've learned nothing in the last 12 years, it's that different scenarios favor different products.
Other commentators look at size. Large vendors with complex platforms claim that their smaller competitors can't scale, saying in effect, "Don't send a boy to do a man's job." Lower-tier players retort, "Don't kill a fly with a cannon." Yes, size and extensibility matter, and we typically include that in our own vendor categorizations. But from a business perspective, you risk losing the more important point around "fit" here.
You want to find a good fit with your business objectives. First that means figuring out which type of technology will provide the biggest near-term value. Then it means knowing what type of scenario(s) you're addressing, to begin to isolate vendors who potentially hit that sweet spot. It doesn't matter whether you employ our list of scenarios or not; the key thing is that you carefully outline what you're trying to achieve with which types of content. A little analysis here can save you a lot of time and money later.