The re-invention of the portal

With sales outstripping those of many other key technologies in the past three years, the corporate portal seems to be making something of a comeback. Enterprise Information explores the new features that are tempting companies to give portals another chance. By Jessica Twentyman.

The corporate portal has taken something of a beating in recent years. A litany of failed or scaled-back portal implementations – attributable to poor alignment with business goals, over-ambitious scoping of projects, incompatibility with emerging portal standards and haphazard budget justification – have given plenty of businesses cause to consider whether the technology can truly provide a robust but flexible gateway to vital business information, documents and knowledge.

But according to Nate Root, an analyst at IT market research company Forrester Research, despite these concerns and tight IT budgets, portal sales have outstripped those of many other key technologies over the past three years. Not only that, but portal spending will stay strong: 38 per cent of North American, and 19 per cent of European companies will purchase or upgrade portal software in 2005.

There are several reasons for that, he says. First, early adopters are upgrading or replacing previous portal implementations – and with good reason, given recent advances in the technology. “Portal software isn’t what it used to be – seven years of hearty competition have resulted in products that are far faster, more scalable, more usable and more capable than the simple content aggregation engines that portals started from,” he says. The allure of new features, combined with lessons learned from semi-failed existing implementations, he adds, constitutes an irresistible opportunity for many firms to give portals a second or third shot.

Secondly, many companies are looking to the portal to tie together disparate business processes that span many back-end systems. That is a considerable leap forward for the portal. First-generation content portals, emerging in the late 1990s, provided a central interactive table of contents. As web technology matured, organisations then began to add interactivity to second-generation portals – meaning that, through the addition of web forms and integration links to back-end systems, the portal was transformed from a one-way information channel to a two-way interactive tool.

That, however, created a thorny problem for many organisations: information overload. In short, the sheer volume of valuable content and transactional interfaces presented through a single portal site became more than users could usefully navigate.

That has given rise to the third and latest generation of portal software, known as ‘process portals’. These aim to cure information overload and make portals more intuitive by enabling them to present individual components of business logic from numerous back-end systems in a logical order, thus creating guided business processes.

That kind of portal potentially has many uses. It can, for example, minimise the problem of “swivel-chair integration”, the need for employees to feverishly swap between multiple applications in order to complete a single business process.

Take, for example, a call centre employee taking a customer order. As well as making the entry on the order management system, they may also need to check the customer’s credit status against a finance system and check the product is in stock against an inventory system. That will often involve re-keying the same data into different systems, making numerous telephone calls and managing a slew of hastily written notes.

That can lead to lost sales and dissatisfied customers. According to a 2004 survey commissioned by software tools company, Corizon, 66 per cent of call-centre agents use three applications or more to serve customers on a typical call, while 27 per cent use five or more.

More worryingly still, 71 per cent claim time is wasted on or after a call because of switching between different applications and more than half (53 per cent) admit that errors tend to creep in when entering data into multiple systems.

A process portal, by contrast, replaces multiple interfaces to multiple systems with a single, user-friendly interface that accesses only the parts of a back-end system that the employee needs. “Yes, you need to combine diverse resources in order for employees to access the information and data that they need to complete a task – but you need to do so in such a way that creates targeted, cross-process applications that are specifically designed according to the user’s needs rather than system functionality,” says Paul Ciandrini, chief operating officer of portal software specialist Plumtree. A process portal, he argues, makes users’ lives easier “because it looks the way they think”.

Testing the process portal waters

Plumtree calls its process portal vision Integrated Activity Management, or IAM, and it relies heavily on the assumption of the portal as the interface to a service-oriented architecture (SOA). Upon the SOA are built composite applications – business processes made up of chunks, or ‘components’, of business logic held in different systems. These components can be reused again and again to build any number of composite applications, lowering development times and costs.

Because business logic components are ‘wrapped’ using web-services standards, they can exchange information over computer networks (including the internet) with other components wrapped in the same standards. That enables process portals – in theory at least – to access applications and information held not only on their own systems but also those of third parties, such as suppliers and retailers. A car manufacturer could, for example, build a process portal-based application that enables its plant-floor employees to view orders from dealerships, assess likely demand patterns and submit orders for necessary components, such as windscreen wipers, directly into suppliers’ systems.

That vision, however, is some way off, says Jim Murphy of IT market research company AMR Research. “SOA isn’t happening for most companies yet and won’t likely reach maturity for many years. Only then will we have composite applications based on web services, and only then does the notion of integrated activity management have a chance of sticking,” he says.

Nevertheless, plenty of companies are making early steps along the process portal path using integration tools that link portals to an integration server. So-called ‘portlets’ in the process portal connect only to the integration layer, which performs translation, transformation and BPM to connect disparate systems.

“Based on the information request, the BPM layer decides which application to tap and how to route specific data and present it to users via a portlet,” explains Marco Tilli, vice president of portals and hosted tools at Oracle. “The translation and transformation layer, which knows how the data is mapped to different back-end applications, taps the specific adapter for connectivity.”

It therefore follows that, until companies have a comprehensive SOA in place, they will need to identify only those parts of back-end applications that are vital to a specific business process and componentise them so that they can be accessed by the integration layer.

“That’s why many companies have only made small steps towards process portals so far,” says Martin Percival, principal technologist at BEA Systems. “It’s quite hard to decide how big or small to make those components when you’re staring at a million lines of code. Each component needs to be large enough so that a company gets a reasonable return from wrapping it in web services but small enough to guarantee reusability in a number of composite apps,” he says.

Market shake-out

The growing complexity of portal architectures is leading to a market shake-out among the vendors of portal software, says Nate Root of Forrester. “Increased IT spending, new audiences and project do-overs all sound like great news for portal vendors, but this rising tide won’t float all ships,” he warns.

In fact, according to Root, only the large infrastructure vendors (as opposed to smaller portal software specialists or ‘pure plays’) will benefit substantially from the resurgence in portal spending – great for IBM , Microsoft and BEA Systems, for example, but not for Plumtree Software or Broadvision.

“To deliver true productivity gains and cost savings, portals have historically needed to tap into the power of application servers and integration servers to assemble unique, new apps that helped people get things done faster, more accurately and more independently,” says Root. “Today, the addition of Web services, SOA and BPM software to the mix means that firms can develop extremely powerful process portals, but only if they can get this complex collection of technologies working together.”

For that reason, customers increasingly favour application platform ‘bundles’ from companies such as BEA, IBM, Microsoft and Oracle over specialist portal products. These bundles offer not only portal functions, but also application servers, integration and development tools and data management software – in short, everything needed to develop a process portal, integrate it with back-end systems and to run and manage it over its lifetime.

“What is changing is simply the underlying stack of technology that firms use to build their portal sites. Instead of having an explicit independent technology – the portal server – to support the sole task of building portal sites, firms that embrace application infrastructure bundles will use the same IT architecture to build all their custom apps, portals included,” says Root.

The first step in establishing a process portal, then, is to get that underlying integration infrastructure right. “If you’re building a new house, you want to get the plumbing and electricity right first time, so that you don’t end up rewiring just because you’ve bought a new toaster,” says Kevin Malone, a senior consultant at IBM Software.

The real challenges, however, will be cultural, not technological, says Root. “The hardest parts will be securing funding, building the project team, prioritising which business processes to target and convincing users to migrate to the new, portal-enabled business processes,” he says. And those – as anyone who has taken part in a portal implementation knows – are not just best practice, but prerequisites.

SIDEBAR: The portal of the future

Many companies are in the midst of both portal projects and determining a service-oriented architecture (SOA) strategy – but few, as yet, are co-ordinating the two. That may be a great mistake, says Nate Root of Forrester Research. “As portal server infrastructure is absorbed into application infrastructure bundles, portals allowed to remain islands of unique functionality and infrastructure will bring redundant development, administration and operations skills, which are unnecessary and costly,” he says. To avoid that situation, he advises companies to:

Fully embrace new portal standards

Portal standards JSR-168 and WSRP hit the portal market “with a thud”, according to Root. “Most buyers couldn’t find a good reason to care about the two specs,” he says. That is changing as companies realise that both standards encourage two very central tenets of SOA policy: Code standardisation and reuse. “It’s a virtuous cycle – using these standards for portal development will reinforce your overall SOA push, which will in turn further promote the use of standards,” he says.

Stop portal upgrade cycles

Standalone portal servers aren’t going to disappear overnight, according to Root, but they are certainly losing the long-term battle to application infrastructure bundles. “Ripping out your existing portal infrastructure immediately and replacing it with these new technologies would be expensive and yield little short-term gain. But expending resources to upgrade and enhance existing infrastructure would be worse – it’s pouring money down a hole that you’ll eventually walk away from,” he warns. When a portal infrastructure starts showing its age, he advises, companies should implement their next-generation platform alongside it and carefully migrate content apps from the old system to the new one without an all-in-one push.

Wire SOA architects directly into the portal governance team

Service-oriented architecture is as much about policy and practice as it is about software. “To truly realise the promise of the SOA hype, firms must sear into their culture best practices like code reviews, modular development and component reuse – so if the portal project team is disconnected from IT’s SOA planners, they’re likely to reinforce bad habits and unwittingly work against the success of the overall SOA initiative,” warns Root. “To avoid this conflict, insert a representative of the SOA planning team directly onto the portal governance and development squads.