We often encounter companies who are trying to improve their web sites by implementing some sort of content management system. Portal vendors will sell them on the benefits of using portal technologies to integrate applications with content. Non-portal vendors will sell their products based on traditional content management features, such as site management, page creation, etc.
For many customers, the choice is very confusing because these systems are soooo different from each other. I’d like to take this opportunity to highlight the key differences and talk about how you can overcome this confusion to pick the right platform for your web sites.
Portal systems have traditionally focused on delivering integrated applications, of which content is but one application. As an example, when we think of an intranet portal, we might think about how to provide self-service access to our human resource and payroll system, which allows a user to update their benefit information and submit changes to their payroll tax withholding. At the same time, we need to display content such as a policy or help on the page. So our main focus is to surface and integrate those applications, but we also want to include some placeholders for content.
Web content management systems, on the other hand, have traditionally focused on building a page of content first and then providing some mechanism to integrate applications. So our content manager wants to display the policy or help for changing your benefits information and then give you a link to launch the benefits web page or application. These wcm systems have great tools for building pages and placing all sorts of content on the page.
Can you see the differences between these two approaches? Both are concerned with building web pages. Both want to provide access to content and applications. But portals typically start with an application centric view of a page while web content management systems typically start with a content centric view of a page.
These different viewpoints often account for the difficulty in achieving consensus when you go to choose a new web platform. Depending on each evaluators’ starting viewpoint one group will align with portal while another group aligns with a traditional wcm system. Often we see the IT people, who traditionally focus on applications, push for the portal platform, while the marketing people, where content is king, want the really nice web content management system. Equally often we see various user groups disappointed after implementation when the ‘system’ doesn’t meet their needs.
How can we deal with these issues?
First, understand with which viewpoint you and your evaluators start. When everyone is on the same page, you will be more successful. If everyone is not in agreement, you will need to find ways to move people from one viewpoint to the other or find common ground.
Along these same lines, make sure the people who are going to use the system become part of the evaluation process. The challenge here is that the more people involved in the process, the more likely you will have people with competing viewpoints. The benefit, however, comes from knowing when you might have competing viewpoints before implementation.
Most portal vendors now include pretty sophisticated content management features within the portal itself. So you can go to a portal page and edit content directly on that page. However, you must keep in mind that the portal considers content just another application; portal is there to integrate pieces of content into the page. You might find that creating a page is a very different interface than creating content. You may find that previewing your content in the portal is difficult. If your users are in the content-centric viewpoint, you may have to work harder to implement features in the portal to make the system more content friendly.
Web content management vendors are now including placeholders for applications on the page. For example, Adobe CQ5 includes a placeholder for portlets. So as you create a page where content is paramount, you can include a portlet placeholder where an application can live. In this example, your focus is on creating the page of content and, while the application or portlet is important, its not your focus. You may find that some of the web content management systems can satisfy some of your application-centric people, but this approach usually requires extra work to make the wcm platform more application friendly (such as adding single sign on).
Finally, you can go with the approach of implementing both types of platforms to satisfy everyone’s needs. But this approach creates the most work because it typically means a lot of custom development to integrate a portal with a different content system. I’ve blogged about ways to integrate WebSphere Portal and SharePoint with external content (see Options for Integrating External Content with Portal and Integrating Content with SharePoint 2010).