Day: November 8, 2007

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.”