Abstract
For over ten years, RivCom has managed the content and publishing processes for the business process models of a major global corporation. Since the publication of the XML standard in 1998, XML-based technologies have been at the core of the systems used to deliver the models to users on the web. Two years ago, data was migrated from a dedicated structure to XTM (XML Topic Maps). This move was driven for a desire for greater flexibility to evolve systems over time as needs changed, and to integrate more easily with other enterprise applications. This application itself was at this time based on an XSLT-driven processing pipeline, generating static HTML pages from the XTM, with source data derived from MS Excel spreadsheets. While this was stable and easily configurable, the overhead of each publishing cycle became too high for the increasingly frequent updates to the business process models which the system was being required to deliver. The application also required specialist management, and a key issue for the client was their dependence on an external supplier for this expertise.
In 2003, a project was commissioned to develop the application further, with the twin goals of bringing management of the publishing process wholly within the client company, and giving the creators of business process models the ability to develop and edit models online, and in a web-based editing environment which mirrored the final published site. Following technology option evaluation, a decision was made to develop the new application using a J2EE-compliant topic map engine, and the Ontopia OKS was selected for the task. This approach reflected the desire to build on the existing infrastructure and to re-use current code wherever possible. An additional factor was the anticipated lower total cost of ownership and ease of maintenance than alternative options, with almost all application code held in JSPs and XSLT. Development of the application was completed in 2003, with migration to the corporate eHosting environment taking place in early 2004. It is deployed on WebSphere 5.0, with data storage in an Oracle 9i database.
The case study presentation describes the application development process and background in detail, covering in particular:
the domain context, and the business drivers behind the project
the way in which topic maps have been used to represent corporate business process models and associated data
an outline of the application architecture
the management and support issues inherent in deploying this sort of application within a global corporate IT infrastructure
a demonstration of the system as implemented
an initial evaluation of the success of the project, and an assessment of the suitability of topic map based approaches to similar projects.
Keywords
Table of Contents
The Business Process Model Publishing application is the latest manifestation of a content delivery system which has evolved over a number of years to support the publishing of business process models. These models are typically developed over a period of months by a Process Team, before being published into an Intranet environment. The development process will include work on a range of content, including:
creation of a model hierarchy
addition of text descriptions within a descriptive template
links to other models
classification of individual processes
Once content development has been completed by the Process Team, the model will be reviewed and validated by the Publish Team, before being published to the Intranet. The diagram in Figure 1 shows this typical business process model lifecycle.
There are a number of underlying business drivers behind the development of the application. First, there is a need to provide support to end users in an intuitive environment through all stages of the development and publishing process. This should minimise dependence on technical support, and bring about faster times to publish, as well as significant savings on the previous manually-driven publishing operations. Second, as business process models become more tightly integrated into global operations, the systems used to develop and publish these models themselves need to be capable of integration with other systems, and of being easily extended into new areas. In particular, linkages with knowledge repositories, where documents such as procedures, templates and specifications are stored, are perceived to be critical to the success of model publishing.
One important part of the overall context for the business process models is the existence of a Master Reference Model. This model is in effect a taxonomy of generic activities, which can be used as reference point for model developers. As part of the publishing process, processes in each new model are 'mapped' to corresponding processes in the Master Reference Model. In this way, correspondences between individual models can be derived by resolving common references to the Reference Model, avoiding the need for many-to-many mappings between models. The diagram in Figure 2 shows the logical process model environment.
The business process information represented in the application have been modelled as topic maps since 2001. The decision to use the topic maps paradigm was based on:
the need for flexibility going forward, as process models evolve and extend their scope
the need for process models to reference and incorporate data from other diverse systems
the availability of commercial tools to support publishing and editing topic map data.
The model used to represent business processes as a topic map is relatively simple, as Figure 3 shows.
The key elements of the representation of business processes as topic maps are:
all process in the business model are models as topics of the same type
the hierarchical structure of the model is represented by associations of type 'composition'
links between the process objects in the business model and process objects in the Reference Model are represented by associations of type 'specialisation'
the sequence of sibling processes is represented by associations of type 'sequence'
almost all other data is held as occurrences of topics.
Figure 4 shows the application architecture.
Data is stored in an Oracle database, using the Topic Map schema supplied by the topic map engine. The business process model application is deployed in WebSphere Application Server, and the topic map engine uses its RDBMS backend connector to access the topic map in the database. Application code is almost all written in JSPs and XSLT, with JSPs implementing the business layer, making calls to the database through the topic map engine. XSLT handles transformations to the presentation and output formats, including HTML, SVG, and Microsoft Word and Excel, with XSLT transformations using MSXML on a standard Internet Explorer client.
In considering total cost of ownership for an enterprise-level application, support and management issues are an important factor. The Business Process Publishing application aims to pass as much control as possible to users. This is done in a number of ways.
A key feature of a topic map based application is that the underlying meta model is part of the application content, and so by applying the same editing interfaces to the data model as are applied to business process model content, the model itself can to some extent be managed and extended from within the application. This means that changes can be made by authorised users, without the need for application development work. Currently, user-level editing of the meta model is restricted to adding and editing field-level help text. However, it could be extended in a controlled fashion to allow, for example, the addition of certain objects and values.
All key publishing events are user-driven, including:
new business process model creation
'cloning' of process models for editing
publishing of process models to the Intranet domain
rollback to previous versions of process models
backup and restore of model snapshots.
This means that technical support is needed only for one-off actions such as legacy data migration.
Application development, when it is needed, can for the most part be handled in the presentation layer using XSLT, or in the business layer using JSPs. In some cases, meta model development alone can be used to extend or amend the user interface.
The conference presentation will include a demonstration of key aspects of application functionality, including:
creation and population of a simple model
adding rich text and 'mapping' data
managing the business process model lifecycle
output and presentation formats.
The application puts in place the core facilities which business model developers need to drive the publishing cycle, and to allow rapid iterative model development. However the migration of business models into an accessible corporate environment paves the way for much wider use of this data. A number of options are currently being scoped, including:
extension of user control over the meta model, allowing users to add data items and configure publishing and editing functionality
closer integration with enterprise applications, and incorporation of business metrics into model representations
extension of graphical representations of models, allowing greater user control/selection over format and visualisation options
generation of static 'offline' version of application
dynamic interaction with local data sources, including standard office tools
handling alternate naming schemes and languages.
  |
Design & Development by deepX Ltd. |
