eight steps to deploying an enterprise portal - part six

Eight Steps to Deploying an Enterprise Portal – Part Six

Intelligent Business Strategies

Springfield House, Water Lane, Wilmslow,

Cheshire, SK9 5BG

01625 520700

February, 2006

Mike Ferguson

© Intelligent Business Strategies Ltd 1

Part Six – Eight Steps to Deploying an Enterprise Portal By Mike Ferguson

Managing Director, Intelligent Business Strategies

In this last of the series article in EI magazine, we will look at the remainder of the eight

steps to deploying an enterprise portal outlined below.

1. Develop the portal business case, and plan for portal implementation

2. Understand user functionality and content requirements

3. Define a portal architecture, and select, install and integrate portal products

4. Develop the portal taxonomy and categorisation scheme

5. Design and customise the portal user interface

6. Develop the security and single sign-on architecture

7. Develop, implement and integrate information, collaboration and applications with

the portal

8. Personalise and prototype to create multiple role-based portals, train users, and

deploy portal technology in a phased manner

Having covered most of step 7 in my last article, this month we will focus on the remainder

of it as well as step 8 which looks at personalisation for role-based deployment.

Step 7 – Develop, implement and integrate information, collaboration tools and

applications with the portal

In last month’s article we looked at integration of content management and collaboration

tools with the portal in this step. To finish off step 7, I would like to look at one of the most

difficult challenges - integrating applications and business processes into a portal.

The problem with applications is that their user interfaces (UIs) vary widely. Applications

may have a:

Web based user interface e.g. ASP or JSP based, or portlet based

Client/Server ‘thick client’ graphical user interface i.e. the application was never

written for the web. This kind of application may be installed on desktop PCs or

alternatively deployed on a Windows server and accessed via a terminal server such

as Citrix MetaFrame or Windows Terminal Server. In some cases the same

application may be deployed both ways within an enterprise i.e. some users have it

installed on their PC while others access it via a terminal server.

‘Green screen’ legacy application e.g. IBM 3270 based mainframe application that

still treats the PC as if it is a dumb terminal. Once again this kind of application has

not been written for the web.


• Web enabled

• GUI-based client/server

• Legacy “green screen”

Application

Application

HTMLXML

datastream

datastream

Clientdesktop

ApplicationInterfaces

ESB ESB msgmsgbrokerbroker

terminal

Data

Data

Webbrowser

Application User Interfaces May Vary

Figure 1

Most of my clients have a mix of applications that represents all three of these kinds of UIs

and so have to deal with integrating all of them into a portal. Therefore it is not a case of

integrating only 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 UIs to portlet

based ones that seamlessly integrate with the portal common look and feel, is not necessarily

within your control. The responsibility for upgrading a packaged application UI rests with

the vendor of that product. Unfortunately, the speed at which this kind of upgrade is done,

varies widely across each and every vendor that supplies you with a packaged application.

So what can we do to solve the problem of application integration?


HTMLXML

client

desktop

terminal

Application

portlet

Application

Webtop

businessAPI

portlet

portlet

portlet

portlet

Considerationscommon look-and-feel

securityportlet standards

inter-portlet communicationmetadata

Portal

datastream

Data

Data

Portal Application Interfaces

Figure 2

For the most popular packaged applications, the chances are that an upgrade to a portlet-

based user interface will already be done i.e. there will already be pre-built portlets available

to easily and quickly integrate it with the portal. Obvious examples of popular packaged

applications include: Oracle E-Business Suite, Oracle Siebel, Oracle PeopleSoft and SAP. In

these cases it is often simply a new release of the packaged application that will provide

what you need. A lot 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 their enterprise portal product with the upgraded version of their application.

In other words, their portal product is the user interface to their application. You may find

this beneficial if you have not yet chosen and enterprise portal product and your company is

heavily dominated by the use of an enterprise packaged application suite such as SAP for

example. 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, if you have already bough an enterprise portal product from another vendor

that is not the supplier of your packaged application(s) then you may find this kind of

‘bundling’ strategy an additional complexity 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 (see my pervious article on Step 3) to integrate this with your chosen portal

product. For example, if you have chosen Microsoft 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 WSRP by packaged application vendors. If a vendor has adhered to these standards then

you should find it easier to snap the application into you portal product and be up and

running relatively quickly.

It is also likely that for the most popular application packages (SAP, Oracle ….) that 3rd

party portal vendors may have written their own pre-built portlets for the most popular

application functionality. Several vendors such as IBM, Vignette and BEA have done this.

What you are looking for in these cases is that the portal vendor gives you more than just

pre-built portlets to integrate a packaged application. As stated already, pre-built portlets are

not likely to cover all of an application package’s functionality. Chances are, they just cove

the most popular functions. Therefore you are looking for a portlet development kit (PDK)

that allows you to build portlets for a package without you having to do any programming.

Point and click portlet building using a PDK for packaged applications was pioneered by a

company call Epicentric which was later acquired by Vignette. Quick to follow was IBM

whose PDK for Oracle Siebel shown in Figure 3 below.

Portlet Development Kit Example - IBM WebSphere

Portal Server Portlet Builder for Oracle Siebel

Figure 3

This kind of PDK delves right into the matadata of the packaged application and allows you

to select data fields to be displayed in a portlet and even provide a new label for it. This kind

of re-labelling feature allows companies to present packaged application data in a portlet

using an enterprise wide shared business vocabulary so that 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 catalog or gallery where partners and even other portal

customers have posted portlets that they have built. However, do not assume that these

portlets necessarily follow standards such as JSR 168 and WSRP. 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

MataFrame or Microsoft Windows Terminal Server until such time as the user

interfaces of these applications have

Not integrating these applications into the portal until such time as their user

interfaces have been re-developed to be portlet based

Replacing these applications with more modern applications that have portlet-based

user interfaces

For many companies, at least in the short term, a terminal server is the option they take. In

fact integrating applications into a portal may cause a growth in use of terminal servers for a

year or two until they are redeveloped 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 where a Citrix

portlet is integrated into Microsoft SharePoint Portal Server.

Terminal Server Integration With A Portal

– Citrix Integration With Microsoft SharePoint Portal


Figure 4

Here you can see the familiar Microsoft 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 a long term option.

In addition to the above techniques, application developers can also develop portlet based

user interfaces for applications using web services and their application development tools.

Proxy (dummy) portlets can be created to access a remote web services via WSRP protocol.

In addition, many popular IDE tools (e.g. BEA WebLogic Workshop, Microsoft Visual

Studio .NET, IBM Rational Application Developer, Oracle JDeveloper etc., have all been

upgraded so that developers can use new wizards and functionality to build portlets for

custom built applications. Figure 5 shows an example of this from BEA WebLogic

Workshop.

Portlet Wizard

BEA WebLogic Workshop portlet creation

Portlet Development Using IDE Tools

- Product Example - BEA WebLogic Workshop

Figure 5


Process Integration with Portals

Part of the wider business integration problem (of which portals are a part) is the issue of

business process management. This is one of the fastest growing areas of IT 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 that span 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 IT developers

using IDE 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 just 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 who is next in-

line in the process to perform a task (see Figure 6).

The Process Server Parses The BPEL and Manages

Process Execution Over An Enterprise Service Bus

Application Integration

Platform

ShippingBillingOrder

Fulfilment

Order EntryEnterprise

Portal

ERP

System

Customer

ServiceBusiness

Process

Business

Process

Engine

External

application

firewall

Business process

modelling tool

GenerateBPEL

Enterprise Service Bus (Msg Broker)

B2B

Note that the software used for modelling processes and managing process execution is not

portal software – it is business process management (BPM) software. Therefore, in order

integrate business processes with portal, we need to business process management and portal

software to work together. This often works best when both these kinds of software

infrastructure products are supplied by the same vendor.

Processes can be integrated with a portal by:


Introducing a task list portlet (e.g. MyTasks) for each user who performs a process

task. A task list portlet is likely to be available from the BPM software or portal

vendor.

Aligning portal page design to specific process tasks so that each task has it’s

associated portal page

Alert the user when a task needs to be performed

When a process is executing and it comes to a point in the process when a human task needs

to be performed, the process must alert a user and then wait until they have performed the

task. The task will then appear in the users tasklist portlet which operates like a task in-box.

When the user selects the task to perform it (sometimes called task claiming) then the

appropriate portal page appears with the necessary portlets needed to perform the task. Once

the task has been performed, the portal page associated with that task disappears and the user

goes back to doing what they were doing before being prompted to perform a task. This is

shown in figure 7 below.

Portlet 3

Portlet 2

Portlet 1

Portlet 6

Portlet 5

Portlet 4

Portlet 7

…..

Travelrequest

TravelCo-ordinator

e.g. Travel

requestprocess

Create and assign portal pages to process tasks

tasktasktask

TO DOList

portlet

tasktasktask

TO DOList

portlet

ManagerAuthorization

tasktasktask

TO DOList

portlet

Creating ‘Process Driven’ Portals –

Apps and BI Is Delivered In The Context Of A Process

Figure 7

Several products support this capability today e.g. BEA AquaLogic Portal and AquaLogic

Process and IBM WebSphere Portal Server and WebSphere Process Server.

Step 8 - Personalise and prototype to create multiple role-based portals, train users,

and deploy portal technology in a phased manner

Portal personalisation is the final step in our roadmap. This is the deployment step and is

based on a very simple principal – “would everything that is irrelevant please sit down”.

Portal personalisation is the process of filtering and targeting content, and services to match

portal community and user requirements and an organization's security policies. Effectively


the user pulls relevant content to the screen. So for example if we were creating a marketing

portal we would create a set of portal pages with the appropriate portlets needed by someone

in marketing – See Figure 8.

Assigning Gadgetsto the profile

Personalisation Example - Creating A Marketing Portal

Using AquaLogic Interaction Portal

Figure 8

Once this is done we simply assign this set of portal pages and portlets (sometimes called an

information profile), to a user group and then attach users to that group. In this way, when

the user logs on to the portal, they would be presented with the relevant portal pages that

match their role. Note that a user group here could consist of one user only if we want it to,

thereby giving us precise control on what every user has access to. If a user moves role to

another user group then they may get access to a different set of portal pages because their

role has changed.

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 you have on the series.

-------------------------------------------------------------------------------------------------------

Mike Ferguson is Managing Director of Intelligent Business Strategies Limited, a

leading information technology analyst and consulting company. As an analyst and

consultant he specialises in enterprise business intelligence, enterprise business

integration, and enterprise portals. He can be contacted at +44 1625 520700 or e-mail

at [email protected]

eight steps to deploying an enterprise portal - part six

Documents