State of the Art for Enterprise Portals

By Janus Boye

Portal software technology has been around since 1998, and while portal implementations still often suffer from many shortcomings, the industry has also come a long way.

As our understanding of portal technology has evolved we've elaborated a set of common, sometimes decisive, portal scenarios that describe different business problems. These scenarios, however, range widely from the simple to the more complex.

While we favor scenario-based analysis, it still begs a question: can we generalize more broadly about features and attributes that are universally essential to successful portal projects? Have we learned enough to identify a current "state of the art" in portal functionality across all types of enterprise scenarios? I think so.

Beyond Scenarios

Many vendors call their products "enterprise portals," but our research finds that in reality, different tools do better and worse across these different scenarios -- and also vary substantially in complexity and cost. As such, scenarios are essential to help you focus on your concrete needs and project goals.

Nevertheless, portals are mature enough that we can start talking about baseline capabilities and practices. As part of my ongoing research with technology buyers for the new Portal Project Starter Kit, I've identified a set of features and attributes that any enterprise portal in 2007 should be able to boast. These range across the different services a portal offers, its technical aspects, as well as important vendor intangibles. Any portal project worth its salt will benefit.

State of the Art, Circa 2007

I'll divide state of the art into the same dimensions that we employ in our evaluation reports:

  • Services

  • Technology

  • Intangibles

Every portal vendor will say that everything below is possible with their platform. That's because portals are, if nothing else, web application development platforms. Given enough time, money, and risk aversion, you can get them to behave almost any way you want.

The key thing is what a product wants to do natively. Each vendor with a mature offering should be able to provide these capabilities out of the box, without you having to customize the product first.

Portal Services

Generate short, meaningful, and permanent URLs

This is the web after all, even if the portal is running on your intranet. Good URL practices translate into better search results and ranking, easier use in printed media and e-mails, as well as fewer problems with broken links when technology changes. And technology always changes.

Replace select portal functionality with third-party services

You may want to plug in a third-party workflow provider or replace the incumbent search engine. You should be able to do this easily, without worrying about complex integration.

Natively provide lightweight collaboration services

Self-evidently useful for departmental project teams, simple collaboration should be included in any portal product. Collaboration tools cover a wide range of functionality, from discussion groups, wikis, project areas, and even the concept of presence.

Easily support arbitrary content and data models

This means your content and data can be organized according to your own requirements, effectively enabling you to leverage existing investments in information architecture.

Navigation controlled by business users

This removes developer bottlenecks and empowers the business folks to change the navigation as they see fit. Also, the portal should allow designers to break out of the simple document-directory-based navigation paradigm.

Search all of different content types within the portal repository

Just like using the popular Google search engine, your search should not be confined to a subset of content, but rather work across all the content that resides in the portal.

Integrate with third-party Single Sign-On solutions

Security, identity management, and ease of log-on are always important, but most organizations have already made significant investments in this area, with many having dedicated resources doing nothing else than managing user directories (e.g., Active Directory or LDAP). The portal should be able to leverage this, as well as any existing security infrastructure in place, while enabling the user to avoid logging in twice.

Technology

Application Server freedom

At some point you may decide to change the application server or middleware running underneath your portal. This change should not affect your portal. Refrain from writing proprietary or vendor-specific code and you should easily be able to switch platforms. This is particularly germane in the Java world.

IDE of choice

Developers can be a talented, but high maintenance participant in your portal project. Letting them use their favorite tool for development surely makes them more productive.

Fast installation

First impressions matter and this should be a good one. A fast installation accomplished in a couple of hours can help the project move along to the real work of helping the business.

Control configuration management and deployment

Moving code and configuration changes among different environments such as staging and production should be possible in a simple, controlled manner. An important detail here is that you can deploy changes and also roll-them back again, without having to deploy everything from scratch. Modifications made in one environment should not have to be redone in another environment, but rather a simple deployment should suffice, ideally without restarting the portal or appserver.

Easily expose application data

Without writing code, business users should be able to expose application data throughout the portal. This could be customer information leveraged by the sales team or inventory data used in the logistics department. Application data is valuable and a portal should provide a simple magnifying glass into the organization. (Of course, true application integration is another matter.)

Better than linear scaling

When you grow your portal installation you should be able to benefit from economies of scale, so that each added server or cluster member should provide synergies towards a faster user experience.

Intangibles

Community rating of portlets

All vendors and open source communities brag about the depth of available, 3rd-party portlets. Reusing and sharing components is already a great idea, but without community ratings it can be prohibitively difficult to assess the quality and usefulness of available portlet code.

Widely available community support

Whether formalized in a user group or using an informal network, community support is a fast and effective way to get answers to your questions. Moreover, location still matters. Local consultants that can support and guide you can make a decisive contribution to your implementation.

A Word About Standards

Vendors may say, "don't worry about URLs and communities, since our wonderful standards support guarantees your investment."

Sure, unlike most other adjacent technologies (such as content management), the portal marketplace boasts many relevant technology standards. However, I encourage you to look beyond industry standards and leave it to the vendors to fight about who has the best implementation of JSR 168, BPEL, EJB, SOAP, and so forth. Don't get me wrong -- these standards matter and are helpful -- but you should look at the market from a broader business and technical perspective.

Final Advice

I intentionally do not crown vendors for each area covered. Different vendors perform well in different areas. So instead of discussing vendors here, I encourage you to start your analysis by identifying which scenarios you need to cover, and then moving on to researching enterprise portal vendors.

Use "state of the art" as your baseline and revisit it regularly during implementation. Your portal might get a stamp of approval from the toughest judges of all -- your colleagues.

Good luck with your projects!

Portal Software: Passing Fad or Real Value?

By Janus Boye

We have been here before. A few years ago vendors were touting personalization software. A major buzzword of the dot-com age, personalization would ostensibly solve a series of business problems and enable a new IT paradigm. Many personalization projects failed due to lack of adoption, long implementation times, problems with the technology, lack of clearly defined business goals, integration and testing difficulties, and cost overruns.

Today many companies are experiencing the exact same difficulties with a new breed of enterprise software called portal software. Nearly every major software vendor has created an enterprise portal solution, which in many ways has replaced their personalization hype. Certainly the CMS market is young and immature, but I would also caution buyers that the market for portal solutions is younger and much more immature.

In fact, I question the whole concept of portal software. Based on a series of issues I have found with portal applications while working on CMS projects during the last few years, I am not convinced this is an investment each and every company should consider.

Brief History

A few years ago the term "portal" emerged in connection with major websites such as AltaVista, Google, MSN and Yahoo!. A portal offered a single entry-point to content and functionality. In today’s world we have portal software, which is roughly an attempt to recreate Yahoo! within the enterprise.

But you should consider the question: What does a portal really mean for my enterprise? Your answer will vary depending on your company. More importantly ask yourself: What is the difference between a Web site and a Portal? In this article I would like to challenge the commonly-held notion that you need portal software to create a widely functional Web site.

Strengths of portal software

In my view there are primarily two benefits that portal software can bring:

  • Enabling business users to visually arrange design elements (via pluggable portlets).
    Portal vendors have taken steps towards the holy grail of enabling non technical business users to dynamically arrange and rearrange informational elements on a page. In practice, however, there is little evidence that portal users routinely modify default interfaces, and the overall design of content pages tends to resemble a stack of cards, which can be more or less usable depending on circumstances.

  • Enterprise Content Integration.
    Portal software can certainly be useful in an intranet where the company wants to present a unified interface to many back office systems and provide a single sign-on to those systems. In my view this is probably the best use for portal software today. The important thing to remember, though, is that you are unifying the interface, and perhaps creating a crude "dashboard," but not actually unifying the underlying logic and content models unless you invest in more costly and difficult application integration.

    Nevertheless, for true content integration across multiple repositories and applications, most experienced developers will also prefer to work with portal software rather than a CMS. Portal vendors -- either themselves or through close partners -- bring stronger integration facilities with superior options for rapid development and deployment.

    Fortunately, today technical standards are emerging that are relevant for integration. JSR-170, from the Java community process, specifies a standard API to access content repositories via Java 2, independently of implementation. JSR-168 is also relevant as it aims to enable interoperability between portlets and portals. Unfortunately few vendors support these, and for the Microsoft-based world there are still no good answers. Both were designed by committees so contains the basic minimum set of functions supported by each major vendor. In my experience, to make use of all the really useful portlet features that a portal vendor can offer, you will end up with a non-standard portlet.

Weaknesses with portal software

The problems with today’s portal solutions come in different flavors; business and technical.

Generally the market for these solution is immature. While portal vendors might have used various tricks to make the version number seem high, prepare yourself for challenges with unproven technology. New versions may or may not be backward compatible, service packs might require significant recoding, and do not expect the technical documentation to be entirely correct and updated. Of course, licensees say many of the same things about CMS products, but generally, portal tools are newer still.

Here is a brief overview of more weaknesses, starting with potential business shortcomings.

  • Costs.
    Most portal software is based on an application server (either MS-based or J2EE). As application server pricing has plummeted, vendors have tried to reclaim what was lost with increasingly higher licenses on portal software. Pricing for commercial portal software is typically done either per CPU or per user. Keep in mind when you sign a software contract, that implementation costs for a portal project are typically at least 4 – 5 times the initial license fee.

  • Usability.
    Out-of-the-box most business users will be intimidated by the user interface offered. If you speak to existing portal users they will most likely call their portal software a nice demo, but very cumbersome to work with. Arranging and placing portlets on major sites can be a very time consuming effort. As the site structure grows, the navigation load time can increase dramatically. This is a problem web content management systems experienced years ago, but most have solved today. If you add a new menu item or rearrange the navigation you might be forced to place the portlets from scratch again. Most portal interfaces were far from designed for business users but instead IT staff.

  • Consider the screen above (click for larger version), an out-of-the-box installation of Sun Portal with FatWire Content Server. Users require significant training before they are comfortable working in this super user environment.

    Among other problems, the occasional business user will find it very hard remembering what all the button and functions do. Of course, businesspeople may have the same difficulty using the applications (like this CMS) in a stand-alone environment, but in the latter case there is at least some context and the opportunity for in-line explanatory text that the squeezed portlet environment typically does not afford.

  • Bookmarks.
    With freedom to rearrange the design of the page, freely move portlets around, many portal users have realized that this comes at the expense of working bookmarks. This means that after brief time, visitors cannot expect their bookmarks to work, as the portlet they bookmarked might have been moved or might contain something new and entirely unexpected. Effectively the only page you can reliably bookmark is the frontpage. Any bookmarks below this level may not provide the expected result, unless you during the implementation spend time constructing the URL in a way so that bookmarks work. The problem with this implementation effort is that it runs counter to the provided flexibility to freely rearrange and reuse portlets. And unless you invest time on it, all pages will also have the same title, which makes it even harder to work with bookmarks.

Technical weaknesses

  • Performance.
    Working with portlets typically requires thousand lines of code to be executed quite often, while the end result may be just a few lines of HTML. This puts strain on servers and requires projects to invest considerable time in caching and performance tuning. . Many firms acquire expensive high-end hardware to run portal software. It is a fact that most content is not dynamic and as such there is no need to deliver it dynamically. Do consider mixed publishing (dynamic and static) as an option to reduce the hardware investments needed.

  • Obtuse URLs.
    This is related to the bookmarking problem above. It seems like most vendors do not care about human-readable URLs. Well, humans do. Portal software is notorious for incredibly long URLs. This has several drawbacks, not the least of which is search engine optimization on public sites. Consider this URL from the BEA WebLogic-driven TDC Kabel TV, or this IBM Websphere Portal Server URL from the Copenhagen Stock Exchange.

Issues of integrating portal software with your CMS

Portal vendors have discovered the importance of content management and tackled it with different approaches. Initially most portal software was entirely without any content management functionality. This is no longer the case, as vendors like Plumtree cried out for "no empty portals," and licensees came to see the need for a concurrent CMS investment.

To get a larger piece of the overall pie, portal vendors have developed strong alliances with major CMS vendors coupled with either 1) acquiring a CMS package (done by IBM, Plumtree, Broadvision, and Microsoft), or 2) building their own CMS (e.g., Oracle and to some extent BEA).

For the business user, working with CMS and portal software typically means working with 2 different interfaces. Yes, these can be integrated into one, but in my experience this can be quite difficult and therefore few licensees actually do this.

For a web editor this must lead to the question: Why is a CMS not enough? You can draw a line between the two, as many have done, by saying that the CMS is responsible for managing content and the portal for delivery. This leaves an important grey-zone for the business user: Where do we place navigation, site structure and preview? How do we ensure that the non-technical business user can control the navigation and preview content with the actual site layout?

A really nice CMS feature is the ability to edit text directly on the site -- either through in-context or pure in-line editing. When put together with a portal solution, this is extremely tough to implement, as you then will need a way to write changes from the portal to update the CMS. What this means for many users, is that a key CMS out-of-the-box feature can not be used. There are techniques that a CMS vendor can use such as “preview this page in the portal” or using a preview version of the portal in the same editorial environment as the CMS. With the use of portlets to delivering the content to the end-user, this still makes the content manager’s job difficult as she will never be able to preview all the combinations that an end-user might select and this means the content manager can never answer a basic question; “how is this going to look on the page?”

Reconsider the business requirement

In fact most site visitors do not require portal functionality. This is especially true for public Internet sites. I have been in many presentations where I have been asked about providing the end-user with a “My Yahoo” type experience. When I ask how many customers they surveyed to get this requirement the answer is usually “what survey?”

The last time I came across this was for a local government council office. Most visitors of local government sites don’t want to rearrange their own pages and portlets. They just want to know when the next garbage collection will be or what times the local swimming pool opens. If my local council proposed offering me a portal, I would tell them to spend the money on a decent search engine. Forget about the personalized portal experience – just show me the right content and show it to me quickly.

Most vendors now speak to the Intranet use case, or the holy grail of an "Enterprise Information Portal," or EIP. Consider, though, the top features repeatedly requested on corporate Intranets:

  • enterprisewide search

  • employee directory

  • common guides and handbooks

  • instructions and other HR information for new employees

  • links to commonly-used internal applications

Do you really need portal software to accomplish these? Maybe you should start by creating a small-p portal deploying a simple website on top of any existing Intranet sites, and invest in big-P portal software only after you have put in place successful processes for publishing and aggregating high-value, highly-sought information. You may find you don't need portal software at all.

In any case, don't use the crush of a software deployment as an excuse for getting organized about the information needs of your employees -- you'll probably just fail on all counts.

This is because building and maintaining any Web site or intranet requires work. Writing quality content requires even more ongoing work. Using portal software is not a silver bullet. It is complicated and will require major efforts to get up and running and to maintain. Presented with proper alternatives the business case would most likely benefit immensely from reconsidering the requirement for portal software.