The Velvet Revolution

Portals have become valuable corporate tools - now what?

Portals | Last month, I wrote about the forthcoming Longhorn version of Windows and Microsoft's plans to eliminate the distinction between client and server by making Web services protocols part of every Windows application. It's a fabulous idea - when and if the whole world runs Longhorn, which will arrive in 2005 if Redmond is lucky.

Meanwhile, a countertrend is shuffling toward a similar goal from the opposite direction: boosting the number, integration and functionality of thin, browser-based clients. Increasingly, the framework for all those thin clients is the business-to-employee (B2E) enterprise portal. Employee-facing portals began with knowledge management, but during the past few years, Java portal servers have provided an organizing principle for Web app integration and development. The dream is a single-sign-on B2E portal tailored to each user, where everything from self-service HR to core business apps sits under a single Web interface.

Recession-Proof

During the spending slump, when enterprises killed other tech initiatives, many portal projects kept rolling, mainly because the benefits were so clear. I'm not talking about vague, top-down plans to give every employee a MyCompany page with a Reuters feed and the CEO's latest quotes. The consultants and customers I've talked to say the most successful implementations have been from the bottom up - to serve specific departments that need to automate a related set of functions.

Sounds like the usual app dev agenda, right? But when you throw a portal server at the problem, you can pull together applications that already exist, from Web-based conference room scheduling to a subset of SAP R3. The portal server's profiling and identity features can then handle security, authorization and self-service customization.

Most portal projects begin as integration projects. But increasingly, portal servers bring a lot to the party by themselves. In a process known as "integration at the glass", developers and even savvy end users can link portlets and create composite applications. IBM has been cultivating a community of third-party portlet providers for its WebSphere Portal. And BEA's WebLogic Workshop has done the best job so far of helping developers whip up Web services applications that provide a portal-based user interface.

Portal Portents

Customer lock-in is one effect of the proprietary development environments that run atop these stacks of portal, integration and application servers. But two new standards are working against lock-in: Web Services for Remote Portals (WSRP) and Java Specification Request (JSR) 168. WSRP lets any server publish a Web service for consumption by any portal, as long as both comply with the standard. And JSR 168 lets developers write a portlet once to run on any J2EE portal server. Both standards will eventually help IT spread portlets across the enterprise.

But those portals will never take on desktop functionality. Look at e-mail. Outlook is so much better than Web-based e-mail, for example, that you could never ask users to settle for an HTML interface.

Or could you? IBM has already released a browser-based version of Notes, targeting workers who don't sit at desks. You could use dynamic HTML, Flash or client-side Java to create enriched versions of browser-based applications. Then you don't need to wait for Microsoft to reinvent the wheel with Longhorn in order to have "desktop" applications that are fully integrated into the enterprise infrastructure. It's a thought - especially when you think about how much lower the licensing costs would be. And it's got to be Microsoft's worst nightmare.?