In the past, I've written about operational readiness and operational excellence as performance models for data center environments. I'm an ops guy; a gear-head; the imperious overlord of all things within my domain. I'm the person you typically hand your space, equipment, applications, and business models to, and say, "Make it all work, then manage it."

The investment in the human aspect of a project is typically what will make or break any major IT undertaking. This asset can never be overlooked or taken for granted. It's where the rubber hits the road - where the planning, organization, and execution take place. POE, not Edgar Allen Poe, but Plan-Organize-Execute, is a surefire formula for success on any project.

This month I'll shift to the next level. Assuming all previous topics have been considered and holes have been plugged, it's time to take a giant step forward and build the application infrastructure. Your firm has decided to purchase and install WebSphere Portal. Where do you start? Let's begin with portals.

What's in a Name?
The word "portal" is overused - everyone has a portal, everyone needs a portal...it's like a fashion statement. What is a portal, anyway? What is its basic premise? Loosely translated, IBM defines a portal as an entryway that provides an end user with a secure, single point of interaction with diverse information, business processes, and other people, all personalized to the end user's needs. Not too shabby, but IBM gets even more granular than this. IBM believes a portal should provide:

• A single point of access to all resources associated with the portal domain
• Personalized interaction with the portal services
• Federated access to hundreds of data types and repositories, aggregated and categorized
• Collaboration technologies that bring people together
• Integration with applications and workflow systems

The Next Step in Portal Definitions: Horizontal and Vertical
Beyond the basic portal concept, IBM and other industry analysts got the notion that further granularity was needed to properly categorize portals. From those thoughts came the ideas of horizontal and vertical portals.

Horizontal Portals
A horizontal portal represents the primary infrastructure upon which the portal itself is constructed. It contains several layers and subsystems, including:

• Presentation layer: Includes a Web user interface along with pervasive device support
• Personalization: The ability to serve dynamic response to the user based on personal profiles
• Collaborative toolsets: Allow things such as e-mail to be exchanged
• Portlets: Provide the ability to easily attach software modules and other services to the portal
• Applications and workflow: Provide the matrices that allow for the integration of legacy and new applications
• Search and navigation tools
• Publication and subscription toolsets: Provide the ability to author new content and publish it to subscribers
• Administration and security services
• Integration toolsets and methodologies

Vertical Portals
Vertical portals, on the other hand, cover a specific domain or business function. They may include functional areas within a company or industry and are typically built on top of a horizontal portal infrastructure. Think of the many pieces that make up an organization, such as sales, operations, IT, customer support, etc. Imagine each of these subsets as the vertical portals. As such, vertical portals are typically defined by the data, people, and processes they represent or serve.

Now that we understand what portals are and we've taken a peek at emerging standards of basic portal infrastructure and classifications, we can tackle what IBM has cooked up in the way of WebSphere.

WebSphere Portals
WebSphere Portal for Multiplat-forms (WebSphere Portal) provides enhanced access to Web-based information and applications and provides a single access point to these applications, including associated content and processes. It comes in three flavors:

• WebSphere Portal Enable: The basic offering, which enables clients to build scalable portals that simplify and speed a user's access to personalized information and applications.
• WebSphere Portal Extend: An enhanced offering that allows portal users to act on information and applications accessed through collaborative efforts with other portal users. It includes all the capabilities of the basic offering, as well as instant messaging, extended search capabilities, and some analytical capabilities.
• WebSphere Portal Experience: The most robust of the WebSphere Portal offerings, it provides the capability for developing, deploy- ing, and maintaining enterprise portals. This solution includes all the capabilities of the basic and enhanced offerings and adds some neat features to the mix, including application sharing, content management, and enhanced security features and functionality.

At this point, everyone on your team should be excited about implementing the project. Ensuring that the proper version of WebSphere Portal has been ordered is the first step. Now it's time to examine how the installation is done.

Supported Platforms
WebSphere Portal is supported on a variety of platforms and operating systems, basically the same AIX, Linux, Intel, Solaris, and Windows platforms that support WebSphere. Platforms and OS environments include the following, but keep in mind that the list represents the minimum requirements that must exist on the portal machine prior to installing Portal Server:

• RS 6000 hardware: AIX v4.3.3 or 5.1 (minimum)
• Intel platforms (IBM Compatibles): Linux RedHat
• Intel platforms (IBM Compatibles): Windows NT Server with fixpack 6a (minimum)
• Intel platforms (IBM Compatibles): Windows 2000 with service pack 2 (minimum)
• Sun platforms: Solaris 7 or 8 (minimum)

There you have it. Everything you need to know about what WebSphere Portal needs to run on - almost. Now come the subtle intricacies, including the critical applications that must be installed prior to the WebSphere Portal installation. These items were taken directly from IBM's documentation package. Let's look "under the hood" and see what powers WebSphere Portal from the standpoint of recommendations, considerations, and choices:

• IBM HTTP Server: IBM HTTP Server 1.3.19.1 is recommended. Portal Server supports all Web servers that the aforementioned level of WebSphere Application Server supports. If you plan to use a Web server other than Microsoft Internet Information Services (IIS), make sure IIS features are disabled before installation.
• WebSphere Personalization v4.01: The Setup Manager installs WebSphere Personalization in the same virtual application server where Portal Server is installed. To use an existing copy of Personal-ization, you must install it in the same virtual application server where Portal Server will be installed, prior to installing Portal Server. By default, Setup Manager installs Portal Server in a virtual application server named WebSphere Portal.
• Database and LDAP considerations: Depending on your configuration, your portal might require a relational database and LDAP directory. However, this software doesn't have to be installed on the same machine as Portal Server.
• DB2 Universal Database, v7.2 with Fixpack 5: During installation you can select to install the DB2 Server or DB2 Administration Client. After installation, a prompt asks you to install or not install the DB2 OLAP Starter Kit. Because WebSphere Portal doesn't include the OLAP Starter Kit, be sure to select "Do not install the OLAP Starter Kit," then continue along your merry way.

• Oracle v8.1.7: Although not shipped with WebSphere Portal, it can be used as your relational database. However, you must install Oracle prior to installing Portal Server. Also, if you've set up your database with a different name for the System Identifier (SID) and the Global Database Name, use the SID during the portal installation.
• IBM SecureWay Directory: SecureWay Directory v3.2.2 is recommended, but, and this is very important, in order to use SecureWay Directory with Portal Server, you must install SecureWay Directory, add a suffix, and then edit and import an LDIF file before you install the Portal Server component.

Above all, be careful. There are several versions and upgrades that aren't supported, including versions of DB2, HTTP Server, SecureWay Directory, WebSphere Application Server, WebSphere Personalization, and some versions of WebSphere Portal Server. A variety of Web browsers are supported, but not Netscape Comm-unicator 4.7X. Before proceeding, it's best to check with your IBM rep or certified installation partner for the entire list of supported and unsupported products and applications.

Now, on to the physical stuff - your actual environment and what will influence it.

Physical Planning
The number of machines WebSphere Portal will require, along with the physical makeup and locations of these machines, depends on client requirements. Therefore, in-depth needs analysis and preengineering exercises need to be completed prior to installation. Portal installation and deployment are interdependent upon how WebSphere Application Server is built. As you can imagine, careful planning and a thorough understanding of what you're doing and where you're going is paramount. Many resources and settings defined within WAS, such as Global Security settings, are shared across all applications, including the portal itself.

Make It a Double...
So what's it going to be? Will you install Portal on one machine or many? This is an important question to consider, since a single-machine install will need to include WebSphere Portal, WAS, and the Web server itself. This translates into a lot running on one box. Unless you're performing testing and development duties, this is probably the riskiest configuration for a production environment. Definitely not a design with any fault tolerance in mind.

Multimachine installations are far more robust and reliable for true production environments. Several example topologies for multimachine infrastructures follow:

• Multitiered topologies: Components such as the Web server, databases, etc., are installed across different machines.
• Vertical scaling topologies: Multiple portals, or portal processes, reside on a single machine.
• Horizontal scaling topologies: Multiple portals are created and deployed across more than one machine and rely on products such as Network Dispatcher, an HTTP redirector, to provide the modality of operation.
• HTTP server separation topologies: The HTTP server is located on a different machine than WAS and Portal.
• Demilitarized zone (DMZ) topologies: Commonplace in most Webfacing production sites, this topology utilizes firewalls to provide logical separation between machines within the infrastructure and the Internet. DMZs provide improved portal security and are the de facto standard where back-end processes and database resources are exposed.

Useful Tools
Some really useful tools are included in the product suite, one of which is the Setup Manager. Portal Server provides multiple software components that you can install. Each component has a variety of separate and distinct requirements; use the Setup Manager to install these components in a variety of configurations.

Depending on the installation you choose, the Setup Manager will prompt you for information during the installation. According to IBM's documentation, Setup Manager's installation options are broken into three offerings:

• Quick installation option: Uses configuration information stored in a response file to automatically install the Portal Server components. The response file is included in the software bundle. During installation, the installer enters the response file when prompted to do so by the Setup Manager. At that point, all components provided with the Portal Server will automatically install. No information input is required.
• Standard installation option: Uses configuration information stored in a response file to automatically install the Portal Server components. The response file is generated during installation and provides necessary information so you don't need to enter informationduring the installation. The response file preselects components that are installed on a single drive on a Windows environment or on default file systems on a Unix environment. The component interdependencies and subcomponent selections are managed for the user. With this installation some preconfiguration must be done. The installation defines what is in your response file and you can change these definitions. However, there is no validation for these changes during installation.

• Advanced installation option: You select the components you want to install. This is recommended for advanced administrators only because you provide the installation, configuration, and customization information using eachcomponent's installation user interface. Selected componentscan be installed on different drives; you're guided to makechoices that satisfy component interdependencies, and you make the subcomponent selections. Because you're prompted for a lot of information during the installation, it's recommended that you gather your answers before beginning the installation process.
• Other Portal Server installation prompts: During installation of the Portal Server you'll be prompted for a Standard or Developer install option. Select the Standard installation if you want to install the secu security features included with Portal Server. The Developer installation doesn't use Application Server or a third-party authentication proxy to verify proof of identity.

I'm just scratching the surface here. Proper installation of Web Sphere Portal for Multiplatforms is complex. It requires genuine planning and attention to detail. Once the product is in use, prepare for the needs that come along with sustaining operations. Keep clean and complete documentation. It may save you some day.

Conclusion
Installation of WebSphere Portal is not for the faint of heart or novice. It requires real planning and understanding of the product, modalities, applications, resources, and project management skills. Intense up-front engineering, along with robust documentation and the use of planning and installation worksheets, should also be anticipated.

Remember the three key letters mentioned early in this article, POE. Adopt this as the engine behind your project plans. Use these three simple key elements in your WebSphere Portal design and implementation. Develop and manage the critical path. Surround yourself with individuals possessing knowledge, drive, and dedication. That's the investment in the human aspects of any major project. Believe me, it'll be worth the effort. In the end, those envious of your accomplishments and the success of your project may indeed nickname you "Edgar Allen."