Do you really need a combination portal plus Web CMS?
Most Web properties require frontend presentation and "experience" services, as well as backend content management functionality. Most Web content management (WCM or Web CMS) tools provide both tiers of services.
However, as complexity increases—especially around advanced personalization, visitor permissions, integration and dashboarding-an enterprise may turn to the long-established approach of applying an enterprise portal framework.
But a question then arises: What do content managers use for publishing content? Enterprises have two broad alternatives here:
1. Use a single platform that offers both sets of services. That means selecting a portal tool that bundles a subset of WCM functionality internally or, alternatively, deploying a WCM tool that offers some "portal-like" presentation and integration capabilities.
2. Use two best-of-breed tools—a portal plus a Web CMS—and integrate them.
On the surface, the first option seems very attractive. It implies greater simplicity in installation, management, configuration and monitoring. It would seem to offer tighter integration between the content management and visitor experience tiers.
Yet, there are downsides to the "combination" approach that in some cases should point you to the second option: two separate platforms. So let's have a look at the pros and cons of each approach.
The case for using a single product
It's pretty easy to enumerate reasons for using a single product for both sets of services. Many portal vendors that offer WCM services will tout their "combination" approach as a strength. A short list of advantages includes:
- simpler administration—Installing, managing, tuning, monitoring and administering a single platform is easier than two.
- better preview—With a single tool for presentation and content management, your content contributors can more readily preview content in the context of how it will appear when delivered by the portal; also, in-context editing becomes much easier, with a more consistent user experience as you move from content management to portal and back.
- one less integration point to worry about—A large scale Web/portal project already brings many integration headaches, so why not reduce one?
- simpler vendor management—Managing licenses, vendor relationships, support and documentation also becomes easier when dealing with a single vendor.
- reduced training and resource costs—All of the above should ultimately lead to reduced operational costs.
Note that the magic word "simpler" appears twice. Remember, though, that you obtain those advantages only in ideal circumstances. In real life, your mileage will certainly vary. Much depends on whether the vendor provides both portal and Web CMS services in the same platform, like Liferay, or whether the same vendor sells two different products that have been integrated over time, like IBM WebSphere Portal + IBM Web Content Management.
The case against using a single product
At a high level, the case against a single-vendor, combination Portal+CMS solution stems from the age-old architectural mantra of maintaining a proper separation of concerns. That is, if you more cleanly decouple portal and WCM services, you can optimize each independently. That can lead to cleaner, more flexible and often more feature-rich implementations.
Let's review some of the benefits of a decoupled approach.
The first key issue revolves around editorial usability. Most portal tools that bundle Web content management or document management functionality feature an editorial interface made up of contribution "portlets." Real Story Group research reveals that many editorial users find a portlet-based paradigm unsuited for sophisticated content management services. Of course, your mileage may vary, but this is an area that you should test with your editorial people if you are considering portlet- or gadget-based tools for content management functionality.
As an example, in the screenshot on page 9 (KMWorld June 2013, Volume 22, Issue 6), you can see document management functionality implemented within a single portlet. The portlet has a plethora of options, all within a small space. That has many usability implications. For example, in this specific case, when you click on anything in the document library portlet, the page refreshes and the control goes to the top, even when you are actually trying to see a document from within that portlet. That can become irritating for power users. Using a better design (such as having a single portlet on a page) can circumvent the problem, but in any case, remember that it can be tricky for contributors.
Separate portal and WCM platforms can introduce complexity to a system. At the same time, many enterprises find that a combination Portal+CMS platform can become every bit as complicated as two separate systems. This has to do partly with configuration management: Portals are designed primarily to move code through a developer lifecycle. WCM platforms are designed primarily to move content through an information lifecycle. When you try to combine those two types of setups in a single install, there's a possibility of unnecessary complexity.
Moreover, you brook extra overhead. You have portal services running in your CMS and CMS overhead in your portal. That means more things can go wrong.
The kinds of analytics and reporting that get emphasized in a portal platform are very different from those found in best-of-breed Web CMS products. Portals tend to emphasize non-functional reporting such as caching, redundancy, load balancing and so forth.
If you get a Portal+CMS, one of the two will not be best of breed, so you will inevitably be compromising from a functionality standpoint. It's a bit like photography in today's smartphones. Most phones can take reasonably good pictures most of the time. But for truly great pictures on a consistent basis, you'll want a proper camera.
As an example, many WCM tools provide you portal-type capabilities via gadgets. However, that approach typically won't bring advanced capabilities such as role-based personalization, application integration and information aggregation, as you would find in a best-of-breed portal platform.
Finally, it is possible that your organization operates multiple sites pulling content off the same Web CMS system. Or alternatively, you might have a single site that draws content from multiple Web CMS systems. Or you might have a combination: multiple Web CMS systems and multiple portals feeding off each other. In such complex scenarios, a portal and a Web CMS tied at the hip will certainly not work. These days when mobile access to your Web resources is becoming increasingly important, you want to be particularly clear about which platform is driving what mobile experience.
Having a single product that offers both portal and Web CMS capabilities can be very useful, especially for simpler scenarios, or when you have a dearth of development operations resources.
However, as complexity increases, you may find that the benefits of separating those two concerns outweigh the additional costs and effort. Every enterprise will balance those approaches differently. Just make sure you create such a calculus before you lock yourself into one approach or another.