Recently in Portals Category

Cross-posted from the Web Content Management Blog...

On a recent phone call with a Gilbane Group client, we were asked about the defining differences between WCM applications and portal applications. This question has two answers – a theoretical one and a practical one. In theory, portals provide a doorway (portal < Latin porta, gate) that, when opened, allows content consumers to view a particular set of content. The exact set of content to which consumers are exposed is (a) dynamic, and (b) controllable either by the application administrator or by the consumers themselves. Because the function of the portal essentially rests in this “doorway” or “frame” function, some customers see portal software as an empty shell or framework, with a set of underlying services, to which content-connected portlets can be added. WCM applications, on the other hand, theoretically provide all of the features and functions required to create, manage, expire, and archive content. This feature set typically includes authoring and editing tools for multiple content types, automated workflow, versioning, audit control, channel management, metadata management, library services, templating, access controls, personalization etc.

In practice, however, the feature sets of WCM and portal applications often overlap. One vendor’s portal product might provide the same feature as another vendor’s WCM application. Because portals are composite applications that expose component applications, this phenomenon also extends to products or modules such as ERP, CRM, search, collaboration, campaign management, etc. For this reason, depending on how vendors group features and functions in their product offerings, any given set of WCM or portal requirements may be satisfied by a variety of product combinations. One vendor’s WCM application may suffice. Another vendor’s portal product may also be a good fit. And a third vendor’s solution may include WCM, portal, and collaboration modules.

Because of this variation in vendors’ grouping and naming conventions, Gilbane clients should, during the technology selection process, seek solutions to their set of content management problems without becoming distracted by the exact names or number of modules or products required to provide the solution. Let vendors include whatever products they wish in their RFP responses, but hold them responsible for (a) satisfying every requirement, (b) identifying the modules that satisfy each requirement, and (c) giving a total price for all of the modules included in the response. In the end, “WCM and portal” by any other name is still “WCM and portal.”

Our colleagues over at CMS Watch have published a new report on enterprise portals. As our earlier reports here and here on the portal market suggested, the list of vendors covered in the report shows the market is now dominated by infrastructure players. Janus Boye, the author of the report is giving a tutorial on Enterprise Portal Software: Architecture and Products - Intensive Review & Roadmap for Product Selection at our upcoming conference in San Francisco, and also speaking on Challenges in Integrating Portals & Content Management Systems. The report, tutorial, and conference session would be a great way to get fully up-to-speed on corporate portals and content management.