The Gilbane Report: Volume 11, Number 4Portals & Content Management Systems: Have Two Markets Become One?
July 2003
Download a PDF version of this article Read the news for this issue.
Portals & Content
Management Systems: Have Two Markets Become One?
When we looked at the demise
of the enterprise Portal market a few months ago we mentioned the close ties
between Content Management Systems and Portals. The historical ties, which go
back to some of the earliest corporate Web applications, are interesting. But
more pressing for today’s IT strategists, is where they should look to
buy Portal technology. Clearly, application platform and infrastructure vendors
dominate the Portal market in terms of market share, but CMS vendors are also
important players in the Portal market, and have the advantage of being close
to the content that feeds Portals. This fact is not lost on the platform vendors,
some of whom also provide some content management functionality. What should
you do?
This month Kathleen Reidy
takes a closer look at the ongoing market convergence, and provides some advice
on where to look for Portal technology and what to watch out for when selecting
vendors. This is Kathleen’s first article with us. She has been closely
involved with the Portal market for many years in previous roles as both a Senior
Analyst at Giga and a Product Line Manager for the Sun ONE Portal.
Portals & Content
Management Systems: Have Two Markets Become One?
IBM’s recent acquisition
of content management system (CMS) vendor Aptrix is a prime example of the market
consolidation that continues to bring enterprise portal products and content
management systems together. Given the spate of mergers and acquisitions between
vendors in these two areas, the question arises: are these two markets now one
in the same? Should you look to buy both portal and content management functionality
in one product? Do the CMS vendors today provide everything you need to build
a portal? Or will the large vendors that consumed the portal market (IBM, Oracle,
BEA etc.) slowly take on CMS functionality to own that space as well? What does
the future hold in terms of continued consolidation in these areas?
In “Corporate Portals
– Success Kills the Market” (Gilbane Report, Volume 10, Number
10), we looked at the dissolution of the market for stand-alone enterprise
portal products (or enterprise information portals). As we explained in that
article, small, portal-only software vendors have all but disappeared over the
last couple of years. There have been significant changes in the CMS market
as well, though it has fared much better than the market for portal products.
In this article, we’ll look at why this is the case and help you answer
the questions posed above.
Content Management Systems
and Portals: Different Origins
Content management systems
and enterprise portal products emerged to meet somewhat different, though often
overlapping market needs. Content management systems pre-date portal products
by several years, and were developed to help organizations collaboratively author,
control and publish large amounts of content to web sites.
Where CMS products were
used to create web content, early portal products were focused almost entirely
on aggregating existing content and data, or content that was created in other
systems, and delivering it via a personalized web interface.
The Gilbane Report has
extensively defined what a CMS is and does in previous issues. For purposes
of this comparison, in Figure 1 we’ll just provide a high-level set of
features initially offered by the products in these two market segments.
Figure 1.
Looking at Figure
1, the main difference between these two segments in the early days becomes
clear. Most content management systems were built entirely around the idea of
a centralized content repository that was the heart of the “management”
that the system was doing. It stored the content (or pointers to individual
documents or pages) and all of the information about that content (its metadata).
Most early portal products
did not have the tools to store, manage or publish content. They were instead
intended to deliver widely disparate content, data or application functionality
that was managed by a whole range of applications and systems that the portal,
in theory, knew very little about. Depending on the nature of the portal product
and its ‘portlets’ or ‘gadgets’, the source content
never moved and the portal might know very little about what was actually be
delivered in a particular ‘portlet’.
However, it is arguable
whether or not there ever was any standard definition of “portal”.
As the portal hype really
took off in the late 1990s, most every software vendor claimed to have some
sort of portal product. This resulted in a very confusing set of products that
were often difficult to compare one to another. In contrast, a CMS has always
been at least a slightly more definable product. The market for CMS products
developed to meet a clear set of customer needs.
CMS vendors were not left
out of early portal hype and more than one of them claimed to have a portal
product in the early days of the portal software frenzy. However, partnering
between the two was more common. The following is a list of vendors that were
early entrants into each of these markets.
| Representative
CMS Vendors |
Representative
Portal Vendors |
| Documentum |
Corechange
(acquired by Open Text 2003) |
| Eprise
(acquired divine 2001) |
Epicentric
(acquired by Vignette 2002) |
| Interwoven |
InfoImage
(ceased operations 2002/ assets acquired by ServiceWare 2002) |
| nCompass
(acquired
Microsoft 2001)
|
Plumtree
Software |
|
Open Market/FutureTense (acquired by divine 2001) |
Sequoia
Software (acquired by Citrix 2001) |
| Vignette
|
TopTier Software (acquired
by SAP 2001)
|
Table 1.
The market for stand-alone
portal products has dissolved as indicated by the R.I.P-type nature of the right-hand
column above (this market demise is also detailed more thoroughly in the earlier
article on portals referenced above). The nebulous nature of portal products
and their widely varied feature sets made it very difficult for a consensus
to emerge as to what it is exactly that a portal product should provide. This
led to a lowest-common-denominator definition of a portal product.
At its most basic, a portal
product is really quite simple to define: it is an aggregation framework with
tools for integrating disparate content and a mechanism for personalized web
delivery. It turned out to be rather easy for the large application platform
vendors to subsume portal functionality into their existing application server-based
platforms without even making major acquisitions in most cases. The last couple
of years have seen this market largely taken over by the large application and
platform vendors like IBM, BEA and others that were able to include a portal
as just one piece of a larger solution.
Customer Demand
Drives Consolidation
As the portal market matured
it became clear that customers required a content management system to make
their portals effective and compelling. Portals require content. While part
of a portal’s value is to provide a single interface to widely disparate
content sources, portal business drivers also often dictate that substantial
new content be created to serve the needs of a particular audience – be
they customers, employees or suppliers. It is important that this content be
well integrated with all of a portal’s processes for information access,
search and personalization. For this reason, these two markets have become increasingly
intertwined.
Early partnerships between
the vendors in these two segments created a lot of headaches for customers.
Many of these problems persist today. The integrations between portal and CMS
products are still often superficial and inadequate to meet end user needs.
For example, the search and taxonomy functionality provided with a portal might
not be tightly integrated with the categorization and publishing mechanisms
provided in the content management system. This can result in recently published
content not being immediately available for searching via the portal or metadata
laboriously added to the CMS not being indexed by the portal’s search
function. Similarly, lightweight integration between the two systems can result
in substantial duplication in roles and privileges information stored in both
systems.
Organic and Inorganic
Consolidation
The portal and content
management markets have begun to merge in both organic ways, meaning natural
product enhancement and expansion, and inorganic ways, mainly company mergers
and acquisitions.
CMS products have grown
to have stronger capabilities for integrating and delivering content and data
that comes from disparate systems through the use of ‘virtual repositories’
and the like. Similarly, portal products have begun to add CMS features.
Content management systems
have also moved much more into personalized delivery, from their roots in large-scale
authoring processes. This can create confusion for the IT buyer, who might rightly
ask: “If my portal is going to provide the personalized home page or delivery
mechanism to my user and my CMS also has advanced personalization and content
delivery capabilities, which product is actually providing the front-end that
my user will see?” Competing capabilities for application integration,
aggregation and content publishing create the same type of confusion for buyers.
Figure 2.
Figure 2 shows how the
feature sets of these product areas have increasingly overlapped.
We should note that portal
products have also been enhanced in other ways, adding collaboration features
for example, that are not highlighted in this graphic as we’re focusing
particularly on the increasing overlap of portal and CMS functionality.
An important take-away
of this market consolidation is that as the portal market has changed, it has
gone in more than one direction. The basic portal features for aggregation,
integration and delivery, are easily provided today by the leading application
server and platform vendors. These vendors are also adding CMS features to round
out their portal functionality to meet customer demand. At the same time, the
CMS vendors have added more portal features, as indicated in Figure 2.
There are several products
on the market today that have been enhanced or were originally developed to
provide both some type of CMS functionality and portal capabilities, using our
most basic portal definition. Oracle’s portal product has always provided
some content creation and management capabilities as it was developed from a
tool that published database content to the web. Microsoft’s initial portal
offering, SharePoint Portal Server, was really a low-end document management
system in disguise. BEA Software recently added content management features
to its portal product.
In addition to the organic
growth that has affected these two markets, vendors have also made acquisitions
to put them in a position to better meet the needs of customers demanding an
integrated set of portal and content management capabilities. Table 2 shows
some of the acquisitions that have been made in this vein:
| Vendor |
Acquired |
| Microsoft |
NCompass (2001) |
| Plumtree |
Hablador (2002) |
| Vignette |
Epicentric (2002) |
| Open Text |
Corechange (2003) |
| IBM |
Aptrix (2003) |
Table 2.
Application Platform
and CMS Vendors Compete
These organic and inorganic
changes to the portal and content management markets leave us with a set of
products and competing vendors that look quite different than they did a few
years ago. There are now several vendors on the market that provide both portal
and content management features and/or products. These include BEA, IBM, Microsoft,
Open Text, Oracle, Plumtree, and Vignette.
This list is an interesting
combination of application platform vendors and CMS vendors. This is the current
state of this combined market.
There are still a number
of CMS providers who have not yet moved to provide the portal layer with a product
that is named and marketed that way. These include (and this list is far from
comprehensive): Documentum, FatWire, FileNet, and Interwoven.
The application server
vendors took the portal market easily because it wasn’t a real market.
It was never easily defined and it was not apparent that specific portal products
were required to build portals. The platform vendors that today own this market
see that CMS functionality is also required to meet customer needs. However,
it is not as easy for them to move into this market as it was to move into the
portal market, unless they make large acquisitions of existing leaders.
CMS vendors are also able
to provide basic portal features, but are not attempting to provide full application
server and integration technology as this market is clearly owned by IBM, BEA,
and others to a lesser extent. It is somewhat risky for CMS vendors to blatantly
move into the portal market without alienating their platform partners. Vignette
is surely struggling with this today as it consumes its Epicentric acquisition
putting it in direct competition with portal products from its close partners
BEA, IBM, and Sun. However, as vendors like IBM and BEA begin to include CMS
functionality in their portfolios, this tension will increase anyway. At present,
the content management capabilities provided by the large platform (and portal)
vendors are quite limited, still leaving plenty of room in the market for the
high-end systems from the CMS providers listed above.
Making Smart Decisions
Amid Consolidation
What does all of this mean
to organizations currently looking to procure products to build portals and
manage content? There are several scenarios and areas of concern to be addressed.
Customers looking to implement
a portal that will include some capabilities to collaboratively author content
with workflow and approval processes, and publish this content to the portal,
now have some nicely integrated alternatives. However, there are several concerns
when taking this approach:
- If the vendor has come
to provide both portal and CMS functionality through organic means, it is
likely that the CMS functionality provided is very lightweight and will only
provide content publishing and management of content intended to be delivered
through that portal. These features will not be able to meet larger scale
CMS needs or enterprise-wide requirements. This situation can also leave the
customer without a proper upgrade path, as these are the only CMS features
provided by this vendor – there is no “pro” edition to which
the customer can upgrade.
- If an acquisition or
merger has occurred, the integration of the acquired product and company must
be carefully evaluated. Depending on how recently the acquisition took place,
the integration between the two products may still be very lightweight. It’s
also important to investigate the status of the acquired company. Have many
of the employees been let go or forced to relocate? Are the services people
that are expert in doing the implementation still with the company? What about
the engineers? No matter how good acquisitions look on paper, they are notorious
for falling apart during the more grueling integration phases. Make sure the
two merged companies will provide a product that is a cohesive whole, as opposed
to just a set of sales slides.
Customers should consider
looking to a single vendor with both sets of functionality when the CM requirements
are limited to a particular portal implementation or set of portals and where
tight integration between these features and the portal framework is required.
Many, many customers today
have already invested in a CMS product (or a portal) and are looking to make
existing products work well with new purchases. In cases where an organization
is looking to add a portal to an environment where one – or several –
CMS products are already in place, the choices are becoming quite murky. There
are still portal products on the market that do not bundle or require the use
of a particular CMS product or set of features. IBM can still easily claim that
its WebSphere Portal does not require any specific IBM CMS product. Sun Microsystems
does not provide any CMS capabilities and still partners heavily in this area
with its Sun ONE Portal Server product. In fact, most portal vendors today including
the likes of Plumtree, Oracle, and Vignette that claim to offer features in
both areas will still also be able to integrate with other systems.
Given that the drivers behind
portal implementations are often to aggregate and deliver disparate content
via a single interface, portal products had better be able to provide integration
with other CMS products. However, it is inevitable that partnerships between
these increasingly competitive vendors will suffer. The integrations will not
improve and are more likely to fall out-of-date with current versions. More
of the integration work will fall to customers. Customers can also expect that
they will increasingly be up-sold on a single vendor’s integrated product
set, rather than on its ability to integrate with products from other vendors.
This discussion is of course
only relevant in the context of your particular definition of “portal”
to meet your business requirements. It is quite possible that a CMS from a vendor
that does not explicitly claim to provide a portal product might suit your needs
just fine in building your portal. In evaluating the need for an explicit portal
product or set of functionality, think about the following areas:
- Aggregation framework:
does the CMS allow you to deliver data, content, and/or application functionality
that comes from or is tied to a wide variety of applications seamlessly in
a personalized view for your individual users? Are you able to do this without
having to alter the source applications and data? Does it allow you to easily
integrate content from other CMS products within your organization?
- Search / taxonomy capabilities:
does the CMS allow you to search across content that is not managed by it?
Most portals provide this and it’s also possible this requirement can
be met using a CMS and stand-alone search product such as one from Verity,
Autonomy or Google.
- Collaboration features:
does the CMS provide any functionality to enable portal users to collaborate
via the portal, both synchronously and asynchronously? This is fairly standard
in portal products today.
- Identity management /
single sign-on: this is an area of evaluation for both CMS and portal products.
Portal products increasingly provide capabilities to centrally manage users
and deliver applications, content and data to them via secure portals with
single sign-on. If this is a requirement and your CMS vendor can’t provide
it, look to a portal or a stand-alone identity management vendor like Netegrity.
These are just some of
the areas to consider when determining if an actual portal product is required.
As always, matching requirements to product capabilities is really the trick,
as opposed to getting locked into vendor and analyst definitions of market segments.
What Happens Next?
Given the rapid pace of
change and consolidation seen in this area over the last couple of years, it
can be difficult to predict where we’ll be in another few years. The vendors
that largely own the portal market today - the application platform vendors
- are likely to continue to expand their CMS functionality to meet customer
demands. However, it will be difficult for these vendors to make real inroads
in the high-end CMS market without making large acquisitions given the maturity
and sophistication of current leading CMS products. IBM’s recent acquisition
was of a small vendor – a tactic other platform vendors might follow to
provide low-end CMS functionality for their portal products in the short-term.
While there may be some
further consolidation, it is unlikely that the current leaders of the CMS market
(both those with and without an identified portal product) will go the way of
the independent portal vendors anytime soon. Content management is a larger,
more mature, and better-defined market than the portal market ever was. Unless
major consolidation occurs, it is not likely that any of the large platform
vendors will be able to make a real go at the established CMS vendors anytime
soon. Partnering between then will continue (with its inherent difficulties
for customers). The large portal / platform vendors will make inroads on the
low-end of the CMS market and provide this functionality with their portal products,
leaving the high-end CMS deployments to their CMS partners (running on their
platforms, of course) in the short-term.
Kathleen
Reidy, kathleenoreidy@yahoo.com
|
