Thursday, November 17, 2005

Why portals need content management

Why? Because Portal Products Lack Robust Content Management
A look at the origins of these two categories of products helps to explain why this situation exists. Content management systems emerged in the mid 1990’s as companies scrambled to put up Web sites. These systems allow organizations to collaboratively author, approve, and publish content. They are built around a content repository that separates the presentation from the content itself, while also allowing users to assign and store metadata with the content.
Portal products, on the other hand, were developed to aggregate existing applications and data,
and deliver them in a personalized manner to users based on their roles and preferences, through a Web interface. Early portals did not know anything about the applications and data other than how to provide secure access to them.
The early players in the portal product market where pure-play vendors such as Plumtree and Top Tier. Because a portal product is primarily an aggregation and integration platform, it was a natural Why Portals Need Content Management 6 step for infrastructure vendors like IBM, BEA, and Sun to extend their application server platforms to contain portal product functions.
It has not been nearly as easy for these vendors to add content management capabilities to their portal. IBM has acquired a small vendor to add lightweight content management. BEA has built a very simplistic content creation feature. Sun has no content management capabilities. All of these vendors maintain partnerships with leading Content Management vendors to support the needs of most of their customers.