How integration needs are driving portals growth

The delivery of personalized information made the browser a place where users could access updated information they wanted and avoid information they didn't. The idea was immediately co-opted by corporations who wanted to display pertinent data to employees through their desktop browsers, and intranets were born.

They quickly evolved into what's known today as enterprise information portals, a conglomeration of content and tools for navigation and collaboration. With portals, employees and even customers can access enterprise data from separate repositories and aggregate it into a single static window. The bugaboo of data access was temporarily solved, but the same old challenge of data integration remained. Workers could, for example, see spreadsheet data alongside financial data, but none of it was integrated--users still had to interpret and apply the data separately.

Clearly, the problem has stopped being one of access and started being one of analysis - that is, getting information to the user that contains intelligence and relevance. This means a renewed focus on the challenge of data integration, a thorn that's pricked IT and business constantly over the last few years. Companies are trying to bring intelligence to the enterprise information portal in three ways: through custom-written APIs called portlets; through traditional enterprise application integration (EAI) tools; and through the still-untested dynamic workflow capabilities of Web services. The problem of data analysis, unfortunately, has yet to solved, because as they tackle each of these three phases, companies are discovering both advantages and drawbacks. Simply put, a portlet is a component of the portal, a window from the browser to an application providing pertinent or personalized information. The information displayed by portlets ranges from applications (i.e., specific links to enterprise applications) and collaboration tools (i.e., mail and chat) to content (i.e., data feeds) and whatever data particular employees need to do their jobs.

Portlet development kits, which allow users to create, edit, and deploy portlets, are available from Plumtree, SAP Portals (formerly TopTier), and Viador (see the table "The Top Portlet Vendors"), as well as Oracle, IBM, and PeopleSoft. Traditionally, these kits also incorporate tools for personalization, categorization, search, content management, publication, and security. The companies that offer these capabilities singly are scrambling to jump on the portal bandwagon.

The advantage of portlets: you can integrate internal data sources as needed. Unfortunately, even though they're traditionally written in Java, Javascript, ActiveX, or XML, you can't take a portlet created with one application and move it to a different one. You're locked into that vendor's proprietary technology to access the data.

Currently, vendors are tackling interoperability solutions, but as might be expected at this early stage, they're solely point-to-point solutions. Microsoft is working with both Plumtree and SAP Portals to make sure its portal software works with the former's gadgets and the latter's iViews. IBM is supporting the Java Apache project, which is creating an open XML-based interface known as Jetspeed so that portlets can exchange information.The next phase in the evolution of tools to build portals involves the transition from integrating data feeds to integrating applications; that is, instead of piping ERP data to the portal, the user actually sees the ERP application in a window within the portal. Portal vendors have been increasing the number of applications they can aggregate, notes Meta Group analyst Craig Roth, "but as they extend this list of applications, they have been recreating EAI"--that is, duplicating effort by building tools that already exist in a similar form.

The enterprise application integration market is already mature, notes Roth, so it's no surprise that EAI vendors have been acquisition targets of portal vendors who want to try and avoid that duplication. Sybase (Neon), IBM (CrossWorlds), and Sun (Forte) all acquired EAI tools. EAI vendors like Tibco and WebMethods have also created tools for working with portals.

At the same time, these enterprise software vendors, along with BEA Systems, BroadVision, Computer Associates, and Oracle, have been capitalizing on their expertise in application servers - the delivery of Web-enabled applications to the desktop - to add portal capabilities.

The next logical step, according to Delphi Group analyst Charles Luce, is to enhance portals with EAI capabilities to break down the walls separating an application's data and an application's functionality, and integrate everything with business processes. "When a process [such as moving parts from inventory to manufacturing] occurs, it triggers a change in the way information is presented in the portal view," says Luce.

But integration is no easier now than it's been in the past. "Offering an integration framework does not fully address the needs of the knowledge worker," warns IDC analyst Brian McDonough, who cites the need for customized views, access to internal and third-party content, and ultimately, Web services.

Without an integration layer such as those offered by Tibco and WebMethods, companies are still forced into point-to-point integration. They face a real dilemma in portal deployment, notes AMR Research analyst Jim Murphy. "Companies say they have to get a quick ROI to continue to justify the expense of putting up a portal, but it's an expensive proposition because of ongoing integration."Currently, the challenge of application integration is aggravated by the grail of Web services, a concept that has great promise in terms of spawning mini-workflow processes. The value of Web services-touted by companies as big as Sun (with its Liberty project) and Microsoft (through the .Net initiative) and as small as Epicentric and Bowstreet-is that they dynamically create processes based on scenarios, profiles, and business rules.

The permutations are so complex that they could never be hard-coded, and so companies aren't even going to try. The ultimate corporate portal will transparently share application data, seamlessly tied with business processes, with each data transaction carried out on a personalized one-to-one basis for the portal user. This is Web services in a nutshell.

It's a logical transition as well. "We see the portal as the place to consume Web services," says AMR's Murphy. "[Plumtree's] gadgets are similar to Web services, but they don't imply a transactional process, which Web services do."

The problem is the same that plagues any business-to-business implementation-getting disparate systems to exchange information easily. "Portals using Web services demand a much greater level of sophistication," insists Luce. "They integrate not only a single organization's information systems' competence, but also that of multiple partners engaged in communications and commerce."

The transition to Web services won't come quickly. Most vendors plan to display the Web services interface the same way a portlet is displayed now, but naturally, each vendor is promoting their own standard that they want the industry to accept: Sun is promoting the Java Portlet Standard as part of its Liberty project, while Microsoft has Web Services - Interoperability (WS-I) as part of its .Net initiative (for more on the enterprise vendors' strategy, see the table "The Intersection of Application Servers, EAI, and Web Services.")

Expect the wrangling over standards to shake out over the next 9 to12 months. In the meantime, the important thing is to build a portal infrastructure now that can accommodate Web services as they mature.