The Gilbane Report: Volume 10, Number 10

Corporate Portals - Success Kills the Market

Download a PDF version of this article

Read the news for this issue.

Corporate portals or enterprise information portals (EIPs) have grown to be wildly popular over the last few years. Even before businesses were asking for them, vendors and analysts had realized that the inevitable takeover of the browser as the almost-universal interface to corporate information would open up new opportunities for information sharing. There were Intranets, etc. first, but portal was a more accessible and appealing term, and had the advantage of not being perceived as limited to Web content. Businesses were drawn to the simple yet powerful idea of a corporate Yahoo. It was, conceptually, an easy sell.

Given this popularity, why is it so difficult to find a vendor whose main business is selling a corporate portal? What happened to all the portal vendors? Why is the portal market essentially non-existent? And if it is non-existent, why can you buy reports that talk about its $2 billion +/- size? Finally, what does this mean and why should you, as an IT strategist, care?

The short answer is that the concept of a corporate portal has become too successful to be owned by specialist vendors. Almost anyone will sell you a portal today. Your job is to determine which set of technologies will translate into what your customers expect from a portal, without the benefit of a well-defined market. This month we look at why this has happened and what it means to you.

Corporate Portals Success Kills the Market

The practice of building corporate portals or, the more important sounding, Enterprise Information Portals (EIPs) is likely to be around a long time a new buzzword might emerge but the concept of a portal is appealing in its simplicity and descriptiveness - portal describes a user requirement succinctly [1.]. Unfortunately, there is a downside; the utility and popularity of the term may end up rendering it meaningless as a way to refer to a set of products. Worse, if you are a vendor, the market for portal products could evaporate. We suggest that this has already happened. What do you see when you look at the vendor landscape? You see 2-3 small vendors of portal solutions, a number of content management (or even search) vendors who will sell you a portal solution of their own, or in partnership with someone else, and every major enterprise software and platform vendor. You might wonder if there is anyone who wouldnt sell you a portal. Could all these vendors be selling you the same thing? Should portal functionality come from a pure-play portal product, a content management system, another enterprise application, an application server, a database platform? If you are looking at implementing a portal, you have to ask yourself what this means.

Whatever you think about the viability of portal products, as an IT strategist you need to consider market dynamics to make intelligent decisions about where portal functionality should reside in your architecture.

What is a Portal?

As usual, analysts, vendors, and users have a wide variety of definitions. All the definitions we have seen are fairly consistent, and include something like A portal is a single point of access to multiple information sources. Common attributes of more detailed definitions include requirements that a portal be browser-based, support some level of interface and information-feed customization, and provide access to information outside the direct control of the application or repository. Beyond this, definitions get much more parochial, and have more to do with vendor features, analyst attempts at differentiation, or customer application-specific requirements.

There are a couple of other characteristics of portal solutions that deserve mention.

Application & platform independence

The value proposition associated with pure-play portals is some combination of reach and neutrality. By reach, we mean how widely the portal product can reach for information basically, how many information sources it can access. Neutrality is assumed to be built into pure-play portal products by definition. However, pure-play vendors still make decisions about which applications to support when, and which platforms to support first, or at all.

While actual reach and neutrality both need to be understood when evaluating pure-play portal products. It is obviously even more important when you are looking at portal solutions that come from a platform or enterprise software vendor with even stronger preferences for, e.g., their own repository. Note that although portal has been used to refer an interface to a single vendor product/repository, this practice has mostly now stopped. An interface to a single ERP system or database is not normally considered a portal. Or rather, users may think of a particular interface into an application as a portal and there is no reason they shouldn't, but a vendor selling a portal only to their own application invites justifiable, or at least understandable, abuse.

Interactive vs. passive

In keeping with the etymology of portal, most portals today are passive they simply provide access, and this access is for humans. Portals are a publishing channel, and we integrate the information we access in our heads. Behind the scenes there may be all kinds of activity, but integration is usually limited to ensuring the user interface is consistent. Beyond that, information integration is the domain of middleware or other enterprise applications. There have been interactive portals from the beginning that included, e.g., interactive forms for HR applications, and most businesses need a mix of passive and interactive functionality. The interactive functionality is where the heavy lifting begins where application independence means more programming for integration and synchronization, and where platform independence requires non-trivial interaction between platform, middleware and applications software. This is why the market is dominated by the large players.

Where Portals Came From

Corporate portals were a conceptual marriage of early Intranet applications and Internet directory portals like Yahoo. Arguably the first corporate portals were sold by one of the first document management vendors to take web content management seriously. Information Dimensions, Inc. (IDI acquired by Open Text a few years ago) was selling browser-based packaged corporate Intranets with a single sign-on directory interface and the ability to gather documents and web content from various repositories in 1995. Plumtree, the most recognizable name in the portal market, was founded in 1996. I don't remember who was the first to come up with the term EIP (Enterprise Information Portal), but it was around this same time. iManage was also selling an EIP then, but decided the market was not yet ready.

What made the idea of a portal appealing, and in fact even possible from a practical point of view, was the browser interface never before (at least in computing) had there been such a universally adopted interface model. It was a natural next step to use browser technology to access information sources other than pages designed for the Web as early portal and content management vendors did. It was also natural for all other enterprise software vendors to take steps to ensure a third party wouldnt take over the interface between their customers and their applications. SAP was perhaps the first and most aggressive to take steps to protect their interest by both building their own portal and acquiring a pure-play portal vendor. The need to maintain account control customer access to your application ensured the ridiculously crowded market for portal solutions we have today.

Content Management & Portals

As we mentioned above, early portals were built with content management products, and many still are. Portals can be built with simple CMSs, e.g., FrontPage, or with industrial strength CMSs like Vignette et al . Today, content management vendors are often approached first for portal solutions. In fact, we have often been asked to advise businesses who say they want to choose a content management system, only to find their business requirements document is really specifying a portal application. This has resulted in most CMS vendors having portal vendor partners and vice versa . These partnerships are only appealing to the PR department and customers however. Portal and CMS vendors end up providing solutions that overlap too much for either of them to be really comfortable with the situation, especially given the current contraction in IT spending.

Although each type of vendor has mostly focused on a different part of the content management problem (CMSs on pure management and portals on access), from a customer point of view this differentiation has not always been either obvious or important. The solution to most business problems of sharing appropriate information with selected groups of employees or business partners in a managed way requires both capabilities. I would bet money that content management vendors still have more sales of portal solutions than pure-play portal vendors do. In fact, you could argue that there are no more pure-play portal vendors since Plumtrees acquisition of Hablador and Vignettes acquisition of Epicentric. (Corechange is the only one that comes immediately to mind.)

Gartner (or rather some Gartner analysts) talk about portals, content management, and collaboration capabilities all converging into a future of Enterprise Suites. I'm not so sure about that, however they are responding to the same overlap described above.

What is the Portal Market?

There used to enough freestanding pure-play portal vendors to suggest an emerging market. Most have been either acquired and/or deactivated. Even Plumtree, the mindshare leader, is not really a pure-play any more as they also sell content management based on their acquisition of Hablador. Some other acquisitions are in Table 1.

Table 1.

Although we argue there is no real portal market, there is of course a market that analysts measure, and vendors want to be a part of. As usual, the analyst firms have varying definitions and different research philosophies, but in the case of portals there seems to be a fair amount of consensus. The market is forecast to be about +/-$2 billion in 2003, depending on the analyst firm you ask.

Clearly, $2 billion is not based on the combined revenues of the rapidly dwindling numbers of pure-play portal vendors. Just as clearly, $2 billion is not based on IT spending for portal development, as such a number is bound to be dramatically higher. In fact, the size of the portal market is either tiny and shrinking, or it is too big to be meaningful this amounts to the same thing, an uninteresting market.

We haven't examined in detail how all the analysts do define the market, but obviously they are including the big guns (Oracle, Microsoft, SAP, etc. ) and some have included vertical industry portals, which distorts the market size for software as it includes content. Certainly, at least some of the content management vendors are included, as well as at least some of the EAI vendors.

Portal Frameworks

One approach to defining a market segment is to change the name or definition to something that includes an interesting combination of vendors. Im not sure who came up with the notion of portal frameworks, but it has largely become synonymous with portal. The Meta Group measures the enterprise portal framework market, and says the top 3 leaders are Plumtree, IBM, and SAP. It would be too easy as well as unfair to say something smug about what this means to Plumtree's future, but it is fair to point put that the market has become a very different beast.

Conclusions & Recommendations

So what's the point? Why should you care whether some analyst thinks there is, or is not, a well-defined portal market? Especially when your customers (assuming you are in IT), or senior management, want a portal? The answer is simple; you should listen to your customers, and your boss, and build them a portal. As we said earlier, it is a powerful and pleasing way to simply describe a need, and it is not likely to disappear anytime soon. Your mission, should you decide to accept, is to understand what they really mean, and to build a solution that is likely to include an unexpected combination of products and technologies. It will not be as simple as picking products labeled as portals or portal frameworks. But you should not discriminate against such products either there is no direct correlation between fitting into an analyst's worldview and being good technology. Sometimes these market landscapes can help, sometimes, as in this case, they mislead.

Think strategy

Think of portal initiatives or portal projects or portal strategies rather than products. The portal tools you may need are largely the same tools you need to build other types of enterprise solutions (EAI, EII, search and categorization, content management, access, permission, and security management, application servers, etc. ) Perhaps the only tools unique to a portal are the administration and set-up of the look-and-feel, configuration of the information sources, and provisioning new intranet members.

Portals do drive demand for content management, and application and information integration tools. You need to understand when these are required and plan ahead. In fact, it is more likely you will need some of these in place in order to build a portal that meets your customer's needs even if they dont recognize it.

Avoid monolithic

The best way to guarantee a failed enterprise portal project, is to think you can create an enterprise portal that will solve all of your employee's (or other constituency's) needs, and build in business rules or policies that attempt to enforce the portals use. You probably don't think this, but unfortunately, this is exactly why many organizations find portals an attractive idea a classic example of the all too common logical error of thinking that just because something ought to be, it will be. Even in small organizations there are too many different users with diverse needs, which are constantly changing. Many of you may be familiar with horror stories of workflow projects that failed for exactly the same reason thinking a there is always a single best way to accomplish something.

Add value

This is not to say that all big portal projects are bad. The point is that portal implementations need to account for user needs or they won't be used and all the purported benefits will never be achieved. And you need to add value. A portal should provide enough value to users that it is, at least sometimes, their default access point to information, and perhaps the only way to access certain information.

Temper expectations

Do you know any users of a corporate portal that actually use it as their only interface to information? Unlikely. Portals are typically only one of the resources users will check with their browser. You cant, and dont want to, try and limit users to portals. And no one wants to be forced to go through a portal to get to the Web.

Also keep in mind that extensive integration and interactive requirements call out for portal solutions that have deep ties to your infrastructure. The more value you add the more far reaching the maintenance. It will be tough to keep up.

Build portals; just don't think you only need to buy one.

Frank Gilbane
frank@gilbane.com

[1.] In this article, portal means corporate portal. Also, we are not talking about vertical industry portals, only products for building portals.