The perfect portal implementation: Eight steps to heaven
Part II

Having developed your business case and examined user functionality and content requirements, you are now ready to move onto the third step of your portal-creation process. By Mike Ferguson.

In this month’s workshop, we will continue to work through the eight steps to deploying an enterprise portal, focussing particularly on step three.

Step three: Define a portal architecture and select, install and integrate portal products
Defining a portal architecture or framework is a good way to see the services that are needed in a portal and how they fit together. This also helps identify what to look for in portal products when you evaluate the solutions that are available in the marketplace.

The architecture shown in figure 1 features two ‘device-facing’ services: presentation and security services. Presentation services render content in portlets to fit the user’s web device – for example, PC, PDA or mobile phones. This means that device-independent applications and content can be developed and integrated with portals for access by authorised users, from any web device. The portal detects the device the user logs in with and renders the content accordingly, making use of the appropriate XSL style sheet for the device being used. Security services handle user authentication, authorisation and single sign-on. This means that the user only has to log on once to be connected to the authorised applications and content they need – without having to keep logging on to each back-end application, business intelligence (BI) or content-management system.

Below these device-facing services are the user services – essentially the tasks that the user can perform. These include:

Personalisation;
Search and navigation services;
Publishing content;
Collaboration;
Participating in processes;
Receiving notifications;
Having subscribed content delivered.

Portal products also have additional services that are typically managed by a portal administrator. These include the portal directory and search indexes, a content-categorisation service, a portal content store and content manager.

The portal directory is the brains of the portal server. It holds community taxonomies, lists of available portlets, user and user-community profiles and security information.

Search indexes speed up user content searches and are used by the search-engine service available to the user via the portal. Portal content stores are ‘entry point’ content-management systems that directly integrate with, and are managed via the portal. Administrators and authorised power users make use of content-management services to manage the content and documents in the content store. Note that the portal-content store may be ‘virtual’ – it could consist of several document libraries and web-content stores that are made to look like one system. Discovery and categorisation services discover content and organise it to populate portal taxonomies. A portal taxonomy is a hierarchical set of folders that holds metadata referencing information that is managed by the portal. The information referenced in the taxonomy can be stored anywhere inside or outside the enterprise, including in the portal-content store.

Pre-built portlets for popular packaged applications, content-management systems and syndicated content are also shipped with many portal products, to speed up deployment. Figure 1 shows a portal development kit for building your own portlets, customising the portlet-user interface and extending the portal to support new kinds of devices. Besides supporting all this functionality, portal products run on top of a web-application server. Typically, this will be from the same vendor as the portal software. For example, IBM WebSphere Portal Server and WebSphere Application Server or Oracle 10g AS Portal and Oracle 10g Application Server.

Portal-product selection is not just about forming a feature checklist for portal software. You also need to understand your business needs and existing IT set-up. This includes knowledge of:

User communities and locations;
Types of content and services needed by user communities and how it is currently accessed;
Tools and applications that are currently used in business processes and when accessing information. These will need to be integrated into the portal;
Your company’s strategic technology preferences, including choice of database-management system (needed to hold portal metadata), web-infrastructure technologies (for example, web-application server), content-authoring tools, application-development tools and security standards.

Once this set of requirements is understood, it is possible to form a portal-technology requirements checklist in preparation for portal selection.

Before selection takes place, a good question to ask is what is it you are looking for – an enterprise portal product or an enterprise-integration suite? Figure 2 shows this probing question more graphically. I ask my clients this question all the time and the answer is never just a portal. They almost always want an enterprise-integration suite so that they can integrate user interfaces, people, processes, applications and data. The point here is to distinguish between what a portal can do and what it can’t. Don’t assume the portal can do all that an enterprise-application suite can do. If you want business-process integration, look for portal products that are able to integrate with business-process-management (BPM) software.

In other words, you need both enterprise-portal and BPM software to make this happen. Most companies simply want to start down the enterprise-integration path by installing a portal product first, mainly because it is relatively inexpensive and quick to implement. However, it makes you think about the vendor.

Chances are that you will want to choose a portal from a provider with the entire stack of technology, rather than a stand-alone portal solution. Because, even if you start with simple portal implementation, you will probably want to go further by integrating people, processes, applications and data – which pushes you into buying additional integration software. So, look at the whole stack anyway because it is likely that you will go back to the same supplier in the future. This is mainly because you’ll expect pre-built integration out-of-the-box between the portal and every other element. Most portal products are bought to facilitate content management and collaboration. This is often the reason why portal products ship with options to buy an integrated content-management system and a set of collaboration tools from the same vendor. You have to bear in mind the bigger picture – the portal as the new personalised desktop with everything accessible through it. Therefore, the five levels of integration need to be considered. This is because, at some point in the future, these layers of software must come together. Most companies favour buying additional integration software from the same vendor that they bought the portal from, on the basis that all of the stack stands a greater chance of being integrated – rather than having to go best of breed and stitch it all together yourself. This kind of choice escalates the portal selection process into a ‘technology-stack’ selection process. This is the reason why enterprise integration suite vendors have been more successful in the market – because they are coming to market with much more than a portal product. The recent acquisition of Plumtree by BEA Systems represents the last of the ‘stand-alone’ vendors, which is now owned by an enterprise-suite vendor.

Bearing this in mind, the requirements from your content usage study and those defined on the checklist in this article need to be taken into account when selecting portal products. Integration into your existing IT infrastructure means understanding how portal software can integrate with your:

Browser and web devices;
Content-management systems;
Security products and requirements;
Terminal servers – (for example, Windows Terminal Server, Citrix);
Web-development environment (development tools, programming language, web-application server);
Server hardware and operating system;
DBMS;
EAI software (including private UDDI registries for web services);
BPM software (if any is in place);
Types of business content to be supported (applications, BI systems, content-management systems, collaboration tools).

A portlet-development kit will allow you to build your own portlets. Most portal products ship with pre-built portlets for access to popular packaged applications. However, these are only likely to provide you with a small subset of that application’s functionality. Therefore, most companies need the ability to add additional portlets. This means gaining access to a packaged application’s metadata to allow you to select what you want in a portlet. Vendors offering portlet-development kits for specific packaged applications offer distinct advantages over those that don’t, because you can gain access to packaged application metadata and build portlets without programming. Vendors like Vignette (who were first in the market with this kind of support) and IBM offer this with portlet builder kits for packages like SAP, Siebel, Oracle and Peoplesoft.

Also, many legacy client-server applications run via a terminal server ‘ultra-thin client’. These include Citrix and Windows Terminal Server. You cannot seamlessly integrate the user interfaces of such applications into a portal on day one, as some may be high priority while others are not. However, if you want these non-web applications integrated with the portal, you should temporarily integrate your terminal-server software into the portal as a portlet – until the application user interface is re-developed. The implications of a portal on a terminal server environment are clear. It will trigger a ‘transition’ that will ultimately phase out terminal server technology in favour of a new, personalised ‘webtop’. This will be done at a pace and budget dictated by you. If you have thin-client Windows Terminal hardware, these terminals should accommodate the transition as they can run a browser. Enterprise portals can accommodate ultra-thin client applications for as long as required via a terminal server portlet. Windows Terminal Server or Citrix portlets enable client-server applications to run, unchanged, ‘inside the browser’. As applications become web enabled and move from two-tier to one-tier architectures with portlet-based user interfaces, the need for a terminal server will slowly reduce until it is no longer needed. This may happen over a number of years. Once you understand your requirements, you are ready to enter the marketplace and evaluate products.

Integrating portal products
Assuming selection proceeds, the next most commonly encountered problem is that of ‘portal chaos’. This is when you discover that you actually have multiple portal products already in your organisation. It is common place, for example, to have multiple BI portals (these often come free with a BI tool set). If you have this problem you are not alone. If you don’t, then expect it – it is the norm.

So, how do you recover from portal chaos and move towards one enterprise-portal solution? The answer is: a federated portal architecture (see figure 3); web services; use of portal standards; plus, setting portal-governance policies on your standard approaches to security, single sign-on, personalisation, portlet development, taxonomy integration, content categorisation and search. Whatever you do, don’t assume everything just plugs together like Lego – it does not.

With a federated portal architecture, you must first choose an enterprise-portal product that you want to become the point of entry for users and the glue that integrates all user interfaces. Bear in mind that this product will, ultimately, have to integrate with everything if it is to become the new desktop. Once this has been decided you can get to work.

BI portals can be integrated with an enterprise portal via proprietary BI portal-integration kits (PIKs) or web services. BI PIKs are a set of pre-built portlets that vendors offer to integrate their BI tools with popular enterprise-portal products. These typically exist for specific portal products. As service-oriented architectures and web services become commonplace, the need for PIKs is disappearing and being replaced by a single industry-standard approach that integrates BI with any portal product – web-services remote portlets (WSRP). BI vendors are now releasing WSRP compliant web-service interfaces to their products (for example, Cognos 8, Business Objects XI, SAS 9, etc) with user-facing web services. If you have these releases, integration with an enterprise portal is based on essentially ignoring the BI portals offered by vendors, while simply integrating the user-facing BI web services directly into the enterprise-portal server.

Figure 4 shows a screenshot of an IBM WebSphere Portal Server administrator screen, where you can request that the portal integrates a web service as a remote portlet. In this case, the portal server reads a UDDI registry and the administrator selects the remote service they want to connect and create a portlet for. Once this has been done, the portal server generates a JSR 168-compliant ‘proxy portlet’ for the remote web service. The portlet can then be snapped into the appropriate portal page and made available to any authorised user.

When the user opens the page holding the remote portlet, the portal server requests the content from the remote web service via standard SOAP protocol. Note that content-management systems, application functionality etc can all integrate with enterprise-portal products in this way.

Sounds easy, but it is not always that simple. It is commonplace, for example, for companies to want to integrate Microsoft SharePoint with enterprise portals like those offered by SAP, Oracle, IBM and BEA (Plumtree).

This is more difficult. You can’t just pick up Microsoft SharePoint Portal Server Web Parts (portlets) and use them as portlets in a Java-based enterprise portal. This is mainly because Microsoft web parts are not JSR 168 compliant. JSR 168 is an industry-standard, portal independent application program interface (API) that allows portlets (which are effectively small applications) to make use of services that the portal offers, such as security. This potentially allows JSR 168-compliant portlets to run on any portal product supporting JSR 168. What about WSRP here? Well, even if you were able to publish SharePoint web parts as web services, they would most probably still not work in a Java-based enterprise portal. WSRP still requires the portlet to be JSR 168 compliant and Microsoft has not yet provided WSRP support in their portal product. Therefore, web parts are not consumable as WSRP remote portlets. Some portal products like BEA Plumtree support the ability to run SharePoint web parts in their portal. They have built a proprietary wrapper that makes web parts function like Plumtree proprietary portlets. Another possibility is to go to a vendor like NetUnity (www.netunity.com) and use its JSR 168 compliant WSRP Portal Framework for .Net to build WSRP wrappers for web parts. This framework consists of .Net classes that can be used in the Visual Studio .Net IDE.

Another way to do this is to ignore SharePoint web parts altogether and build your own generic, JSR 168 compliant web-services portlet (or use one shipped by the portal vendor) that can make use of one or more SharePoint Web services. SharePoint provides an extensive web services API, through which you can perform a wide variety of functions. SharePoint data items such as news, events, ‘to-dos’, contacts and document libraries are stored in lists and detail the services that exist to get this data and display it in a portlet.

Many external content-management-system providers are also exploiting web-services interfaces, to integrate their services as remote portlets.

So, you get the idea. But it is not just about portlets. Federated portal architectures require security lightweight direct-access protocol directories to be either shared across, or synchronised between, portal products. In addition, federated search will be needed.

In next month’s article, we will examine taxonomy design and categorisation; as well as customising the portal to meet your organisation’s requirements.

Mike Ferguson is managing director at Intelligent Business Strategies Limited. He can be contacted at: mferguson@intelligentbusiness.biz.

Box-out: Example portal-technology requirements list

Personalisation support;
Single sign-on integrated security (including LDAP support);
Flexible and customisable user interface (this should include multi-lingual support);
Extensible and open portal directory;
Integration with Microsoft or Lotus e-mail;
Integration with third-party, or shipped with a set of additional collaboration tools;
Manual and automated content publishing (including content approval);
Integration with third-party BI tools and content-management systems;
Automatic content discovery and categorisation;
Integrated search engine;
Portal development kit and support for web services;
Integration with terminal-server software;
Schedule and business-rule-driven delivery with notification;
Implicit (via group/subject area registration) and explicit (via direct subscription) information notification and delivery;
Application integration via remote portlets;
Integration with BPM software (for example, task list portlet) and EAI software;
Portlet development via shipped tools and your own existing solution;
Integration with your web application server;
Administration and management features (for example, security, performance, scalability and user management);
Support for offline browsing (for example, via a disconnected laptop);
Support for JSR 168 and WSRP standards.

The perfect portal implementation: Eight steps to heaven Part II

The perfect portal implementation: Eight steps to heaven
Part II