This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Moving beyond conventional portals -- with their chaos of directories and portlets to disparate applications -- organizations are starting to deliver information in the context of user roles and processes. The challenge is selecting technologies that will create a single, cohesive environment that supports both Web-and thick-client interfaces.
Information is power: Organizations that exploit that power will successfully grow their businesses. The challenge for most companies, however, is managing exponential information growth while connecting users with the data, content, applications and processes they use in their various roles. The solution is to create role-based personal workspaces.
Personal workspaces provide a collaborative environment in which users can access, share and communicate with others about the information they need to do their jobs. Many companies are developing and deploying these environments using Web portals. The challenge is selecting tools that will support a single, cohesive environment — a tough choice now that portal technology is offered through a variety of software, including application servers, packaged applications, business intelligence tools and content management systems. Another complication is that many advanced analysis and collaboration tools rely on thick-client software rather than the Web interfaces favored in portal environments.
Personal workspaces are fast becoming the main gateway to information, applications and processes. It's crucial to develop a strategy for building and successfully deploying these environments for employees, partners and customers. This article explains how portals are evolving to support role-based workspaces and how you can make the right choices to develop a coherent strategy supporting both Web- and thick-client interfaces.
Evolving the Portal
When portals first appeared, they enhanced existing corporate intranets with single sign-on capabilities and facilities for organizing and personalizing information. The focus was on improving employee productivity and efficiency through self-service and on lowering costs by providing access to information in electronic formats, thereby reducing paperwork.
Improved productivity and reduced cost are still the focus of many portal projects, but the capabilities of these environments have expanded significantly over the years. Most portal products now support collaboration and content management. Portals no longer simply provide directories that point to the location of data and applications; they now offer powerful tools for taxonomy development, content categorization and personalization, and enterprise search. These enhancements at last deliver many knowledge management capabilities promised by vendors years ago.
Portals are now incorporating composite applications and business process workflows between the user interface and underlying information. This semantic layer gives users access to information in the context of their roles and activities. In a support center, for example, customer service representatives could see a business process workflow that leads them through a series of tasks they must perform to answer customer questions.
Often implemented in conjunction with an SOA (service oriented architecture), the semantic layer insulates users from the chaos of disparate data stores and apps. They can better view information from the perspective of business processes.
Now that portals offer powerful knowledge-management and business-process capabilities, your portal strategy must take into account related IT initiatives in areas such as collaboration, content management, enterprise search, business process management and SOA. Without a coordinated strategy across these areas, your portal can't achieve its primary objective of providing a single interface to enterprisewide information.
The two main alternatives for building a portal are to select a solution from an IT infrastructure vendor, such as BEA Systems, IBM, Microsoft, Oracle or SAP, or to integrate independent portal, content management and collaboration products with your existing IT infrastructure. As always, the choice is between relying on a single vendor's preintegrated solution or selecting best-of-breed technologies and integrating them.
Packaged applications often provide portal interfaces, but these are generally developed on the underlying application infrastructure. Microsoft, Oracle and SAP, for example, frequently employ the portals provided with their application server software. If this happens to be a different app server than that used for other business applications, you'll likely have to choose between one of the two portal solutions or find a way to integrate the two environments.
The Microsoft Problem
One of the biggest portal strategy hurdles is the fact that most organizations rely on Microsoft Office for workgroup computing. Fortunately, Microsoft is tightening the integration of Office, Windows and Windows SharePoint Services in the coming releases of Office 12 and the Windows Vista operating system.
These introductions will encourage more organizations to use integrated SharePoint Services at the workgroup level. As workgroups proliferate, companies will need a portal to manage and search the related content. Microsoft's solution is the SharePoint Portal Server.
However, the Microsoft workgroup environment creates two problems. The first is deciding how the workgroup portal will interact with the business portal (a term used here to cover enterprise, business-to-business, business-to-consumer, business-to-employee and departmental portals). One obvious choice is to use the SharePoint Portal Server for both environments. This approach works if SharePoint provides the functionality and if your enterprise infrastructure is based on a Microsoft .Net framework.
If your organization, like many large firms, relies on a Java-based infrastructure, you'll have to find a portal that supports both .Net and Java — and that also works well with Windows SharePoint Services — or you'll have to integrate the SharePoint Portal Server workgroup environment with a Java-based business portal. Many will choose the latter approach; standards (such as JSR 168, JSR 170 and OASIS WSRP) coupled with Web services will be the key to success.
The second problem with Microsoft workgroups for portal implementers is that the full version of Office is only available from client-based software. Microsoft has made great strides in Web-enabling Office, but many users still need full capabilities from thick-client software.
This dependency isn't unique to Microsoft products. For example, most advanced BI tools have the same limitation. Vendors are responding with more browser-based functionality, but the Web isn't well-suited to certain types of processing. In fact, portals have failed when organizations tried to make rich features available through browsers.
Personal workspaces need to support both Web- and client-based interfaces. The Web portal is the main environment for accessing and sharing information and supporting collaboration. When more advanced content management, collaboration, workgroup or BI capabilities are needed, personal workspaces will let users switch to thick-client interfaces.
This dual approach has been embraced by many software vendors. SAP, for example, emphasizes the use of its NetWeaver portal for enterprise computing, but its joint Mendocino project with Microsoft will result in an Office interface to SAP applications. IBM, with its WebSphere Portal Server and WebSphere Workplace products, also accommodates both Web- and client-based modes of operation (with the latter frequently involving Office).
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.