Web publishing is surely very different from collaboration, and both are altogether very different from ebusiness. Yet all of these are frequently labeled “portal projects.” Even though we recognize the major differences among these types of projects, many organizations unsuccessfully attempt to use just one single portal product for all of them. To make matters worse, albeit not surprisingly, most vendors and even many consultants have a hard time telling buyers when a portal product is an unlikely fit for a specific project. In my research I’ve identified seven very different portal scenarios, which I use to describe fundamentally different types of portal projects. While the scenarios may overlap slightly, they can lead to a deeper understanding of the marketplace in 2007. When interviewing organizations with successful projects across these scenarios, I noticed a few shared characteristics. It became clear that there is hard work involved in portal success, but also an imminent danger that the portal will become little more than just a pretty face. Interestingly, most of the typical, critical project challenges are virtually unrelated to technology and the choice of specific portal product.
In this article I’ll try to untangle what can be a confusing market. I’ll then move onto looking at portal functionality, differences in portal projects, and finally offer a few words of wisdom.
Speak the Same Language
Before you move too fast into all the details in your project, make sure that your entire team is speaking the same language. In this young industry, many terms are often used with a variety of definitions. A portlet may seem to be a universal concept, but there are indeed significant differences among portal products. Important terms such as “collaboration,” “workflow,” and “design” may have very different meanings among project members.
A practical approach to defining terms is to ask a key project player to create a brief glossary with definitions of key terms early on in the process. This must be a living document, where terms can be added or modified as the organization learns. The document could be kept as a part of the project office with other relevant documents (e.g., requirements, project plan, etc.). Consider using a wiki here.
Once a glossary is established, it is important to dedicate time to addressing adherence. Team members will invariably come and go and—as with old-fashioned printed glossaries—terms will slowly change meaning over time (particularly high-tech and emerging terms). In addition to regular updates, make it a standard exercise to review the glossary at given intervals (e.g., every 6 months).
Beyond basic terms, also consider the differences between the inside and outside of the portal. The inside consists of the administrative and editorial parts that are only visible by designated users, while the outside contains the parts that are typically visible by everyone. In general, managers tend to excessively focus on the outside—making sure that everything looks nice. The problem is that much of the valuable work is done on the inside. The inside is where your colleagues will spend their work days administrating users, assigning permissions, adding content, and placing portlets. Inside is also where the portal can act as glue connecting different IT applications and processes. Integration is usually quite complex and expensive, but it is required to move the portal past being just a pretty face. In fact, your portal may become a magnifying glass to existing organization problems if you don’t effectively tackle the challenges on its inside.
Inside the Box
Let’s look at what today’s solutions on the market have to offer.
In my recent work writing the Enterprise Portals Report, I divided portal functionality into these categories:
Utility applications. Enterprise portal solutions commonly include basic utility applications within a portal. These are simpler web applications that an enterprise might want to “plug in” to any web-based portal. Common and popular utility applications might include organizational charts, employee directories, polls, surveys, and calendars.
Content and document management. This includes services that support the full life cycle of content and document creation and provide mechanisms for authoring, approval, version control, and scheduled publishing. Many vendors aim to remove the need for a third-party web content management system.
Collaboration. This category covers a wide range of functionalities enabling portal members to communicate. This may be through chat and messaging or through Web 2.0-style collaboration using blogging and wikis.
Search and navigation. Content is meant to be read, so on the usage side of the equation, being able to find and retrieve targeted content is the essential task. As more content is added to repositories, the more valuable those repositories become. Unfortunately, retrieving useful information becomes more difficult as the volume of information grows unless effective search and navigation methods are employed.
Content and application integration. At their most basic level, enterprise portals provide a presentation interface for accessing and displaying the results of several applications, but they are usually displayed independently. This type of shallow integration is the easiest to implement but provides the least benefit. Frequently, enterprise portal applications require something deeper: integration of multiple systems below the presentation level. When information from multiple services must be combined to complete a task or display a result to a user, application integration must be undertaken.
Personalization. Tracking a user’s identity can leverage more than just security in enterprise portals—it also enables personalization. The goal is to provide rapid access to the essential content and services to enterprise portal users. Portals can be personalized by central administrators, or users themselves, or (frequently) both.
Business intelligence. Executives typically require high-level aggregate information about key performance indicators (KPIs), such as total revenues, number of outstanding claims, volume of product produced, and aggregate quality measures. Dashboards are often used in portals to display multiple KPIs. Users can then drill into the details behind each of those measures to examine ad hoc reports.
Business process management. The ability to define multi-step procedures that span multiple systems and users is a critical feature of enterprise portals and is an important distinguisher between enterprise and departmental implementations. Previously known as “workflow,” technology for managing these processes now typically goes under the “Business Process Management” (BPM) moniker.
Some services, such as search, are often included in the portal software itself. Others, such as reporting services, are typically independent applications made accessible through the portal. An enterprise will almost surely face decisions about when to use portal-provided services and when to opt for a third-party solution. The former are usually somewhat lightweight, but are included in the price and well-integrated into the portal. The latter tend to be substantially more robust, but they represent an additional license fee (usually from a third-party supplier) and greater integration work.
We’ve now discussed portal services. For the technical audience, there are also several key technical areas worth considering. These include architectural differences, development approaches, reporting, scaling, loading, security, and the actual presentation layer. I won’t go into great detail with the technicalities other than to say that this is also an area with major differences among the products. Let’s instead move onto looking at how portal functionality is used across very different portal projects.