Portals Show Signs of Sanity


Merrill Lynch may well have released the only investment analyst report that created an entire industry, in November 1998. It was titled "Enterprise Information Portals" and written by Chris Shilakes and Julie Tylman. They defined an EIP as an application that enables companies to unlock internally and externally stored information to provide users with a single gateway to the personalized information needed to make informed business decisions. Shilakes and Tylman forecast growth rates of nearly 40% per year for this market, which was pretty ambitious even in pre-dotbomb days. Over the next few years, the number of portal vendors rose quite dramatically, and by 2001 there were perhaps more than 100 vendors in the market, none of them making any revenues worth counting. Which is why eight years later there are no more than around a dozen major players, and most of those are IT-industry giants like IBM and Oracle.

Over the last few months, portals have reared up again in my consulting business. The first instance of this was a client in the U.S. who wanted to provide a highly personalized web experience that would enable visitors to be presented with information specifically relevant to them, based on registration information and the pages that they had visited in the past. Now, Amazon is a good example of this approach, but it has taken a long time—and a colossal amount of money—to achieve a user experience like the one it currently offers. I am highly skeptical about the value of personalization at an individual level, whether on a website or an intranet. My experience, which is entirely anecdotal, is that after the initial excitement of being able to manage the flow of information to the desktop, the user refreshes the personalization profile on an increasing ad-hoc basis, until the time comes when they abandon it altogether. The result is that from that point on, the user is no longer seeing all the information that is relevant to his or her needs, and is likely to make seriously flawed decisions.

What I do see is that organizations can provide a lot of benefit in customization at a role level. So, for example, all marketing staff would see an intranet desktop that contains most (and I emphasize the word most) of what they need, derived from an intranet manager having developed personas into scenarios and tasks. Their view would also provide ready access to other sections of the intranet that complement the marketers' specific information. SAP is very adroit at this in its portal implementations, but it does not need portal technology to deliver customized pages.

The second example I recently saw was a client that had one of the best-organized global federated intranets I have come across, with very sensible levels of governance on the top levels of the intranet, extending even to local sites in national languages. However, the intranet team could only manage this by consensus, and they now face the challenge of how to accommodate portal implementations that have, to some extent, crept under the governance radar. One of the major issues in this case is that of usability. The portals themselves arguably meet the needs of a fairly small (in terms of the total employee count) group of users, but do so in a way that is totally contrary to the overall information architectural and design guidelines. The result is that other employees cannot easily use information on these portals. They may find a specific page through a search engine, but then lack sufficient knowledge of the portal to find related information.

Although there have been a number of books on portal technology over the years, most of them are from authors who lack a sense of perspective about portal technology and, in particular, the issues of product selection and implementation. However, Tony Byrne at CMS Watch has published what for me is the definitive report on the benefits and challenges of portal technology; the Enterprise Portals Report (www.cmswatch.com/portal/report) is authored by Danish consultant Janus Boye. In the classic CMS Watch format, it provides all that is needed to assist in the selection and implementation of a portal product. The choices are quite limited, but the differences in approach between the products are quite significant and need to be fully understood before selection—not after implementation.

My sense is that we are entering a phase of sensible portal development. For the first time, the emphasis is on understanding what a user might want from a portal, rather than an IT-driven approach that seeks to provide notional access to multiple databases and fails to deliver the kind of accessibly integrated information users need.