Taking a business-centric approach to portals


Enterprise portals (generally known as just ‘portals’) rose to prominence several years ago. Complementing or replacing earlier technologies, portals promise to deliver a more coherent information management platform, and a more seamless user experience for staff.

Now that the early hype has died down, it is not surprising to find that portals are not a ‘silver bullet’ solution to all the information delivery challenges within organisations.

Like all technologies, portals have their strengths and weaknesses. These need to be well understood if they are to be successfully implemented within businesses.

This article outlines the characteristics (good and bad) of enterprise portals, and proposes a business-centric approach to selecting and implementing portals.

Two definitions of portals

The word “portal” can mean many things. As recently highlighted by Janus Boye, the Wikipedia entry lists 13 different definitions for portal, not all of which relate to IT.

In practice, there are two main definitions that exist in the marketplace. The first is “portal as a concept”, which encapsulates the general principles of providing staff with a single point of access to information.

The second is “portal as a technology”, which is the IT solution being promoted by a range of vendors.

These are two very different things, and it is the confusion between these definitions that is causing organisations so much difficulty in the current marketplace.

Portals are very different as a concept, and as a technology

Portals as a concept

The general concept of portals focuses on aspects such as:

  • providing staff with a single point of access to business systems
  • aggregating corporate information into a single location
  • providing staff with a single user experience that crosses information systems and technologies
  • tailoring (customising or personalising) information to the needs of individual staff (or groups of staff)
  • reducing (or eliminating) the need for multiple logins

These are all unarguably important objectives, and any steps that can be taken to deliver solutions that embody these goals are worthwhile taking.

Note that on the whole, these goals relate to the user experience of staff, and are about making it easier for staff to access information and to complete tasks.

This concept has been around for a long time, and quite a few technologies have had a positive impact.

For example, web content management systems (CMS) have done much to improve both the delivery and management of corporate information.

Behind-the-scenes, technologies such as LDAP have made huge strides in reducing the number of logins required, by allowing multiple business systems to share a single definition of users and permissions.

These goals can also be (at least partially) met through the design of better interfaces, via the application of usability and information architecture techniques.

Staff portal

Portals as a technology

The first generation of portals were born on the web, a product of the initial internet boom. Created by major players such as Yahoo and Altavista, these promised to deliver a single site that would become the user’s home page for the entire web.

While a few of these portals still exist (and even prosper), the vast majority of these sites rapidly headed to extinction. To a large extent, the concept of the ‘portal’ on the web died and has not been resurrected.

In recent years, there has been a resurgence of the portal, but this time within the organisation. These ‘enterprise portals’ still offer a single home page for users, but this time for staff rather than general web

Enterprise portals as a technology have been almost entirely driven by the technology vendors, most notably from three major groups:

  • database vendors
  • enterprise resource planning (ERP) vendors
  • application server vendors

Very quickly the definition of the enterprise portal (as a technology) became well-defined, even across vendors.

All vendors promised that portals were the ‘next big technology’ that would solve all of the information management challenges confronting organisations.

Within certain market segments (such as major corporates and universities), the purchase and deployment of portals became widespread (if not necessarily successful).

Portals all offer the same basic interface design, as shown in the diagram above. This consists of:

  • a single ‘home page’ which aggregates all of the information and tools into the one location
  • individual elements within the page (known as ‘portlets’), each containing a specific piece of information or functionality
  • some controls allowing portlets to be minimised, resized, or moved
  • a configuration page, allowing users to ‘personalise’ what is displayed on the portal, and how

An increasing number of portals allow this design to be customised, potentially making the portal appear like a traditional intranet or website. Even for these systems, however, the default design is still that shown in the diagram.

Portals: strengths

Portals provide a range of benefits, which are the basis for the enthusiasm generated for the technology in recent years.

It is worth noting, however, that many of the strengths listed below are of direct benefit to IT teams. In many ways, portals are most attractive to the IT areas responsible for corporate infrastructure, while the weaknesses (listed in a later section) impact on site owners and end users.

Simplifies some integration issues

The primary purpose of portals is to provide a single point of access to existing business information systems and sources.

To this end, portal software comes out-of-the-box with a range of integration tools for a range of technologies.

For example, most portals integrate cleanly with all major email systems (such as Exchange or Notes), as well as a diverse set of database platforms.

Note that portal products do not automatically integrate with all existing systems. In practice, there will be many legacy systems that will require custom-development in order to achieve clean integration.

Portals can help to deliver ‘single sign-on’

Provides single sign-on for common applications

Staff in many organisations are overwhelmed by the number of account names and passwords they have to remember, in order to access the variety of information systems they use on a daily basis.

This is particularly acute in large corporate and government settings, where there may be hundreds of commonly-used business applications, each with its own login details.

A primary goal of portals is therefore to deliver ‘single sign-on’ for staff, by providing an integration layer between the end user and the source system.

Portal software provides a range of tools to achieve this, and it is a benefit that can be delivered invisibly, even if typical portal user interface is not deployed.

Supports portlets, which offer much functionality

Portal products provide an ever-increasing number of pre-built portlets out-of-the-box. These provide a wide range of functionality, from integration with corporate email, to corporate calendaring, or the display of stock prices.

The ability to ‘bolt together’ these portals provides an extremely rapid way of delivering functionality with little (or no) development.

Of course, the range of portlets available varies between products, and this should be a key evaluation criteria during the selection process.

Portals come bundled with many out-of-the-box portlets

Provides personalisation/customisation

One of the major features of portals is support for personalisation or customisation. These are two related but different concepts, which can be defined as follows:

  • Personalisation allows individual users to tailor the portal for themselves (such as what information is displayed).
  • Customisation involves the filtering of information and tools to target identified user groups or roles (such as delivering information to specific geographic areas).

The objective of both approaches is to deliver a tailored environment to staff that contains only the information they need to do their job, presented in a way that is best suited to their needs.

This is a powerful concept, and one that is very attractive within today’s complex business environments.

Unfortunately, we know that users don’t personalise (see the item in the list of portal weaknesses), which somewhat eliminates this benefit.

The implementation of customisation also requires considerable amounts of user research, planning and maintenance. Few organisations are mature enough in their information management to effectively deliver this type of customisation.

Offers a development environment

Portals are generally deployed on top of a robust application server environment. This can offer a clean and well-support platform for further development (typically based on either J2EE or .NET).

This base platform, when combined with the framework provided by the portal and portlets themselves, can make it much easier to develop custom applications or integration.

This is one of the major reasons why IT departments consider portals when planning the modernisation of their IT platforms.

Provides integration standards

One of the biggest benefits of portal technology is the widespread adherence to a number of common standards (JSR 168 and related specifications).

These provide a strong basis for interoperability between vendors, and have been widely implemented.

Support for these standards is increasingly being found even outside of portal products themselves. For example, there are now a number of web content management systems that allow portlets to be embedded in published pages.

Standards such as JSR 168 have been widely adopted

Allows more dynamic delivery

Portals provide an inherently ‘dynamic’ environment that makes them well-suited to delivering more interactive capabilities.

The direct integration with back-office systems can also greatly help when delivering dynamic displays of data, or other online business systems.

Note that this benefit is not unique to portals, but is more related to deploying a modern web environment. Many content management systems also offer a strong platform for dynamic delivery of information and tools.

Portals: weaknesses

While portals provide a range of benefits as outlined above, they are not without weaknesses (like any technology).

These weaknesses include:

Inflexible in design and appearance

Almost all portals provide the same basic interface, as shown in the earlier diagram. While this can be customised to provide a different interface, this often requires development or behind-the-scenes tailoring of the product.

Besides being potentially costly or complex, this customisation can have a major impact on the ability to upgrade the product when new versions are released.

For this reason, many IT teams mandate that the portal must be deployed ‘out of the box’ as much as possible, minimising (or eliminating) any customisation.

If this is the case, the information management team may have little or no control over how the portal appears or operates. This inflexibility is potentially a very serious issue, when the portal is being deployed as a strategic enterprise-wide solution.

The default design of portals is not very usable for general staff

Default user interface is not usable

The standard portal design features a screen full of boxes (portlets), with a variety of controls and options. This is quite technical in nature, and not necessarily well suited for general users across an organisation.

A broader issue is whether this is really the interface that users need or want. There has been little (if any) research that has identified that the current design of portals is something that has been demanded by users.

A number of organisations have found there to be significant usability problems with portals, creating the need for reasonably wide-spread redesigning of the interface.

Users don’t personalise

It has been known for a long time that users don’t personalise. Anecdotal evidence suggests that in most organisations, only 5-10% of staff (or less) will actually modify the default appearance of the portal.

At a stroke, this eliminates one of the biggest selling points for portals. If users aren’t going to personalise, then the centralised team is left with the same design challenge that has confronted intranets for many years.

In many organisations, the portal owners have also disabled personalisation for the simple reason that this makes IT support much more difficult. If users have different portlets and layouts, this presents a considerable challenge for support staff trying to diagnose problems.

While these challenges can certainly be overcome, they have nonetheless been the reason for many IT teams turning off personalisation before the portal even launches.

The user experience of portals is often only one click deep

Integration is often only one click deep

Almost all the integration of the various applications and information sources is done on the main page of the portal.

This consistency of presentation, however, is often only one click deep. If the user chooses an option within one of the portlets, or clicks on a link, they are generally taken directly to the original application.

This makes for a user experience that is very shallow, with the differences between applications and platforms quickly reasserting themselves.

Development needed for some integration

While portal software can certainly make integration easier, considerable amounts of development effort may still remain.

This is typically the case for legacy applications which may not be in wide use. These will almost certainly demand custom-development for integration, made harder by the limits of these older technologies.

In the end, it may prove easy to integrate with more generic applications such as email (which provide limited benefits to staff), while integration with business-specific systems remains hard (even though these are more likely to deliver tangible benefits to the organisation).

Doesn’t manage content

Fundamentally, portals are not designed to actually contain or own information. Instead, they provide an entry point to existing information sources and systems.

This means that portals provide a poor replacement for the corporate intranet. For example, the authoring capabilities of most portal products is very rudimentary (at best) compared to most web content management systems.

Portals often also have a focus on managing documents rather than web pages, and therefore provide limited site management capabilities.

This reliance on other sources of information is one of the biggest achilles heels of portals, and one that portal vendors are keenly aware of. Many vendors are therefore progressively adding content authoring and management capabilities to their products, although this has some way to go before it is comparable to the much more mature web CMS offerings.

Content authoring and management is poor in portals

Relies on the quality of source information

One of the biggest challenges in any organisation is the diversity of information sources, and the lack of consistency between them. Dozens of definitions of a ‘customer’ plague many organisations, as does duplicated or incorrect information.

Portals are sometimes implemented as a short-cut to resolving these problems, with the promise that they will resolve all of these data management issues.

Unfortunately, portals do nothing more than provide access to existing information. If this is poor quality or inconsistent, portal solutions will only shine a bright light on these deficiencies.

At the end of the day, the hard work remains in resolving and consolidating these information sources into something that is coherent and well-integrated.

Can lead projects to be driven by technology

All too often, portals are chosen and implemented solely by the IT department. Worse yet, the portal software may not have actually been chosen, instead bundled (or offered for free) as part of another software purchase.

In these situations, the project may become very technology-driven, with the imperative to deploy the software even in the absence of clear business objectives or designs.

This can obviously be very damaging, not least because it may stifle or delay pre-existing information management tools already in place.

Taking a business-centric approach

The previous sections outlined a range of strengths and weaknesses of enterprise portals. With a solid understanding of these, it then becomes possible to plan a project that ensures the desired benefits are delivered.

The fundamental principle is to maintain a business-centric focus to the selection and implementation of the portal. Foremost to this is ensuring that there are clear objectives for the project, and that it isn’t driven solely by a technology agenda.

The sections below outline a range of tips and suggestions for planning and managing a portal project.

Don’t name your project a ‘portal’ project

Many organisations fall into the trap of naming their project a ‘portal’ project, such as the ‘staff portals’ or ‘student portals’ within universities.

This presupposes a technology solution, and tends to strongly bias the planning project. It also places ownership of the project within IT, and positions the project as one of application development and infrastructure deployment.

Few staff outside the central teams will know what a portal is, and the name does not paint a clear picture about overall objectives or benefits.

A more meaningful name should be found for the project, one that is directly related to the overall objectives and benefits.

The project should not be driven by the needs of IT

Don’t let IT drive the project

The portal project should not be primarily driven by the IT department. Portals, like intranets, require ongoing maintenance, support and enhancement.

This will only occur if the portal is ‘owned’ by a suitable business area with the right focus.

Having the project driven by IT will also tend to skew the project towards objectives that benefit the IT areas, rather than the organisation as a whole. For example, improving the underlying IT infrastructure, but without delivering any visible benefits for end users.

Getting the ownership of the portal project correct at the outset is crucial for the success of the whole initiative.

Identify business needs

The starting point for any information management project is to gain an in-depth understanding of staff (and business) needs and issues.

There are a range of techniques that can be used to gather this information, as outlined in the earlier article Conducting intranet needs analysis.

Only once this research has been conducted will be it be possible to design a solution that delivers clear and measurable business benefits.

The knowledge gathered is also critical when evaluating and selecting appropriate technology solutions.

Portals are not automatically the ‘best’ technology option

Carefully evaluate technology options

Regardless of the earlier hype, portals are not automatically a ‘better’ option than other technologies, and organisations are not required to implement portals simply to remain competitive.

Once business needs are known, the next step is to evaluate a range of technology options to identify which will provide the best solution.

This may involve exploring web content management systems (CMS), document management systems (DMS), portals, or even in-house custom-developed solutions.

Clear business requirements should be documented, and these used to evaluate the products under consideration. This ensures that all aspects are reviewed, including how information is presented, how the site is managed, and how the technology issues will be addressed.

Maximise flexibility

Efforts should be made to avoid being locked into a rigid design for the portal, or limitations on how the software can be integrated with other systems.

The portal project will only deliver benefits if it remains possible to design a solution that closely fits staff (and business) needs.

A number of practical steps can be taken to ensure that flexibility is maximised:

  • Specifying product (and interface) flexibility as a selection criteria when evaluating potential portal products.
  • Ensuring that the project scope and guidelines allow for customisation of the portal interface.
  • Allocating sufficient time during the project for the interface design and usability testing work.
  • Allocating time and resources post initial go-live for further refinement and enhancement.

Ensure time and resources are allocated to customisation

Allocate funds to development

Integration does not happen easily, and yet it is one of the main goals of most portal projects.

Funding should therefore be allocated to support sufficient customisation and development to deliver a solution that is of real value to staff.

Organisations that have run highly successful portal projects recognised that the key functionality is that which targets the unique challenges and needs within the organisation. By funding customisation and development of the portal, a site can be delivered that is both usable and useful.

Of course, this development must be project planned in detail, following standard practices of initially capturing requirements, developing prototypes, and then usability testing designs (see below).

Conduct usability testing

Usability testing should be conducted on the portal, to ensure that staff can easily complete common tasks.

This should be done as early as possible in the project, potentially even on paper prototypes or partially-working designs. This allows the usability testing to guide the ongoing development of the project, and avoids issues being identified too late in the project to be resolved.

The application of usability testing as part of the project will undoubtedly identify a range of issues that may impact on staff uptake and usage of the portal. These can then be corrected before the initial go-live of the software.

The portal will not immediately replace the need for an intranet

Don’t kill the intranet

Much work is required on the portal before it is in a position to replace a corporate intranet, particularly when the existing site is many thousands of pages in size.

More significantly, most portal software has very limited authoring and content management capabilities. This makes them a less-than-ideal tool to manage a substantial intranet.

For these reasons, the portal should be designed to work closely with the existing intranet, with no expectation that the intranet will be turned off when the portal goes live.

Only once the portal has proved itself and has been further expanded, should the future of the current corporate
intranet be re-evaluated.

Reduce (don’t increase) the number of systems

In all too many situations, newly-implemented portal solutions are simply added onto the existing list of applications.

In this situation, the portal can often be a direct competitor of the intranet or the document management system.

Users are then left with multiple ‘home pages’, all vying to be the ‘single point of entry’. This confusion impacts on staff, and is detrimental to the success of all systems.

An overall information management strategy must be developed that provides a clear path for all systems and platforms within the organisation.

Even where necessity demands some short-term overlap of systems, there should be a carefully planned set of activities to deliver greater consistency (and simplicity) as quickly as possible.

Consider individual business unit needs

The discussions up to this point have assumed that the portal project is being implemented enterprise-wide, with the goal of delivering a single ‘home page’ for all staff.

Another approach (and one that can be explored in parallel) is to deliver solutions targeted at individual business unit needs.

For example, some organisations have found great benefits in creating a sales force ‘dashboard’ providing a consolidated set of sales statistics and trends. This can then inform better decision-making by sales managers.

This is one example of smaller-scale initiatives that are designed to address the needs of one area of the organisation, or one staff role. These may prove to be more successful (and more sustainable) than enterprise-wide projects.

Into the future

In many ways, portals as a technology are struggling to survive. Quite a few vendors now give away their portal products, when a sufficiently large enterprise purchase is made of their main-line products.

This highlights that many vendors are finding it difficult to sell their portal products as stand-alone solutions that compete on their own merits, and are forced instead to bundle their technology offerings.

With the initial hype of any new technology fading, the limitations and issues with portals are becoming more widely recognised, as is the realisation that the marketplace has (so far) been driven by vendors rather than user demand.

It is far from clear that portals will be prominent even in the next year or two, and even now many organisations have lost interest in purchasing (or implementing) portals.

That being said, the underlying concept of portals remains sound, and highly desirable. Even if the technology of portals doesn’t survive in its current form, it is likely that the general principles will be incorporated behind-the-scenes into a range of platforms.

Portals are certainly not sustainable as an IT-driven strategy, and vendors must reshape their offerings to better meet user and business needs if they are to survive.


There is a clear need to deliver better information management solutions for users and for the business as a whole. The existing mess of overlapping (or even competing) information systems with most organisations must be addressed and resolved.

Enterprise portals may be able to assist with resolving these issues. If they are to succeed, however, organisations must be fully aware of both their strengths and weaknesses (like any technology).

Most importantly, these projects must be driven by clear staff and organisational needs, as well as a clear vision of the user experience that must be delivered.

Where portal projects are driven solely by IT considerations, they will fail. They do not offer a ‘silver bullet’, nor will they eliminate the need to better manage the underlying information.

By taking a business-focused (and user-centric) approach to portal projects, organisations can take valuable steps towards the goal of providing a single information environment for staff.

James Robertson
James Robertson is the Managing Director of Step Two, the global thought leaders on intranets, headquartered in Sydney, Australia. James is the author of the best-selling books Essential intranets, Designing intranets and What every intranet team should know. He has keynoted conferences around the globe. (Follow him on Twitter or find him on Google+)