Managing Content On the Web

Enterprise portals have become a common component of IT infrastructures, and even if ?portal? remains an overloaded term, enterprises consistently rank portal technology near the top of their IT investment plans.

While much ink has been spilled about portals becoming the de facto platform for enterprise initiatives, there has been less discussion about the growing functional capabili- ties of portal products?including the increasing development of content and document management services. Meanwhile, many Web content management systems CMS- can offer information integration and delivery services common- ly associated with portal software. Some packages have always focused on website management, but the industry is seeing a new emphasis on interaction management, with vendors ranging from Ektron, FatWire, Hummingbird/RedDot, Interwoven, and Stellent, coming out with new and improved website management platforms that are portals in all but name. Given this overlap, it?s reasonable to ask: where do your content management systems end and your portal begin? We recommend avoiding labels and focusing on providing real value to information producers and consumers. To do that, you may have to make critical choices about how to divide labor between your CMS and portal. What is a Portal, and What is a CMS? For the most part, portal and CMS software represent two distinct product segments. But first, a caveat: just as there are signifi cant differences among the scores of content management packages in the marketplace, our recent research with portal customers around the globe suggests that what constitutes ?portal software? can vary dramatically across the 13 major solutions we studied. In general, though, portal software provides a framework for integrating information, applications, and processes across organiza- tional boundaries. Portals do this by providing a variety of business services such as collaboration and business intelligence- and technology services such as integration frameworks and security-. Content management systems, in contrast, focus on the creation and processing of information throughout its life- cycle. For Web content, though, part of that lifecycle is delivering information to end-users in the form of Web pages. Some CMS tools therefore also manage the delivery of content?in short, manage a website or intranet, as well as its information. To that extent, those products serve as a kind of lightweight portal, particularly since they may also offer integration and interaction facilities traditionally as- sociated with portal software. Similarly, most portal vendors are increasingly offering their own ?integrated? content management features. Typically they are less robust than what you would fi nd in a third-party CM or DM system, but depending on your requirements, the bundled version might suffi ce just fi ne, especially if you are only seeking to manage content within a portal framework, as opposed to publishing a standalone website. As a practical matter, for the business user in most enterprises, working with both CMS and portal software typically means work- ing with two very different interfaces. In our experience, integra- tion can be quite diffi cult and, therefore, few enterprises succeed at more than very high-level linkages between the two systems. You can draw a clear line, as some have tried, by saying that the CMS is responsible for managing content and the portal for information delivery. This leaves an important grey zone for managers: Where do we place navigation, site structure, and content preview? Which search engine will we use? Where will we integrate diverse content sources? And so on. Below we?ll explore some key areas where portals and content management systems overlap. Where to Assemble Web Pages? Both portals and CMS software can assemble dynamic Web pages on the fl y. From there, the differences begin. Portals typically con- tain their own content and metadata models. This means you must ?map? the information structures from your CMS to portal or vice versa. If the CMS ?pushes? content to a portal a common scenario for security and performance reasons-, you must arrange for a potentially very complex synchronization of content, metadata, templates, and fi les from one system to the other. In addition to possible delays in the publishing cycle, important usability issues emerge here. How can au- thors fully preview a page as it will appear on the site? The answer is, short of conducting Herculean integration, authors have to wait until content is physically promoted to the portal environment before they can fully understand what the content will look like, let alone where it will actually appear within the portal. And then, who owns templating and navigation? Most content management systems explicitly manage templates and navigation, but in a portal delivery model, the portal typically controls how pages are rendered. Several implications fall out from this. First, you simply may not be able to implement the rich navigational structures possible in a standalone web-site within a portal application. Perhaps more importantly, when content managers want to revise templates or site organization, they typically have to make a request of what is often a different team of portal administrators who manage the portal as a separate project. This can lead to delays and frustration for both groups. Who Should Personalize? The goal of personalization is to provide easy access to the ?most likely-used? content and services to website visitors. Most CMS packages focus on profi le-based personalization that is, you be- long to a particular group and therefore see a particular set of information or a particular presentation. Portals can work off profi les as well, and sometimes add preferences-based features i.e., ?MyAcme?- into the mix, although few users seem to actu- ally take advantage of this. Portals can also apply personalization rules to a wider scope of applications and information sources. It?s possible to tag content in a CMS so that your portal can deliver that content in a personalized way. As with other services, this requires mapping your CMS metadata scheme to that used by your portal, and arranging for a smooth promotion of metadata from one system to the other upon any additions or modifi cations. But the real truth is that most portal and CMS implementations tend to suffer from a dearth of suitably categorized content for a richly personalized experience. Which Search? Most portals embed stripped-down versions of commercial search engines. A portal?s bundled search engine typically integrates with the portal?s underlying security framework and should be aware of most though rarely all- of the different content and data repositories within the portal. That?s good for searchers. Many CMS tools embed stripped-down versions of commercial search engines. The advantage to using the search engine that comes with your CMS is that it is probably already configured to fi nd metadata in the right places and update website indexes immediately upon any editorial changes. That?s also good for searchers. Without signifi cant customization, though, the search engine coupled with your CMS may be less aware of content residing in other repositories. Many enterprises are working to standardize on a single enterprise search platform. However, this is not a simple or inexpensive exercise, particularly when the enterprise-standard search facility is slated to replace a more localized search engine that has been well tuned against a particular repository. But our point is: in the long run you may end up dispensing with both your portal?s and CMS search engines. Whose Caching? By accelerating the delivery of dynamic content, caching is critical to the performance of both portals and some Web content management packages. CMS developers tend to boast about their tools? caching algorithms, but the fact is, few of them can match the caching subsystems underneath most major portals. On the other hand, when content caching is turned over to the portal, contributors often complain of delays in content refresh, since the CMS must be confi gured to prompt the portal to fl ush any items from the cache that editors have updated. Moreover, portals bring their own overhead, and ?like many CMS packages? are plagued by nearly ubiquitous performance problems. Either way, don?t underestimate caching. It?s never a silver bullet. Both CMS and portal caching is complex. You might need to work with caching across multiple systems to obtain decent performance ?the ultimate measure of success here. Which Document Management and Workflow System? Document management systems enable enterprises to track and manage important documents throughout their lifecycle. The typical portal can easily expose document folders through simple interfaces. Of course, this will not relieve you of important integration choices, such as how to deal with document security, versioning, and reconciling different taxonomies. But we have increasingly seen lines blurring in the marketplace between lightweight document collaboration and portals, exemplified most notably by the tremendous success of Microsoft SharePoint. Most portals bundle lightweight document management and file-collaboration systems. For example, IBM WebSphere Portal bundles its own simple file repository, with its own versioning and workflow. This should not be confused with IBM?s heavier weight ?Content Manager? product, and also duplicates some file management capabilities in IBM?s various Workplace and Notes applications. In short, portal customers almost always have multiple choices for managing documents. Similarly, many commercial portal products bundle their own workflow services. Here, portal vendors are encountering the same problem as other software vendors: they may have multiple applications with different workflow subsystems, along with their own separate workflow services. In general, though, portal vendors seem to be re-orienting around business process management, orchestrating activity and information across disparate information systems with a breadth of integration capabilities you typically won?t find in a content management system. Extras, Anyone? Enterprise portals commonly include basic utility applications ?common applications that an enterprise might want to ?plug in? to a portal, such as:

  • polls
  • surveys
  • calendars
  • org charts
  • phone books
  • simple data collection forms
  • blogs and wikis

Increasingly, CMS vendors are embedding these tools as well, often as optional add-ons. Content management packages that provide these applications can usually boast integrated metadata and workflow frameworks, as well as ease of applying a common look and feel. However, portal products and their ecosystems of 3rd-party suppliers can supply a greater variety of these micro-applications, and they are more likely to be more tightly integrated with the portal?s access, security, and search subsystems. At the end of the day, CMS and portal suppliers will both claim that your diverse application requirements can be met with their products, perhaps in concert with a partner?s offering. In reality, you should expect to undertake substantial customization in either case. Both portals and CMS tend to be less out-of-the-box than most licensees expect, but to meet your additional requirements, portals tend to be far more mature and flexible as broader Web development platforms. Typically portals allow for integration to your developers? favorite tool e.g., Eclipse or VisualStudio-, while many CMS vendors make life quite a bit harder for developers. Reusable elements ?portlets or Web parts? are ingrained in the soul of portals, but remain more of a far-fetched dream in most CMS offerings. Your Choices At the end of the day you have some strategic choices. You can use the lightweight content management services in your portal until such time you need something more substantial recognizing that migration won?t be a trivial exercise-, perhaps making a bet that the portal vendor will become strong enough in this area to obviate the need to ever change. Similarly, you can adopt one of the many content management systems that offer content delivery services as lightweight portals, until such time that you need the more robust integration and delivery capabilities of a portal server recognizing that migration won?t be a trivial exercise-. Or you can do what most large enterprises do ?invest in both CMS and portal technologies and work hard to integrate the two. Indeed, most enterprises operate multiple content management systems and often possess more than one portal. From an enterprise architecture perspective you?ll want to figure out where to place what services. It?s tempting to draw neat boxes and arrows and be done with it, though you?ll find that discrete services are harder to decouple from their underlying platforms than vendors typically let on. But the choices you make will have a real impact on your colleagues as well as your customers. Your evaluation of alternatives should begin and end with their needs. Source: