Our Articles

A Monthly Article from our Speakers

Current Article of the month

Articles of 2017

Articles of 2016

Articles of 2015

Articles of 2014

Articles of 2013

Articles of 2012

Articles of 2011

Articles of 2010

Articles of 2009

Articles of 2008

Articles of 2007

Articles of 2006

Articles of 2005

Articles of 2004

Articles of 2003

Articles of 2002

Mike FergusonCorporate and E-Business Portals:
The Next Generation Workplace

by Mike Ferguson

June 2003

 

Over the last three years the uptake of portal technology has grown dramatically as companies look to integrate information, applications and collaborative tools into a single web based user interface to provide a more personalised workplace inside the browser.

During that time we have seen a surge in new start-up portal vendors, some of which have grown dramatically. More recently the market has started to consolidate rapidly as the software giants, who entered the marketplace late, begin to take larger market share. However there is still a lot of confusion in the marketplace with the vast majority of companies still to commit to portal implementation. This article is the first of a series that attempt to offer a deeper understanding of portal technology and a guide to portal implementation.

Introduction

Most large enterprises today are suffering from massive complexity in terms of their applications, databases, unstructured content and “spaghetti” infrastructure. Few would ever admit (at least in public) that while the journey through the client server era was necessary, it has left many companies with a massive legacy of fragmented systems, application and data duplication and heterogeneous platforms that are not well integrated. For most, while the systems deployed on these platforms serve their purpose, the complexity and total cost of ownership of computing is far too high. In addition, fractured business processes, data duplication, poor data quality, application functionality overlap and lack of integration are all contributing to business inflexibility. Most companies are desperate to sort this out in order to reduce costs, improve process efficiency, increase self-service and become more competitive. Is it any wonder therefore that in a tough economic climate like today, that business executives are leading the way in demanding enterprise business integration and enterprise wide consistency.

In addition, the power of the web is now understood and companies want to leverage it for everything. The requirement is to roll out access to common business processes, common applications and shared information and make it available to customers, suppliers, and partners as well as employees in order to cut costs, simplify operations, increase automation, extend self service and integrate the value chain. In addition common integration platforms are now sought as the focus switches to supporting integrated business processes and applications on a more simplified technology base.

Enterprise business integration is therefore happening at four different levels:

  • User interface integration
  • Business process integration
  • Application and transaction integration
  • Data integration

Enterprise portal technology serves the first of these levels – namely user interface integration, and is the focus of the rest of this article.

What is a Portal?

A portal provides internal and external users with an integrated, personalized and secure web-based interface to information, applications, and collaborative services. It is much more than just a web interface however. A portal is offers:

  • A single point of control for personalising, securing and integrating business content and services
  • Web device independent presentation services
  • Single sign-on
  • Personalisation services
  • Publishing and categorisation services
  • Search and navigation services
  • Notification and delivery services
  • Collaboration and workflow services
  • Taxonomy development
  • Content management and storage
  • Application integration services
  • Development kit for customising the portal user interface and for building back-end portlets

An example of a portal is shown in figure 1 below.

 

Figure 1

Here the content on the portal comes from a variety of information and application sources that are connected to the portal. The point here is that the user does not need to know what application to use to look at information. They simply see the information presented in a set of ‘portlets’ that occupy a part of the screen ‘real estate’. Portal vendors actually make use of the term portlets while others use different names for portles e.g. modules, pagelets, iviews, web parts, gadgets. Nevertheless, all these marketing names refer to vendor specific implementations of portal adapters that connect various systems to the portal.

One of the key differences between a portal and an intranet is that a portal offers each user a different personalised view. This personalised view is dependent on the users’ role and security profile. A procurement manager for example would have access to a personalised set of business process tasks, information, application functionality and collaboration tools to allow them to do their job.

Portal users can be both internal and external. Employees make use of a portal to access an appropriate subset of applicable corporate systems and also to gain access to external systems and services on the public internet, in partner organisations and on e-marketplaces. Equally external users such as customers, partners or suppliers can access a portal over the internet to make use of your corporate systems for e-business.

Portal users are typically formed into groups of users often called communities. A community is simply a set of users and a user can be a member of multiple communities. A community may be a set of employees located anywhere in the enterprise, in any location who work together to perform a particular business function e.g. procurement, sales or marketing. It could also be a set of external users such as partners or a mix of both internal and external users.

Why Build an Enterprise Portal?

A key question of course is why build an enterprise portal? I often hear statements like “I don’t need a portal my Intranet is sufficient” or “I can’t justify a portal given current IT budgets and the need to reduce costs”. There are a number of soft and hard return on investment benefits to portal technology. Soft ROI examples can be measured using polls and surveys and include

  • Improved employee productivity and collaboration
  • Improved employee satisfaction
  • Improved customer satisfaction
  • Improved security
  • Better and faster decision making

Hard ROI examples on the other hand can be measured using business metrics. Examples include

  • Headcount reduction, e.g., HR department based on employee self-service
  • Paper and media reduction, e.g., electronic forms or news
  • Business processing costs, e.g., expense handling, PO creation, procurement
  • Reduced travel and training costs, e.g., online education and meetings

However in my opinion, the best examples of return on investment (ROI) are when organizations consider the ROI of a portal application in conjunction with the ROI of underlying business applications. It is these two things together that make the difference. For example, a digital copying manufacturer deployed a customer sales and purchasing portal to enhance customer relationships and improve customer retention and reported an increase in revenue by 25% and an increase in contract renewals by 15%. An office furniture company deployed a supplier portal to manage external manufacturers accessing their back office and sales applications. The result was a 20% reduction in cycle time by synchronizing demand with supplier schedules.

Portal Business Content

As far as content is concerned, portals give us access to 3 kinds of content:

  • Information
  • Applications
  • Collaboration services

Information consists of unstructured information (e.g. text, digital media, syndicated feeds), semi-structured information (e.g. tagged data, XML data files etc.) and structured information in databases for example. Information may also come from content management systems external to the portal e.g. Documentum, Interwoven, Stellant etc. and from portal content stores that may be included as a component within some portal products (this is portal product independent).

Applications can be packaged applications, legacy applications and web applications. The challenge here is that some applications may be client/server based with a GUI interface, ‘green screen’ legacy applications, packaged applications with a business API e.g. SAP BAPI or web applications with an HTML user interface or a web services interface. In addition, some applications may be outside the firewall. This means that the portal must seamlessly integrate different user interfaces into a common look and feel to remove the problem of the user having to struggle with different interfaces. I will address how this is done in another article later in this series.

Collaborative services include email, instant messaging, net meetings, discussion groups, shared calendaring and workflow services for example.

Portal Components and Services

In order to understand what a portal does in more detail, it is a good idea to explore the services these products can offer. To help do this I have included an example of a generic portal architecture to show how these services come together. This architecture is shown in figure 2. The architecture shows a number of portal services. It should be noted that not all portal products offer all these services but clearly the more services and types of content they support, the richer the product in functionality and the more business value it provides.

 

At the top of the architecture is presentation services and security services. Presentation services manage the presentation of content on any web devices supported by the portal. These can be desktop computers, laptops, tablets, PDAs, phones etc. Both data and voice interfaces are now accommodated by enterprise portal products although voice portals are still in their infancy. The key point to note here is that portals offer device independence. This is because they automatically detect the device the user is using to access the portal and then render the content in the appropriate mark-up to fit the device. This is typically done in portal presentation services by taking in XML into the portal and using device specific XSL style-sheets to convert the XML into HTML, WML, VoiceXML or some other mark-up compatible with the web device being used. In addition, some portal vendors partner with specialist offline browsing vendors to allow users to take their portal on the road an use it in disconnected mode. Vendors such as iORA and Backweb provide offline browsing services for portal product like Microsoft Sharepoint and IBM Websphere Portal Server respectively.

Security services provide single sign-on authentication and authorisation including integration with cross-platform LDAP compliant directories such as Novell Directory Service, Microsoft Active Directory and Sun ONE Directory Server. Most portal products tend to inherit the user group and user profile information from these directory products to facilitate repid set-up of portals for large user bases. They do this by copying the user information into their own portal user directory from the LDAP directory. Changes to LDAP directories are then propagated into the portal to keep information synchronised. Some portal products maintain the LDAP directory directly through the portal security administration service e.g. Corechange CorePort 3G portal server. To provide additional flexibility portal security services may integrate with web single sign-on products such as Oblix, Netegrity, RSA and IBM Tivoli to provide a more robust service if you have to authenticate the user against multiple user stores on different heterogeneous platforms. In fact Plumtree even re-sell the Oblix NetPoint web single sign-on server re-badged as Plumtree Single Sign-On Server. The idea behind single sign-on is that once the user is logged on to the portal, they will be automatically signed on to all servers connected to the portal without the need to re-enter user identifiers and passwords.

Once the user is logged in, he or she then has available a number of user services. User services are what the user is allowed to do. Perhaps the most distinctive of these is personalisation which is the process of filtering business content to match a portal user’s requirements/role and an organization’s security policies. Personalisation can take place at several levels. Portal administrators can filter content and target content to one or more communities and individual users. Authorised content managers in different parts of the organisation can also filter and target content to communities and users in their business area. Finally the users themselves can filter content to match their requirements within the bounds of their security profile. The most common form of personalisation is role based personalisation were the appropriate content filtered to personalise the portal to fit the role of the user. So for example a marketing manager has access to the information, applications and collaborative tool to do the job of marketing.

Search and navigation services help the user find the information they are looking for. Portals have a search engine that typically makes use of a search index to rapidly find all related content across systems attached to the portal. Some search engines can use federated search to pass the user’s search criteria to other search engines and then assemble the results passed back from these engines into a final result before showing the user. Note that the portal security service will filter out restricted content before the search result can be shown. Navigation services allow the user to navigate a portal taxonomy which is a hierarchical set of ‘topic’ folders that contain related references to content that may reside in many different locations and systems inside and outside the enterprise. Users may not necessarily have access to all topics in the taxonomy. Navigation is when the user navigates their way through the taxonomy to ‘zoom in’ on the information they are looking for.

Publication services allow authorised users to publish new content into a taxonomy folder to share with other users. Publication can be controlled by workflow for approval of content before making it available to others. Equally notification and delivery services allow users to subscribe to content and be notified when new content appears or is changes. Notification might be by email or by instant messaging with a URL reference to the content.

Collaboration and workflow services allow users to make use of collaborative tools to share applications and information with others via the portal. Collaborative tools include shared calendaring, net meetings, threaded discussions, co-editing documents, instant messaging etc. Collaboration has been one of the fastest growing areas in portals. Microsoft, IBM, Plumtree, Sun, SAP, OpenText and many others support various tools.

Beyond user services, portal products provide other components and services that are normally only visible to administrators. At the heart of a portal is a portal directory. This is probably the most critical component of a portal product. The directory is a database of metadata that acts as a roadmap to the business content and services viewed through a portal. It contains documentation (metadata) organised by business topic about business content that can be accessed via the portal. The level of metadata supported in the directory varies from a list of portal content portlets to a full metadata directory. Metadata support is particularly important for information-focused portals. The portal directory facility is essential for supporting categorisation and personalisation.

Some portals also provide their own portal content store and a content store manager to administer it. Product examples include Microsoft SharePoint Portal Server, CA CleverPath Portal, and Plumtree Portal Server with the Plumtree Content Server. Portal content stores allow companies to have the portal also manage information as well as deliver it. Portals without such a facility can only deliver content. The portal categorisation service automatically discovers content by crawling multiple internal and external systems. It them automatically attempts to determin what that content is about and then to categorise it into the correct topics in the taxonomy that is held in the portal directory. Most portals have some kind of automatic categorisation service which is very useful if you have thousands or even millions of documents that need to be organised to make them easy to find. Specialist vendors like Autonomy and Verity also offer rich categorisation and search portal services that can be integrated with portals to add value if the ‘out-of-the-box’ categorisation service is not considered accurate enough. Of course these 3rd party products come at an additional cost.

To speed up deployment, vendors provide a number of pre-built portlets to popular packaged applications, syndicated content, email, content management systems etc.. The key question to remember with pre-built portlets is, can you do everything inside the portal as you could do outside it when using these. In addition, if pre-built portlets are not available for the system you need to connect to your portal, then most products provide a portal development kit (PDK) to customise the portal user interface and build your own portlets (e.g. to legacy applications). These development kits also allow you to add support for new devices to the portal’s presentation services. The PDK is extremely important to building portals and integrating products to create a federated portal solution.

Portal Product Types

The most confusing thing about portal technology is the marketplace where vendors all package their products differently. This makes it very difficult to compare candidate products. I divide the market up into four broad categories:

  • Stand-alone portal platforms e.g. Plumtree, CoreChange, Vignette, CA, Microsoft
  • BI portals – Cognos, SAS, Business Objects
  • Application portals e.g. SAP, PeopleSoft
  • Web Server portal platforms e.g. IBM, BEA, Oracle, Sun, Sybase, Tibco

Stand alone portal platforms either come with no other packaging or can include a portal content store. CA, Microsoft and Plumtree all have portal content stores. BI portals are offered by the BI vendors. These products typically come bundled with the vendor’s BI tool(s) and/or packaged analytical applications. Typically BI portals are restricted to providing access to BI reports and analyses produced by the vendor’s own BI tools. Therefore these products should be integrated into enterprise portal offerings so that intelligence can be shared. Application portals come with the packages application suite but do support integration with other packages. Many people mistakenly assume that SAP Enterprise Portal only works with SAP applications for example. This is not the case. Finally the web server portal platforms are when a portal platform such as IBM WebSphere Portal Server are integrated with a deeper technology stack such as a web application server and/or an application integration server. Also these products often come with integration services. Microsoft will move to this category with version 2 of Sharepoint which integrates with Microsoft Biztalk Server. The key market is the enterprise portal market where consolidation is occurring. Perhaps only a one or two stand-alone vendors will survive to compete with a few enterprise application suite vendors and the giant infrastructure vendors.

Implementation Steps

In order to get started in implementing portal projects you need a methodology. I have proposed eight steps that form a high level implementation methodology shown below. In future articles I will examine each of the steps to implementing portals in more detail.

  1. Develop the portal business case, select the portal development team, and create the portal project plan
  2. Understand the user functional and content requirements, and determine the business content flow
  3. Develop the portal framework, and select, install and integrate portal products
  4. Develop the portal taxonomy and categorization scheme
  5. Design, personalize, and customize the portal user interface
  6. Develop the security and single sign-on architecture
  7. Develop and implement the portal integration services (information, collaboration, applications)
  8. Prototype the portal, train users, and deploy the portal in a phased manner

Critical Success Factors

In summary there are a number of critical success factors to implementing an Enterprise Portal. These are as follows:

  • You need business user sponsorship
  • The portal needs to offer quick return on investment with near-term value
  • A sound taxonomy is critical to acting as a portal business content roadmap
  • An integrated and open portal technology framework is needed
  • Invest in an experienced portal development team (content/business knowledge, IT Web and infrastructure expertise, application integration knowledge, performance specialist, corporate librarian)
  • Have a pilot project and phased implementation
  • Market the portal to your users and train them to use it
  • Phase out old ways of accessing business content as you integrate this content into the portal so as to stop users from bypassing the portal to get to that content

In future articles I will discuss the implementation steps in more detail to show how to build and deploy portals to internal and external users.

Upcoming events by this speaker