The perfect portal implementation: Eight steps to heaven Part VI

The final workshop in this series completes the application-integration stage and finishes with a look at portal personalisation for users and departments.

By Mike Ferguson

In last month’s workshop, we looked at the integration of content management and collaboration tools with the portal. To finish off step seven, I would like to look at one of the most difficult challenges in the portal implementation journey: integrating applications and business processes.

The problem with applications is that their user interfaces vary widely and can be either:

Web-based user interfaces – for example, Active-Server Pages, Java Server Pages or portlet-based user interfaces;
‘Thick client’ user interfaces – whereby the application was never written for the web. This kind of application may be installed on desktop PCs or, alternatively, deployed on a Microsoft (MS) Windows server and accessed via a terminal server, such as Citrix MetaFrame or MS Windows Terminal Server. In some cases, the same application may be deployed both ways within an enterprise. For example, some users may install it on their PC, while others access it via a terminal server;
‘Green screen’ legacy applications – for example, IBM 3270-based mainframe application, which still treats the PC as if it is a dumb terminal. Once again, this kind of application has not been written for the web.

Most of my clients have a mix of applications including all of these types of user interface and so have to deal with integrating all of them into their portals. Therefore, it is not a case of integrating just one type or another. In addition, this complexity is compounded by the fact that some of these applications are custom built (often referred to as ‘legacy’) and some are packaged applications.

This means that the job of ‘upgrading’ application user interfaces to portlet-based interfaces, which seamlessly integrate with the portal’s common look and feel, is not necessarily within your control. The responsibility for upgrading a packaged-application user interface rests with the vendor of that product. Unfortunately, the speed at which this kind of upgrade is completed varies widely across vendors.

For the most popular packaged applications, the chances are that an upgrade to a portlet-based user interface will already be complete. There will already be pre-built portlets available, which can be easily and quickly integrated with the portal. In these cases, a new release of the packaged application will usually provide you with what you need. Much depends, however, on whether the packaged application vendor also sells an enterprise portal product. In this case, you may find that the packaged application vendor ships its portal with the upgraded version of the relevant application. In other words, the portal product is the user interface to the application. You may find this beneficial if you have not yet chosen a portal product and your company is heavily dominated by the use of an enterprise packaged-application suite, such as

SAP, for example. The latest releases of packaged applications such as SAP and Oracle E-Business Suite ship with SAP NetWeaver Enterprise Portal and Oracle 10g Fusion Portal, respectively.

On the other hand, if you have already bought an enterprise portal product from a different vendor to the supplier of your packaged applications, then you may find this kind of ‘bundling’ strategy to be an additional complexity that you could have done without. If a portal is shipped with a packaged application then you may be able to adopt a federated portal architecture to integrate it with your chosen portal product (see my previous article covering step three – EI, October 2005, Volume 2 Issue 4). For example, if you have chosen MS Office SharePoint Portal Server as your enterprise portal, you will find that SAP iViews (SAP’s name for portlets) will run as web parts inside the SharePoint portal. Integration of packaged-application user interfaces with portal products often depends on the adoption of industry standards, such as JSR 168 and web services for remote portlets (WSRP), by packaged application vendors. If a vendor has adhered to these standards then you should find it easier to snap the application into your portal product and be up and running relatively quickly.

It is also likely that third-party portal vendors may have written their own pre-built portlets for the most popular application functionality. Several vendors, including IBM, Vignette and BEA Systems have done this. What you need in these cases is more than just pre-built portlets to integrate a packaged application. Pre-built portlets are not likely to cover all of an application package’s functionality. Chances are that they will just cover the most popular functions. Therefore, you are looking for a portlet-development kit (PDK) that will enable you to build portlets for a package, without having to do any programming. Point and click portlet building using a kit for packaged applications was pioneered by a company called Epicentric (which was subsequently acquired by Vignette). Quick to follow was IBM – its PDK for Oracle Siebel is shown in Figure 3.

This kind of PDK delves right into the metadata of the packaged application and enables you to select portlet data-fields and labels. This kind of re-labelling feature allows organisations to present packaged-application data in a portlet using an enterprise-wide, shared business vocabulary. Therefore, you can hide the different data names imposed on you by the packaged-application vendors.

In addition to pre-built portlets and packaged application-specific PDKs, most portal vendors also provide access to a portlet catalogue or gallery, where partners and customers have posted portlets that they have built. However, do not assume that these portlets necessarily follow the industry portal standards mentioned previously. The onus is on you to make sure that this is the case. Vendors such as Oracle should be commended for offering a portlet-test site to check for adherence to such standards.

For ‘fat-client’ applications that are not built for the web, you are faced with a choice:

Integrating these applications into the portal using a terminal server, such as Citrix MetaFrame or MS Terminal Server, until such time as the user interfaces of these applications have been re-developed;
Replacing these applications with more modern ones that feature portlet-based user interfaces.

For many companies, at least in the short term, a terminal server is the best option. In fact, integrating applications into a portal may cause growth in the use of terminal servers for a year or two, until they are re-developed or replaced. It sounds strange that you would want to access a fat-client application via a terminal server embedded in a browser, but that is what is happening in many cases. An example screenshot of this is shown in figure 4. Here, you can see the familiar MS Office application icons visible via the browser. Note, however, that if I start one of these applications by double clicking the appropriate icon, I am forced to use the native user interface of that specific application, which is not portlet based. There is no seamless integration with the common look and feel of the portal user interface once this application has been started. Therefore, while this strategy works and is acceptable to many, it is not necessarily a long-term option.

In addition to the above techniques, application developers can also create portlet-based user interfaces for applications using web services and application-development tools. Proxy (dummy) portlets can be created to access remote web services via the WSRP protocol. In addition, many popular tools (for example, BEA WebLogic Workshop, IBM Rational Application Developer and Oracle JDeveloper) have all been upgraded so that developers can use new wizards and functionality to build portlets for custom-built applications (see figure 5, page 23).

Process integration with portals
Part of the wider business-integration problem in which portals play a part, is the issue of business-process management (BPM). This is one of the fastest-growing areas in information technology, mainly because process integration carries such enormous business benefits in streamlining business operations and reducing operational cost. The whole idea here is that we can use process-modelling software to design processes separately from applications. These processes typically consist of multiple tasks spanning multiple underlying systems and departments. Process tasks include automated and human tasks. Once a process has been modelled, it needs to be mapped to underlying systems and to people to specify how each task in the process will be performed. This mapping is normally done by professional developers using integrated development-environment tools. Mapping on to underlying systems specifies which application services to invoke to perform each process task. Once this is done, industry standard business-process execution language (BPEL) is generated. This is simply XML. The BPEL is then fed into a process server, which parses it and starts managing the execution of the process, sending messages over an enterprise-service bus to the appropriate service or person next in line to perform a task (see figure 6).

Note that the software used for modelling processes and managing process execution is not portal software – it is BPM software. Therefore, in order to integrate business processes with the portal, we need to ensure that the BPM and portal software work together.

This often works best when both infrastructure products are supplied by the same vendor. Processes can be integrated with a portal by:

Introducing a task-list portlet (for example, MyTasks) for each user that performs a process task. A task-list portlet is likely to be available from the BPM or portal vendor;
Aligning the portal’s page design to specific process tasks, so that each task has its own associated portal page;
Alert the user when a task needs to be performed.

When a process is executing and a human task needs to be performed, the process must alert a user and then wait until they have performed the task. This will then appear in the user’s task-list portlet, which operates like a ‘task inbox’. When the user selects the task to perform – sometimes referred to as ‘task claiming’ – then the appropriate portal page appears with the required portlets. Once the task has been performed, the portal page associated with that task disappears and the user can go back to what they were doing before receiving the prompt (see figure 7). Several of the portal products that are currently available support this capability.

Step eight: personalisation, training and deployment
Portal personalisation is the final step in our roadmap. When the portal is deployed, it is important that individual users have access to the content most relevant to their job function. Personalisation is the process of filtering and targeting content and services to match the portal’s community and user requirements, while adhering to the organisation’s security policies. Effectively the user pulls relevant content to the screen.

For example, if we were designing a marketing portal, we would create a set of portal pages including the appropriate portlets required by individuals within the marketing department (see figure 8).

Once this is done, we simply assign this set of portal pages and portlets – the information profile – to a user group and then attach users to that group. In this way, when the user logs on they are automatically presented with role-specific portal pages. Note that a user group here could consist of only one user if we wanted it to, thereby giving us precise control on what each individual user has access to.

This completes my series of articles on the eight steps to deploying an enterprise portal. I hope you have enjoyed the series as much as I have. I would be most grateful for any comments and feedback that you may have.

Mike Ferguson is managing director at Intelligent Business Strategies. As an analyst and consultant he specialises in enterprise business intelligence, business integration, and portals. He can be contacted on +44 1625 520700 or by e-mail at mferguson@intelligentbusiness.biz