Portals Pay Off
After all the hype from application server vendors in 2001, portals have finally landed firmly on solid, enterprise ground.
- By Andy Patrizio
If you've been blowing portals off as all hype and vapor, you're forgiven, since that's largely what they were in 2001. All of the major application server vendors (including Sun, IBM and BEA Systems) talked up portals but didn't have a particularly strong offering to back up the talk.
How things have changed. Programmers have gone to work and product has begun to reach the market. In many cases, portal technology is second generation, offering more functionality than the first-generation products that were little more than a presentation layer. More important, if you're trying to make that elusive business case to top management, portals are offering a measurable ROI in both time and money almost from implementation.
That news seems to have reached some IT organizations, which are taking portals seriously. A recent report from META Group says that 85 percent of global Fortune 2000 employees will be using portals to access information by 2004. AMR Research was a little more cautionary, pointing out that while 42 percent of companies it surveyed have budgeted to build an enterprise portal, only 11 percent view it as a top priority. [For more on portal vendors and products, see "Business Snapshot: Portals."Ed.]
Companies that have rolled out portals have made them available to, on average, 21 percent of their users, but are using just 27 percent of the portal's total capabilities. "So people are still in the ramp-up stages," says Jim Murphy, senior research analyst with AMR, in Boston, Mass.
Don't make the mistake of incorrectly defining your intranet or internal Web sites as a portal, as many companies have done. Murphy says he saw one firm with more than 2,000 internal Web servers. That's not a portal. Likewise, while there have been interfaces that allow Web browsers to access back-end systems, they still require multiple log-ons to access different systems.
Portals, in the truest sense of the word, function as a single point of access for all company systems: HR, internal documents, T&E, applications, knowledge bases, and so forth. They offer single sign-on to access different systems and services across an enterprise, eliminating a major nuisance for many corporate userskeeping track of multiple sign-ons and passwords.
A shift to portal technology can solve key problems: You can have single sign-on and you can rapidly develop more portals by reusing the directory server, applications and content. Because many intranets or early portals are built separate from each other, locating information can take a lot longer than with a cross-referenced portal that can search all knowledge bases from a single point of access.
"Studies have shown a knowledge worker can spend anywhere from 25 to 50 percent of their time looking for information. That's not an efficient use of time," says Tim Thatcher, program director for WebSphere Portal marketing in the IBM Software Group. "And the decisions they make are only as good as the information they have. So if they can find the information they need, they can be more effective in their decision making."
Axa Financial Inc. of New York, N.Y., shifted to a portal based on Sun Microsystems Inc.'s iPlanet Portal Server and saw gains in three areassingle sign-on, shared data and the ability to rapidly deploy additional portals as needed. The company's portal, Axa Online, was designed for its customers to access all of their financial planning and services over the Internet rather than through a call center or financial planner's office. Axa reports between 60 to 70 percent reuse of the parts in creating new portals.
"We reused 100 percent of the infrastructure and architecture, [and] almost all of the intellectual capital. We used all of the same tools, the same search tool and about one-third of the content," says David Wollin, managing director of emerging technology at Axa Financial.
Like a lot of IT shops that switched to a portal product, Axa is still in the early days of running a portal, so it's still computing the savings. However, 23 percent of all transactions at Axa are now being done over the Internet, and that number is growing. "We can deliver an online transaction for 75 cents, and a call center is significantly more expensive," says Wollin.
The company also has eliminated mailing out portfolio performance information to its clientsinstead, it points them to the Internet. By reducing its mass mailings to clients, the company estimates it can save $600,000 per year.
Axa was smart. It hadn't yet built siloed intranets or portals that needed to be unified. That's not always the case. Many companies have an internal portal for every department in the company. Often this happens when a department or division simply decides to develop its own portal, its own directory service, and a simple, first-generation portal product that's little more than content presentation.
The end result is a company with a half-dozen or more internal "portals," along with some external ones for customers. Usually, these portals are individual sitessilos, in other words that are completely separate from each other, repeatiting code and data.
"One of the key aspects of a portal is it's supposed to connect the right people to the right services," says John Fanelli, director of communications and portal products at Sun. "If you build them out with siloed connections [there's] no cross-references between the services," he explains.
If a company chooses to bring in a portal product, such as Sun's iPlanet Portal Server (re-named Sun ONE Portal Server in April), all of the siloed portals/intranets can be merged into a single portal that can cross-reference its different services. "We're seeing portal consolidation in the industry, where siloed portals that have been built using packaged products or from scratch are centralized with a common infrastructure," says Fanelli.
What Sun, BEA and IBM do to help clean up that mess and support what exists is import the existing portals and user directories and build a single- directory server to handle all sign-ons.
That was roughly the scenario facing Toshiba American Business Solutions, in Irvine, Calif., which sells office equipment. The company had a number of siloed portals and intranets/extranets for its internal use, as well as for its resellers and customers; each was separate.
Prior to the portal, the company used a number of separate portals/intranets, each with its own sign-on. If a dealer wanted to place orders, he or she needed the order entry application. Training or checking an order required a different applicationeach with its own sign-on.
So in November 2001, the company launched a portal built on BEA Systems' WebLogic Portal server. Built in four months, the portal consolidated user information and services. Payback was almost immediate: It generates $1 million in orders per day and will save the company $300,000 per year by eliminating the need to do mass mailings and print CDs to get materials to dealers.
"The portal gave a consolidated view of the applications and single sign-on so that a dealer can basically access one application to get access to all of its business information," says Manuel Ley, director of enterprise services for Infosys Corp. in Woodland Hills, Calif., the systems integrator that built the portal for Toshiba.
Another ROI for Toshiba was saving $300,000 in maintenance over a year. "For one thing, all the support calls have been dramatically reduced," says Ley. "The maintenance of users for each system has been reduced because all the user information is centralized." Because the portal is so new, Toshiba is still calculating its savings.
Another company with the same issue was Perficient Inc., an enterprise systems integrator in Austin, Texas. The company had its own internal cluster of intranets that needed to be unified due to overlap. [For more on Perficient, see "Choosing the Portal View."Ed.]
Perficient is an IBM shop and chose IBM's WebSphere Portal Server. That helped consolidate Perficient's employee intranet and a static information portal for employee reference. The end result is a portal site that allows consultants to access e-mail, look at travel expenses and policies, and search for information, all from a single sign-on and through a single interface. The immediate result has been a 30 percent savings on travel expenses and 15 percent savings on other business expenses.
Around the Bend: Portlets
A future technology for portals will be "portlets," or windows into the portal. At online portals like Yahoo! and Netscape, there are several boxes/windows with various applications and information, such as news, stocks, weather and so on. Each of these windows is a mini-portal within the portal and are displayed via a content delivery mechanism.
These portlets are made either manually, using Java and XML, or via a portlet creation wizard that the portal-server vendor provides. Either way, XML is used to connect into back-end systems to retrieve information.
Sun is pushing forward with a Java portlet API and has 18 application-server vendors supporting it (for more information go to www.jcp.org/jsr/detail/168.jsp). Sun intends for the Java portlet API to become the standard way to create portlet interfaces in portals, and this API will be used across all J2EE application servers.
IBM is Sun's partner in developing the portlet API. "You couldn't have done portlet API a year-and-a-half ago because the acceptance of what a base portal was, was spread all over the map," says IBM's Thatcher. "What changed is the belief in what a portal needs to do and provide."
The portlet API handles the presentation-end of information. On the other end, which has to interface with the back-end systems, IBM, to no surprise, is taking the lead on the Web Services Remote Portlets (WSRP) API, which it proposed in January as an XML and Web-services standard. WSRP will allow portals to retrieve content from a variety of data sources. More information on WSRP can be found at http://xml.coverpages.org/ni2002-01-21-b.html.
Microsoft vs. J2EE
Like far too many technologies, portal servers seem to be dividing along lines of Microsoft versus non-Microsoft. In this case, the non-Microsoft platform is Java 2 Enterprise Edition (J2EE) version 1.3, which includes Java Connection Architecture (JCA), a series of adapters that connect into back-end server applications like SAP, Oracle and DB2. JCA handles the connection, transaction and security in the transaction between the client and server.
Microsoft does have a portal product, called Sharepoint Portal Server, which it released in March 2001. But Microsoft admits the product, still in its 1.0 release, is rather rudimentary and focuses mostly on presentation, not application access, and is meant for a department, not enterprise-scale use.
A future version of Sharepoint, which should be announced around the time this article goes to press, will have support for the .NET framework. Because it will ship before the .NET framework is finalized, it will also support the Visual Studio.NET tools suite, and feature integration with Microsoft's line of business applications.
Supporting .NET is the primary concern for Microsoft. "One of the most important parts of the whole .NET framework is making it easy for applications to talk to each other in a seamless fashion," says Trina Seinfeld, product manager for Sharepoint.
Seinfeld acknowledges that iPlanet and WebSphere have been on the market longer, but says each product's complexity works against itself and in Microsoft's favor. "[The products] require more development and resources to deploy," she says.
JetBlue Airlines is a 100 percent pure Microsoft shop and uses Sharepoint to provide access to all 2,800 employees. With that level of software adoption, it's no surprise that Jeff Cohen, vice president and chief information officer, firmly believes in Microsoft products and thinks Microsoft is easier to set up in a portal environment.
"I think that if you're using the Microsoft technology, you're ahead of the game because [the company] makes it a lot easier to do Web parts, and that's what a portal is all about," he says. Because JetBlue is a startup, its entire enterprise is new, allowing Cohen to build a pure Microsoft system, which is what he wanted. It parallels the airline's fleet, which are all Airbus A-320s.
"I only need to have one type of technician, one who knows Windows 2000, I only need one type of developer, one who knows Visual Studio," he says. "I don't like this having to have a server guy who knows Unix and a server guy who knows AS/400. It just doesn't work. It's a duplication of manpower, and if you've done it the way I have from the beginning, then you don't have to put yourself in a position to have dupe staff to do the same things."
The other important element of Microsoft products is integration. "IBM isn't responsible for your desktop applications," says Cohen. "BEA isn't responsible for your desktop apps. Sun doesn't make a desktop app [Actually, it doesStarOffice]. So if you want to use [an IBM, BEA or Sun] portal, you have to start developing the Web parts. With Microsoft, a lot of those pieces are there for you."
Despite the animosity between Microsoft and, oh, everyone else, the J2EE community wasn't too harsh in its assessment of .NET, beyond pointing out that it's Intel-only and most of it's vaporware. IT managers say roughly the same thing.
"We're already a Unix shop, which is why we went with iPlanet, but we didn't have confidence in an NT server farm to scale up to the numbers of customers we're serving," says Axa's Wollin.
"The whole focus for us is on J2EE," says Sweet. "We like the portability of the Java environment and the application server environment as opposed to a single-vendor environment. This allows us to scale up, and it's the same answer for our clients."
IT shops considering a portal need to think ahead. Far ahead, says AMR's Murphy. "The concept is here to stay, and people are thinking about this framework as a solid, strategic initiative that's going to last us for years," he says.
You'll help yourself and your enterprise if you plan long-termeven longer than usual. "Think about the ultimate portal that you're going to want rather than the immediate portal," Murphy advises. "There's a lot of difficult decision-making around governance, who owns the portal, what the initial rollout looks likethat's why it's long-term."
Vendors advise you start with a directory service, whether it's Active Directory, LDAP, or another product. Most major portals support existing directory servers and will import them to create a single directory service.
"A good directory server is critical to the service of these things," says Axa's Wollin. "If you want to deliver personalized views, you have to have a strong directory behind you, and LDAP does that."