There is really only one common, accepted definition of a portal, and that's the one that none of us will ever need to implement in our lifetime: the Google or Yahoo home page type of portal. On the other hand, I suppose you could argue that one sub-genre of portal implementation—the corporate intranet—is meant to be similar: a sort of home page for your employees.

In any case, that particular definition of a portal revolves around a simple idea: When users load their browsers, this is the page they see. It's a powerful concept; if 25 million people use your page as their home page, you've got some very prime advertising real estate. It's more complicated now; with the Firefox tab set concept, users may load a page without ever seeing it. But still, you get the idea: The measure of success for this particular model is page hits, and being someone's home page is a guaranteed way to drive that number up. And one way of becoming someone's home page is to provide them with all the features they need. This is not the only way; you can also do one particular thing extremely well. I'd bet there are a large number of people who have Google as their home page as opposed to Yahoo or MSN, and the Google home page is about as simple as you can get (and maybe that's the lesson to be learned: simple is good).

For the corporate intranet, the idea is a little different. You have something of a captive audience. Still, your goals are similar: Make sure you provide a page from which users can do everything they need. Users will be less likely to use the page (and more likely to complain) if it's not productive. And if upper management decrees that they shall use this page (which they are probably going to do; otherwise, why spend the money to build one?), you had better believe that the end users are going to expect it to help them with their jobs...and that they won't be shy about making noise if it doesn't.

So a lot of what you need to do is to determine what exactly this portal is going to do for your users. This will allow you to build a feature list, which will in turn help you start your decision-making process. In this article, I'll outline a number of those features and even give you a few examples of commercial applications that might help you get an idea of what's available. Note: These aren't recommendations for any given portal product, but instead are examples of features that you might want to consider when making your decision.

Anatomy of a Portal

A portal is more than just a home page. In it's most complete form, it's meant to be a desktop replacement, driven by the browser. In fact, if you were entirely successful in deploying a portal that supplied all of your users' needs, that could lead to significant savings in your IT costs. For example, you'd be able to replace most if not all of your users' PCs with very cheap network devices that could boot a browser off your corporate intranet and be done. This would also provide easy access to remote employees through laptops or, with a little forward thinking, via handheld devices (including cell phones).
But before you implement a portal, you need to know what your end users need. And the chicken before that particular egg is to know what is possible. So let's take a look at some of the things that today's portal technology does.

Functions of a Portal

The first and easiest portal function to get your hands around is probably content management. Even if you didn't know it by name, you're probably familiar with this technology through MSN, Yahoo, My Google, or any of the hundreds of other public, commercial portals out there. And although content management varies wildly from product to product, the primary components are fairly basic: Define content (Web pages), identify who can access content, allow users to customize which content they want to see, and provide the ability to search and index content. If your content is of any appreciable size, the last one is probably the one that will make or break you. Witness the fact that Google is a verb, while IBM's InfoCenter is an epithet.

Next is the concept of a portal as a user development tool, which has a lot of appeal to the power user sector. In this environment, the portal provides more or less direct access to the database, including tools to analyze data and generate graphics and reports that can be easily customized by the end user. Not surprisingly, the database vendors provide the best tools in this regard. Oracle's portal solution is heavily geared toward allowing easy integration of the database (including the use of Oracle features such as Query by Example to build queries). Application vendors do similar integration; SAP has a solution that relies on BPEL, the business process language that several vendors, including IBM and SAP, have been pushing as a standard language for defining business processes.

The third fundamental component of the portal is the idea of portal as collaboration tool. The term "collaboration" is quickly taking on a life of its own, but for now it's still safe to say that it includes things like mail, calendars and scheduling, voice and video conferencing, and collaborative documentation. While many of these have their own standalone solutions (such as Outlook for mail or Google's Writely online word processing), the trend seems to be toward combining these services into a single cohesive product...or maybe two products; WebSphere Portal and WebSphere Workplace are distinct products, and Oracle is announcing Oracle Workplace, which will be a separate entity from Oracle Portal. So it seems that the attempt to integrate all forms of computer-aided interaction is fragmenting right along the fault line between collaboration and content management (be it static content or dynamic, data-driven content).

Deciding What Is Needed

While it may seem a bit of a cop-out, this is one of those areas in which what you need is very dependent upon your business. I can address a couple of simple examples, though. Let's say you're a small business with only a few employees and no real remote users except for Jim the Sales Guy. Well, in that case you don't need much in the way of collaborative software. On the other hand, if you're a publicly held company that regularly gives quarterly results via news briefings, you're probably going to want some sort of Web conferencing. In fact, you need to look into hosting your own services and having a variable-capacity solution like the recently announced 3COM VOIP services for the System i. How will that weigh into your portal decisions?

Now, while I may not be able to guide you to a specific solution, I can perhaps give you some areas to think about while you're making your decision. One of the easiest ways to get started is to consider your existing infrastructure. If you are already heavily invested in either Lotus or Microsoft server products, the decision is fairly easy. A Lotus shop is going to be best served by continuing in that direction with the IBM product line, while the Microsoft shop is going to reap the most benefits from the high integration between the Sharepoint product and the rest of Microsoft Office. So, provided you're already going down one of those roads, you have a ready-made answer that will probably give you the best return on your investment.

For those without any particular vendor predisposition, it gets a little tougher. Now you need to get more technical. One question is whether your upper management is going to want graphical presentation of data and drilldown. If they do (and chances are they will), you need to start asking technical questions. For example, is your data relatively coherent and roughly normalized, and does it reside primarily in a single database? Or is it more of a distributed database (either by design or by accident)? If most of your data is centralized, you may be able to get away with a database-oriented portal. Of course, that would depend on your database, but as I've already mentioned, many of the database or application vendors provide portal tools. If, on the other hand, your data is scattered throughout multiple databases and even different servers, then you will have a more challenging prospect on your hands. The only way to provide coherent access to such data is either to provide an adapter that hides the access to the data behind a filter or to stage the data into a warehouse environment. Either of these methodologies effectively provides a consistent interface to inconsistent data and then allows you to select whatever graphical tools best suit your business requirements. So in this case, the technical question of how to access your data is more important than the question of which portal to use.

But even the simpler questions need consideration. Take a look at content management. Even the basic question of who gets to see what can become a fundamental deciding factor in your search for portal solutions. Some portals allow you to define roles and then administratively assign content to those roles. This can make sense for extranet sites or multi-company environments, where content access is determined by the user and a simple public/private designation isn't enough. Another issue is that of offline access; some portals have features that allow a "push" mechanism out to client PCs so that the user can access content even when not connected to the Internet. If you have issues of connectivity for employees in the field, this is a great way to provide access for them.

Not to Be Overlooked

A couple of relatively minor points can still add up to big issues, especially if you don't consider them up front and they become requirements later. If your infrastructure isn't set up to handle them from the start, shoehorning these particular features in is going to be a challenge.

Single Sign-On

The first is single sign-on, or SSO. The more you use your portal as a vehicle to integrate different applications, the more you're going to want to think about single SSO. In the past, I've been pretty vocal against relinquishing security to a box outside of the System i, but as the System i is going to evolve from a back-end provider of services to the integration backbone of the enterprise, SSO is going to evolve from a nice-to-have to a need-to-have to a deal-breaker. The good news is that SSO is available on the System i, but the exact implementation of your SSO provider is of less consequence to this article than the ability of your applications to work and play with SSO. The point is that however you provide SSO services, every application on your portal needs to be able to use that provider and your portal solution needs to be able to cache credentials for a session and present them to all applications. Otherwise, your users are going to find themselves logging on multiple times, possibly with different passwords, and that will significantly impact their user experience. I know this sounds a little "fluffy," but think about it: Your user wants to run a graph that compares data from two different locations, and you make him log on three times (once for the application itself, once for data from location one, and once for data from location two). My guess is that you're going to get disgruntled calls with that particular scenario.

Wireless Communication

The other is wireless communication. There are several different options. One is simply to use standard HTML and make sure your handheld devices work properly. The trick is to know what your target device resolution is going to be, but many handhelds are up to 480x480 now, and the smallest cell phones typically get 128x128 or 128x160 (larger phones get QVGA—320x240—or better). Since portals regularly break up standard Web pages into segments of this size (Google portlets such as weather and calendar are less than 200x200), whatever the resolution of your end device, I think it's reasonable for your portal software to support these devices. They just need a slightly different navigation mechanism (probably some sort of tabbing). Other options include using a different access mechanism, such as Wireless Access Protocol (WAP), which is a technology whose fate is somewhat uncertain. Since WAP's primary reason for existence was to counter the slow speed and low resolution of handheld devices, as these two issues lessen (we have 384 KB wireless now and ever-more-detailed screens), it's my belief that these protocols will become less of a factor.

I think it's likely that some of your users are going to expect access via these devices. In fact, I am willing to bet that portable device access via browser is going to be a standard requirement for software in the very near future.

Which Door?

Ah yes, the lady or the tiger. Really, the decision of which way to go with portal technology depends a lot on your crystal ball and your ability to predict your company's the future needs. While some trends are pretty easy to extrapolate (cell phone as mobile terminal replacement), others are not so clear. Will you need to give power users access to disparate data? Are you going to embrace SOA standards and start writing your applications as services, or are you going to handcraft interfaces to your primary business processes? Is Web video conferencing going to play a major role in your company's future? And as always, the make-vs.-buy question comes into play: Are you going to buy an existing portal solution, or are you going to write your own using something like JavaServer Pages (JSP) and AJAX?

The questions are varied, but this article should have given you some food for thought so you can start to answer the technical questions that will in turn allow you to make the appropriate business decisions.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. and has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books including E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Joe Pluta available now on the MC Press Bookstore.

		Developing Web 2.0 Applications with EGL for IBM i Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform. List Price $39.95 Now On Sale
		WDSC: Step by Step Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95 Now On Sale
		Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00 Now On Sale

Also Read

Practical Middleware: Architecting for the Future

Practical Middleware: Starting the Journey

IBM i 7.2: The Carrot Versus the Stick