Why Portals are not dead

Portals are not dead, but they were supposed to be. What happened? In early 2000, architects and technologists believed portals were to become the single UI interface for all web applications built by an enterprise. But five years later, most developers had switched from their focus on portals and realized that there were quicker means to develop web UI tasks. However, also by 2005, enterprises were evolving development from standard web applications to collaborative applications with rich UI interfaces.

It was at this time that new portal server technologies entered the market, and at least one of them was called the fastest growing product ever for a multibillion-dollar company. Each new technology was a portal, but somewhat different, which caused product teams to struggle with whether to call the products a portal or something else (e.g., Oracle WebCenter, Sun WebSpace Server). What happened to bring on the resurgence of portals? It may be that the portal as a defined technology followed the standard hype cycle but with a rather longer (or deeper) "trough of disillusionment" than normal. But more likely, portal technology evolved, and additionally, web technology itself evolved.

In 2000, Java technology was increasingly focusing on the Java Platform, Enterprise Edition (a.k.a., J2EE, Java EE) with a defined stack of technologies. Several vendors created application stacks, including an application server, identity management, and messaging layers, with a portal on top.

The portal allowed users to define a website consisting of web pages built with a background theme, navigation and portlets. Portlets could be iFrames, web applications or web content. One of the greatest benefits of the portal was that when tied to the identity management layer, developers could build portlets, add them to web pages and control their access using their existing identity management policy, called role-based content delivery (RBCD). The intent was to simplify the development of web applications across an enterprise, but the complexity of installing, integrating, and developing with the stack caused projects to become too complex. Besides stack complexity, another reason portals lost favor was because they did not include a method to create and maintain web content. Instead portals would be integrated with an existing Web Content Management System (WCMS) or Enterprise Content Management System (ECMS).

Whether or not it came from the same company, it still required you to integrate the two, and coordinate teams using both to create new content. For example, if you wanted a new web page in the portal, you would have to first create the content in the WCMS and then create a portlet to consume that content in the portal. Given that as much as 70 percent or more of every portal page included web content, two steps to create new content was one too many. Lastly, the development of portlets was limiting and complex.

JSR 168 was intended to be a simplified method for building modular applications (portlets) which could be assembled onto a single web page. However, it lacked many features (like interportlet communication). JSR 286 helped, but it still required more work to develop a portlet than just to build a web application from scratch. By 2005, new web 2.0 advancements became popular providing developers richer scripting, simplified integration, and new collaboration services. Developers began to use these other tools to build UIs instead and they relegated portals to corporate-wide applications. But while developers were moving to simpler development methods, they were missing out on the benefits originally designed in the application stack and portal.

The LAMP stack was not supported, so migrations and upgrades were difficult. The LAMP stack also didn’t include WCM. Additionally, a centralized identity policy could not be leveraged across all applications. Last, while new collaboration techniques were becoming available, they were not available as a service in one package, e.g., if you wanted ratings, blogs, wikis, or presence in your application you had to develop them each from scratch or integrate multiple external services. Also in 2005, new portals that provided these features and solved the problems with the old portals began to emerge and grow in popularity.

These new portals were lighter weight (some as small as a 200MB) and were easy to install, administrate and develop against. They often were an entire “application stack” bundle and installed in one step. Velocity and Freemarker were used to increase developer speed, allowing projects to be separated between web developers and business logic developers. These platforms also included a full WCMS, yet could still integrate with an ECMS. They included out-of-the-box collaboration services like wikis, blogs, address books, user-defined communities, and friend networks. And most importantly, they included the original benefits of a portal, a central platform to build web sites/pages using modular components (portlets, gadgets, web content) whose access is controlled by a centralized identity management policy.

Portals have returned to favor as a standard method to build web interfaces, web sites, and web applications. Today they are lightweight, include WCMS and allow developers to deliver social collaboration services faster than with old generation portals or even with standalone web methods pieced together.

Paul Hinz is the chief marketing officer for Liferay, Inc., the world’s leading open source enterprise portal. Before Liferay, Mr. Hinz led strategies for Java EE and the GlassFish Portfolio product lines and was Sun Microsystems' strategist for portals and collaboration. He has held multiple positions for Sun-Netscape, OSI, Hewlett-Packard and for the California Department of Transportation Research Laboratory.