Portals have moved on from glorified Web sites to fairly sophisticated tools that tie together Web services, line of business applications, online content and collaboration tools. This poses some planning challenges for IT managers, who now need to think a lot further ahead in their portal strategy than before. Once they were built on the fly, from bits and pieces. Now they need to be built on the fly, but from a solid foundation.
The original concept of a portal was a Web site specifically designed to give users faster, easier access to information. The Web, by its nature, is inclined to lead to "content sprawl", where loads of information would be gathered over time, but then would often simply languish on a server, with users not able to see the trees for the woods.
Sheer volumes of data and lack of structure made finding relevant information a hit-or-miss affair for users. By specifically designing Websites to meet a group of users' needs, content could be structured in a way that made sense, users' attention could be drawn to specific topics or news, and information could be tailored to be of more immediate use. And so the Web portal was born - basically a user-specific Web site, tailored to meet the needs of a group ... whether internal staff teams or a group of customers.
As time passed, many organisations ended up with several portals - perhaps an HR portal so that staff could check employment information, apply for benefits or interact with HR staff. Another portal could be aimed at the sales team, giving new product information, sales teams' status and customer order information.
"For many large organisations, there was a proliferation of portals. Before long, IT managers were faced with a new challenge - instead of being faced with a sprawl of information that couldn't be managed, they were faced with a sprawl of disjointed portals that couldn't be managed," explained Graham Dickinson, an expert in portal solutions at Safmarine Computer Services (SCS).
"Often each portal was based on a product from a different vertical solution vendor - one specialised in customer-centric solutions, one supplier relationship solutions, maybe one for internal staff requirements. Portals were becoming part of the information management problem. Still today we are seeing vendors punting their specific portal and this merely adds to the complexity of the situation instead of simplifying the situation."
This situation got worse as portals were required to provide more than content storage, presentation and search functionality. Before long, portals were integrating into business systems, so that not only were they a source of stored information, but they could also allow people to request information directly out of line-of-business systems, such as accounting, payroll or procurement.
The problem from the IT department's point of view was managing and maintaining the systems, ensuring that not only were they available, but that the business logic that they were based on was working correctly... a bug in a script or a piece of middleware could be giving people the wrong answers or answers presented in one portlet could be out of synch with answers presented in another portlet on the same user's screen.
Even more complex was the increasing desire to include collaboration functionality into a portal - not only to be able to query a busy system for some information ("How many orders do BIG Retail Stores have outstanding"), but also interact with people ("I can see Bob Smith is BIG Retail Stores' account manager, I want to quickly do an online chat with him to check when he's seeing them next").
This meant that portal technology must not only arrange and present information on the Web, but also integrate into real-time business systems - as well as interact with underlying IT infrastructure (directory services for authentication, messaging servers' collaboration functions).
"This has substantially changed the underlying design strategy that IT managers need to take when designing portals," says SCS's Dickinson. "Where once before it made most sense to select a best-of-breed specialist for each portal solution, the requirement to tie into underlying business systems has made this approach impractical."
The current 'best practice' is to use an underlying middleware architecture that can talk to all the real-time business systems (eg transaction processing, procurement, accounting, payroll) as well as the information storage systems (Web servers, databases, messaging and collaboration servers).
This ensures that if portal needs change, or new services need to be added, it requires only the addition of the top-level information presentation system, not a fundamental engineering challenge in application integration.
"Rather than a portal being a vertically integrated piece of technology that runs from the user requirement down through the information systems into the specific business system concerned, it now becomes a horizontal layer of middleware that takes all business systems, and exposes the information they contain in a way that can be interpreted by standards-based information and manipulation technologies," says Dickinson.
The benefits are obvious - when there is a need for a new type of portal, it is still possible to go to a best-of-breed solution provider that knows and understands how to present the information in the best way for the particular audience, rather than someone who knows how to extract data from an old host-based system and present it through a Web page. The portal developer is now an expert in communication, rather than a technology vendor.
"The portal is defined by the users' needs, and by how effective it can be made, rather than being a technology-driven solution, where the bulk of the engineering is drawn into just getting to the data," comments Dickinson.
The second clear advantage to basing portals on an underlying architecture is that if there is a strong underlying platform for portals to be built on, they are simpler to maintain - both in up-time and information integrity, and the ultimate method used to access information can be chosen independently of the portal technology, using any standards-based technologies. Want to use a Web browser? No problem. Want to use a PDA? No problem. Want to drop information down to a mobile phone? No problem.
The third advantage of having an underlying portal architecture is in customisation and security. The original advantage of a portal was that the user could customise it. They could choose which information was presented first, and filter what was more important. Having an underlying portal architecture allows this kind of personalisation to be automatically extended across all the portals that the user has access to (when signing in to a new portal for the first time, user profiles can be immediately applied to the new portal, such as location, display preferences, read/write authority), and also ensure that security policies can be implemented centrally.
There is a very real security danger in multiple vertical portals, in that certain users could be given access to information that they are not actually authorised to view or change - and several portals mean several places for mistakes to be made in managing user access.
Gartner gives a pyramid of portal generations. Generation Zero was the "Home Pages on Steroids", with simple hyperlink structure and a search engine.
Generation One had content management or aggregation, search and categorisation, personalisation, some application integration within a simple framework.
We're probably somewhere between Generation One, and Generation Two, which is based on a robust application framework, with collaboration tools, mobile and wireless support and a management framework. The portals are becoming an online workplace.
The Third Generation will extend this further, with context personalisation, process integration and abstraction layers. They will bring in federated search, portal-to-portal technology, advanced Web services and knowledge management. But they will need to be based on a solid architecture.
The market for portal solutions is massive. According to Gartner, just the licence revenues for portal products is expected to hit $1.8 billion by 2005 - and this excludes the significant services related-market emerging to assist organisations implement and integrate portal solutions, which may be as much as two to three times this figure.
"The secret to being able to take advantage of the promise of the Third Generation portal without breaking the IT budget is planning the architecture now, so that advanced services are a feature to be added to an existing platform, not a massive new project," concludes Dickinson.
Some tick-boxes to fill when choosing a portal technology
Framework capabilities: portal infrastructure must scale, be manageable and allow applications to be deployed easily. Look for a distributed architecture and support for open standards to ensure freedom of choice in the future.
Integration with existing assets: the portal environment should provide all the resources necessary, or incorporate existing resources (eg existing directory or messaging system).
Workplaces and collaboration: for strong collaboration, the portal environment must provide tools for membership management and collaborative computing, such as instant messaging, discussions, document libraries, group calendars, task management, shared bookmarks and more.
Extensibility: integrate with existing infrastructure, as well as future ones through support for open standards, such as Web services, Java and XML.
It is critical to be able to customise portal solutions by adding specific modules or products.
Portlets and enterprise application integration: if the portal user interface presents the face of the organisation to a user, portlets act as windows into the core of the organisation. They access, filter and format content and applications to provide a personalised view of content for individuals and communities. Portlets need to be able to provide connectivity to a wide variety of content or application sources.
Share
Editorial contacts