The perfect portal implementation: Eight steps to heaven

Part V: The penultimate instalment of this workshop series focuses on developing, implementing and integrating information and collaboration tools with the portal. By Mike Ferguson.

The eight-step approach to portal implementation
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 tools 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.

The seventh step of our implementation involves the integration of information, collaboration tools and applications with the portal. The ‘information’ element covers unstructured information, such as office documents, images and digital media, as well as semi-structured information that has been tagged in some way. This could include extensible mark-up language (XML) or hyper-text mark-up language (HTML) web pages. Finally, it could also include structured data stored in a database management system. Figure 1 shows that this information can reside in multiple places including:

Content stores that ship with the portal;
Third-party document and web content-management systems;
File systems – for example, office documents;
Database management systems;
External websites and syndicated content feeds.

The point here is that these are not mutually exclusive alternatives. In fact, most of my clients have all of these and, therefore, face the challenge of integrating them with a portal server. A recent survey of Fortune 1000 companies highlighted the fact that organisations have, on average, more than six content repositories – meaning that the real challenge is the integration of several, rather than one, content-management systems (CMSs).

Content stores, which can be used to manage documents and digital media as well as web content, typically ship with the portal server. They can also be obtained as a separately chargeable, add-on component. Pre-built portlets provide a user interface to the portal’s content store, using portlets to view and manage content. Figure 2 shows a screenshot of BEA Systems’ AquaLogic portal product, where the user interface is simply a series of portlets.

If you have a third-party document or content-management system, such as EMC Documentum, Interwoven or Stellent, you will need to integrate this with your portal. To enable this, the portal or content-management vendor should supply you with:

Pre-built portlets to manage and view content in that system via the portal;
Pre-built crawlers to discover the content in the third-party CMS, to include in search indexes;
Pre-built crawlers to discover the content in the third-party CMS, to update the portal taxonomy with references to that content.

The portal taxonomy is different to that of the CMS. Bear in mind that the portal may be referencing content scattered across multiple file systems, internal and external websites and several CMSs. For this reason, even if the CMS content is well organised it needs to be clustered in the same categories as related content that is stored elsewhere – whether internally or externally. If the CMS vendor does not provide pre-built portlets they should, at the very least, supply an application program interface (API) so that some kind of integration is possible. Figure 3 shows EMC Documentum integrated into the BEA AquaLogic portal using pre-built portlets. Notice the taxonomy portlet on the bottom left of the screen. This provides a view of how the content is viewed in the Documentum system, for which a crawler is also available. Web pages themselves can be quickly integrated into a portal using a technique known as web clipping. Another name for this is HTML scraping. Figure 4 shows an example of this in Microsoft Office SharePoint. Web clipping is attractive because it is fast and cheap. However, it is often best suited to static web pages as opposed to dynamic web pages.

Business intelligence (BI) can also be integrated into the portal using pre-built portlets. In this way, users can view reports, drill down to data and slice and dice it within the portlets.

It is also possible to make use of enterprise-information integration (EII) tools to integrate information residing in multiple locations into the portal. Popular products that can do this include Vamosa and Kapow RoboSuite. There are many other products on the market, but these two in particular specialise in real-time (and batch) integration of unstructured content from multiple sources. With EII, federated queries that integrate and re-purpose unstructured content can be created, saved and published as web services. These can then be invoked by proxy portlets via web services for remote portlets (WSRP) to trigger on-demand integration of information when a user opens the portal page. This is illustrated in Figure 5.

With respect to information in file systems, crawlers can automatically discover this to include it in search-engine indexes, and also as referenced items in portal taxonomies. The user can therefore navigate the portal taxonomy or search for the content using a search engine (See Figure 6). In addition, really simple syndication (RSS) feeds and other syndicated content can be integrated into the portal directly from the internet via pre-built portlets.

Integrating collaboration tools into the portal
It is often the case that many companies also want to integrate collaboration tools with their portal. Today, when we talk about collaboration tools most people think about e-mail or instant messaging (IM). However, the market has changed to the point where single vendors are offering a whole suite of collaboration tools. These include EMC Documentum, IBM WebSphere Collaboration Services, Microsoft Exchange, Live Meeting and Live Communications Server and Oracle 10g Collaboration Suite. Typically, most suites will include tools such as:

E-mail;
Expertise locaters and trackers;
Content meeting points where experts congregate and collaborate;
Presence awareness and availability management;
Shared calendar information;
Conference room management and moderated chat;
Net meetings and live threaded discussion capabilities;
Document co-editing tools;
IM for real time polling, alerting, chat and response.

Collaboration tools are useful for many reasons. Net meetings can reduce travel costs, for example, and facilitate the sharing and discussion of BI in decision-making processes. They help us to locate and collaborate with ‘expert’ staff, who may be in other locations. It is also possible to collaborate with partners over marketing initiatives and with suppliers on just-in-time delivery of inventory or to resolve logistical problems. The confusing thing about collaboration tools is how they are brought to market. For example, you can buy and use them as stand-alone tools, where users log on and make use of a tool-specific user interface. An example here might be Microsoft Outlook. Also, rich Office clients are now embedded collaboration tools, too. For example, it is possible to enter into a threaded discussion from within Microsoft Word or IBM Workplace. In addition to this, collaboration tooling can be embedded directly inside applications, such as customer-relationship management (CRM) and BI performance-management applications. Finally, you can buy a suite of collaboration tools with portal products, whereby they appear as portlets in the portal’s user interface. Users can then make use of the tools directly via the portal. This enables administrators to make use of portal personalisation to select the collaboration tools they need for specific users and for specific process tasks.

However, with all these options available it is often the case that companies can get themselves into ‘collaboration chaos’ by having any or all of these. The problem here can be:

Lack of integration and sharing of collaboration tools;
Potential duplication of tools across multiple applications;
Collaboration content (for example, threaded discussions or e-mails) scattered widely across multiple systems so that it is not easy to find the knowledge buried within it.

The ideal architecture that you should, ideally, aim for to combat this problem is shown in Figure 7, where common collaboration tools are shared by the portal, office applications and other operational and BI applications. It is also desirable that the ‘collaborations’ themselves – for example, e-mails and instant messages – should be stored in an enterprise CMS and crawled, so that the content can be included in search indexes and the taxonomy.

It is a good idea to create common collaboration services that can be integrated with the portal and do the following to maximise the potential benefits of implementing collaboration tools within your organisation:

Upgrade collaboration tools to a version with web services APIs (collaboration services);
Upgrade collaboration tools to a version that stores collaborations in a CMS;
Integrate collaboration content for all to share;
Integrate common collaborative tools with portals and portal workspaces – create collaboration workspaces via the portal to allow authorised communities access to shared workspaces;
Crawl collaborative content sources for categorisation and building of search indexes, and facilitate search across collaborative and standard content;
Upgrade to MS Office rich clients that integrate with the portal or directly with collaborative services;
Build composite applications that integrate collaborative services with other services – reference collaborations from within application data structures to relate the data;
Integrate collaborative services into business processes;
Push application and BI vendors to leverage common collaboration services.

There are a number of benefits to integrating collaborative tools into a portal:

Portals offer security and personalisation with collaboration;
A portal user can see if other users are online (using a portlet) and access collaboration tools via portlets to interact with them;
Portal users can take actions on documents or user names that appear in a portlet;
Shared workspaces (for example, team workspaces or project workspaces) can be saved and re-used by other portal users to really take advantage of the knowledge captured in collaborations;
Collaboration can be introduced into existing business processes in a specific context, by integrating collaboration portlets with other application and information portlets into process task portal pages.

In next month’s article I will look at completing step seven by discussing how applications and processes can be integrated with the portal’s user interface. In addition, and to round off this workshop series, I will also cover portal personalisation.

Mike Ferguson is managing director of Intelligent Business Strategies Limited. He is also a partner in iBonD. 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.