Thursday, November 16, 2006

Integration of BPMS and Portals

A recurring question is the integration of BPMS and Portals - how would organizations benefit from the interaction of these two technologies?

'Integration' is a word often avoided by Portal vendors. Vignette preferred the word 'surfacing', since it reflects more closely what is happening when an application's data is presented in the Portal. The chosen data or predefined portlet (a visual application component) is pulled through the Portal and 'surfaced' on the screen.

With a strong Enterprise Portal, formal integration is not required, instead just the configuration of what is displayed where. That said, often implemented as a precursor to a broader SOA platform, the portal becomes the central meeting point for many system integration activities that provide composite applications through 'integration on the glass'.

Outside of this, Enterprise Portal value is sold on:


  • Providing end-users with a single, consistent point to interact with systems and find information
  • Enabling personalization of appearance and applications, to help users feel comfortable with the system and more rapidly find information relevant to them
  • Implementing a consistent technical and visual framework for integrating disparate systems and information services
  • Simplifying, delegating and enforcing administration of Intranet and Web Sites, taking the burden off IT and web designers
The value associated with Portals can be related to many systems deployed in organizations, including the BPMS. A BPMS can incorporate some of the features of a Portal into the native BPMS application, such as consistent presentation, delegated administration and componentized user interfaces. The latter though often demands webpage development to perform.

A BPMS may benefit from being surfaced in a broader Enterprise Portal system, providing consistent access to BPM and the other resident information systems, potentially showing information from both on the same page. For example, this could provide the end-user with contextual information from a knowledge base, automatically displayed based on the type of process or activity he or she is working. In flexible, browser based BPMS applications there is of course no reason why this type of functionality could not be integrated by IT, but the value of the Portal is that once each system is integrated once, it can be reused in other parts of the application without web developers getting involved.

The previous example implies that the most valuable way of surfacing a BPMS in a Portal is for the presentation of end-user work lists, individual work items and associated data. For users who work with BPM occasionally, for example for Expense Claim Approvals, pulling the BPMS into a broader Employee Intranet may help the ease with which users can find and use the system. For the other extreme, heads-down users processing large volumes of work, or customer services focused users, demanding Portal presentation needs to be carefully assessed to ensure that it truly offers value and does not in fact hinder the fast, effective and efficient interaction with the BPMS. Composite display and interaction may slow the system and detract from the user experience.

From another point of view, supervisors or administrators of BPM may benefit from the flexibility and user driven configuration of applications available through Portals. Being able to simply configure the most important process analyts charts for his department may help a supervisor to most quickly and effectively monitor the performance of his staff and spot potential red-flags. Being able to display this information alongside information from other systems enables a better contextual view of what is happening, and why.

Portal 'integration' can be approached in several ways:

  • Surface main web page components directly in the Portal
  • Use the Portal's application / portlet designer
  • Develop highly customized portlets using JSP
For example, Global 360's Java BPMS provides flexible enough browser-based presentation components to be effectively surfaced directly in an Enterprise Portal. Use of the portal's own portlet/application design tools can use the full BPMS Web Services or Java Client API to provide highly configurable displays of data from the BPMS in ways not invisaged by the original user interface. Finally, web developers can easily use familiar JSP page design to create standards-compliant (JSR-168) portlets for highly customized presentation.

True Enterprise Portals can provide a lot of value to an organization. For the right scenarios a BPMS should be surfaced within a portal. The right scenario is typically not one where the BPMS is used for very high volume human-centric processing or data entry, where the Portal is just being used to provide a consistent user interface and slighly simplified page layout capabilities. If a BPMS vendor insists on the importance of a portal for a high-volume processing application, see a red-flag. The BPMS that salesman is pushing you is probably not really designed for your high-volume requirements, and is more likely designed to look pretty for managers approving occasional expense claims.

Technorati tags: BPMS Portal

No comments: