Except for portal vendors themselves and a few companies boasting very successful deployments, there still aren't a whole lot of fervent portal evangelists. On a scale of "interesting but only to specific niches" (e.g., the Segway) to "part of everyday life" (the cell phone), portals seem currently to be hovering somewhere between blog and instant messaging. They have high technosex appeal, but the jury is out as to whether the investment will really increase productivity enough to justify the cost.
In this column, I'll present a stratospheric view of portal technology and what it means to a business. I'll address these topics:
- Business issues surrounding portals
- The benefits of a portal approach
- The broad categories of portal solutions
- The state of the portal market and how to choose a portal
The Business of Portals
Portals are basically aggregations of Web pages. A single browser window is broken up into smaller rectangular areas, each with its own independent content. Each rectangle is produced by an instance of a specialized Web content generator: In the J2EE world, this is called a portlet, while in the .NET world, there's a Web Part. And that's about as deep into the technical details as I plan to get in this article. In keeping with iTechnology Manager's mission, I'll instead focus on the business issues that center on your selection of portal products. Throughout the rest of this article, when I use the term "portlet," I mean either the actual J2EE portlet technology or the .NET equivalent unless I specifically state otherwise.
First, you have to decide whether portals actually make sense for your business. As I noted earlier, this is far from a sure thing. Portals are not the universal panacea; they don't fit every business. For example, like any user interface architecture, an improperly implemented portal might actually reduce productivity. We've all heard horror stories of how a bad GUI turned a perfectly functional green-screen system into an end user nightmare and eventually a good excuse to leave the iSeries altogether. The portal interface is no different.
Another risk is that portals can be abused, leading to a requirement for additional management. Portals can be set up to allow users to pick their own content; taking that to the extreme, you could have real-time stock tickers or even streaming video on end user desktops, taking up both your network bandwidth and your employee's attention. This sort of problem has been encountered by companies implementing instant messaging; one of the categories in your vendor search should be making sure that the product's administration capabilities meet your business requirements.
The Benefits of Portals
Risks aside, portals provide some key benefits. Not all features come straight out of the box for all portal solutions. Some of those benefits depend on the vendor, while others are optional features that may require more or less effort on your part to implement. The variety of options is nearly endless; luckily, most of you reading this will be in the market for a portal solution that will integrate your legacy applications, and that significantly narrows the market.
Let's start there. Legacy integration is one of the key benefits of a portal. In a very broad sense, integration means being able to use your legacy systems along with applications created using the newer generation of tools (such as the many Web-based database query tools) or with third-party or open-source portal applications. If you can Web-enable your legacy application, you can provide some level of integration with these newer applications. This integration can range from "integration on the glass," which is little more than cutting and pasting between the two applications, to truly integrated systems in which a single action can cause multiple sections of the browser to update themselves with the appropriate information. Note that the most primitive level of integration doesn't provide much more than having a browser open in one window and a 5250 emulator open in the other. It's the true event-level integration that really opens the possibilities of user productivity enhancements.
A second benefit comes from enabling users to "design" their own portals. At their most flexible, portal servers allow users to pick and choose which applications they want in their display as well as the locations. Typically, the portal software allows the portal administrator to limit these capabilities, from allowing access to only certain applications based on user type (usually called a "role") to completely locking down the screen so that users cannot even move or resize the panes. The more flexible type of environment might be reserved for power users or for business-to-consumer (B2C) portals, while the most restrictive rules might be applied to data entry roles or to minimal control environments like kiosks. Thus, the actual benefits as they apply to your company depend very much upon the business functions you will enable via the portal.
An additional advantage comes if you choose to implement the collaboration features that most portal vendors provide. The impact of such a decision is difficult to quantify; not only does it depend very much upon the portal vendor, but even more it depends upon your employees and the type of work they do. Collaboration can be as simple as a shared calendar and as complex as global Web conferencing. The initial investment in setup, hardware, and possibly even additional Internet bandwidth can be substantial, reducing the immediate return. In the long run, though, most companies tend to agree that some sort of online collaboration and project management system reduces costs over time.
An often-overlooked class of benefits comes from a standardized look and feel that can be manipulated by the end user. In many cases, portlets can be written to a specific design standard, typically using Cascading Style Sheets (CSS). Done correctly, this can allow you to place standard controls on the portal that allow users to easily change things like color schemes or font sizes. This is especially important in B2C environments, where the size of the actual monitor is not under your control, but it can also make it easier to support people with different interface needs.
Types of Portal Solutions
Portal solutions come in three basic flavors: application-specific, technology-specific, and technology-agnostic. The application-specific solutions come from large package vendors such as SAP or from smaller, task-oriented vendors such as Viador. The portals from the package vendors are naturally geared toward their package, while the task-specific tools are almost all "business intelligence" or "data mining" applications, often geared toward that latest of buzzwords, the "executive dashboard."
(Author's Note: I'm still not sure just how much value an executive dashboard has except as a sales tool. A business partner explained it to me this way: "While I can understand that such a thing might have some vague usefulness as perhaps an entry point into a drill-down, I just can't imagine a CEO sitting in his office saying to himself, 'As soon as the little arrow on the portal goes into the red zone, I'm selling!' " But as usual, I digress.)
The technology-specific portals are designed more as frameworks for you to use, but they're tied specifically to one technology. Examples are IBM's WebSphere Portal products, BEA's WebLogic, and Microsoft's SharePoint Server. The primary benefit of products from these technology-centric vendors comes from their extensibility. For example, Microsoft has multiple ways to integrate to other Microsoft and particularly .NET technologies. WebLogic is the foremost player in the J2EE product space, boasting a long history of J2EE solutions. Despite the company's adherence to standards, it is arguably the most insular of providers since it even includes its own JVM (JRockit). IBM's WebSphere Portal is also an integration behemoth. In fact, the options are so profuse as to make selection difficult. My recent article on the Lotus Notes/Domino platform makes it clear that Lotus is one possible direction for portal solutions in the WebSphere world. Another option seems to be the WebSphere Workplace product family, and it's unclear what the exact long-term relationship between the two platforms will be.
One problem with the vendor-specific application provider suites is the fact that you will tie yourself irrevocably to that vendor. With simpler products such as WebSphere Application Server or Microsoft IIS, it's relatively easy to combine packaged vendor software with your own custom code to form bridges to other technologies (for example, to access SQL Server from WebSphere or to call an iSeries RPG program from .NET). With the portal frameworks, at least the vendor-specific solutions, you're typically locked into their development tools, which tends to make it much easier to use that vendor's code than your own.
You can avoid vendor lock-in with a technology-specific portal by going the pure open source route, using technologies such as Apache, Tomcat, and Jetspeed. The only open source solutions I know of use the J2EE platform; I'm not aware of any non-Java open source portals. But there are vendors with complete open source solutions, such as Liferay, which are typically free to use and require a fee only for support. If your staff is technically motivated and you are averse to vendor licensing issues, this is probably the solution for you.
The last type of portal is the technology-agnostic portal. I use the term "agnostic" rather than "independent" because the portal itself is written using a single technology, typically a standard J2EE approach. But the framework is designed to easily integrate solutions from multiple vendors using a standards-based approach. The two major players in this niche are Plumtree and Vignette, and both boast a very quick time-to-market while at the same time providing a high degree of extensibility.
The State of the Market
As with any technology on the cusp, there is currently a frenzy of partnering and acquisition in the portal space. This particularly hits the smaller task-specific tools as they vie for market share. The major Chinese players, Hinge and Chinasoft, began partnering with Viador back in 2003 to create a sort of pan-Asian portal cartel, while TIBCO has jumped into a tight relationship with Siebel. More alarming from a diversity standpoint is the recent acquisition of Plumtree, one of the two technology-agnostic portal providers, by WebLogic, one of the most technology-centric vendors. Whether this is a real attempt by WebLogic to move into the .NET space or instead merely a way of removing a technology from play remains to be seen.
The upshot of all this is that there will likely be continued merging in the field, and the number of products will dwindle over the next year. Unless you decide now on a very large vendor such as IBM or Microsoft, you may find yourself holding a bag of software from a vendor that no longer exists. That caveat aside, let's go over some questions that might help you make up your mind in the portal decision-making process.
First, do you have an iSeries application suite such as SAP that has a portal solution? If so, it makes sense to review the vendor's portal product to see if it meets your price and feature/function requirements. This is probably the safest route to go from an integration and deployment standpoint.
Second, if you're not going to lock into an application vendor, are you willing to lock into a technology vendor? If so, then selecting among the big three (BEA, IBM, and Microsoft) may be your best bet. Smaller technical resources and shorter deployment time frames also weigh in favor of this option. How to choose among the three is more than I can cover here, but in general the decision will depend on your current infrastructure. For example, if you're a big Lotus shop, then the Domino/Notes direction is your frontrunner. Similarly, if you've got a heavy investment in Microsoft in the form of products such as Exchange Server and SQL Server and you're already embarking down the .NET path, then SharePoint Server is probably your going-in position. Finally, if you're a major open source shop, especially if you've got strong in-house UNIX/Linux expertise, then BEA is probably your first choice.
Absent those options, the question comes down to money and support. If you've got the money (both in hardware—WebSphere is a resource hog—and software), then WebSphere is an excellent technological solution, and it's backed by superb support from IBM. On the other hand, if you're willing to trade a lot of money for the risk and time of putting together your own systems, then the standard "make vs. buy" argument applies and you should consider an open source solution.
Note that I've steered away from the technology-agnostic solutions. This is not for any particular technical or architectural reason, nor for any business process-related issue. Instead, I'm a little leery of the idea of the hidden restrictions of such an environment. It seems to me that in order to have an environment in which diverse technologies interact seamlessly, the easy route to take is to enable only the subset of features that is common among them all. Also, the fact that one of the two leading vendors, Plumtree, was acquired makes me a little uncomfortable regarding the long-term fate of the other vendor, Vignette. Vignette does offer a free trial of its software, however, so I may give that a try in my CFT*.
* CFT stands for Copious Free Time, something I'm sure we all have tons of.
The State of the Technology
After you've made some basic decisions using the points I raised in the previous section, you'll still have to do some technical analysis, an analysis that's better suited for the iApplication Designer publication. However, from a very high level, the single biggest requirement is that your portal solution allows your legacy software to be integrated into the portal. And if you want something that actually adds significant productivity, the integration must be better than just "on the glass" integration using cut and paste. Instead, you will need the ability to write a simple query portlet and then click on a line in that portlet and feed the customer number from the line into your legacy application, automatically bringing up the sales history for that customer. This sort of integration must be bidirectional and ideally should not require any manual customization of the legacy applications; changes to the legacy system should be automatically handled by the integration software.
If you're interested, I'll see if I can do some comparisons for an upcoming iApplication Designer column. In my CFT, of course.