RivCom has been involved with helping Shell to publish its business process models and related information since 1991, when the newly-released Word 1.0 was used to publish the Guide to Procurement and Logistics Management (GPLM). These models have always been of high strategic value to the business, and over the years since RivCom has been involved this value has steadily increased, and publishing and management requirements have grown in parallel. Models now have complex multiple hierarchies, and are mapped to each other directly and through other models. As complexity has grown, so has the challenge of designing and implementing intuitive and functional interfaces.

When the first project was commissioned in 1991, SGML was a serious candidate for the delivery system. However the first development was based around MS Word, with Word fields used to incorporate 'tags' in the content, a database to store the structure of models, and PostScript processing for intelligent rendering of the combined Word and database output. This allowed us to ensure the integrity of the structure in the database, and to use the PostScript to include non-Word, hypertext-like features in the printed output. The example in Figure 1 is similar to the published version, which included glossary definitions and 'call-out' boxes.

Figure 1. Printed page in style of Word version of DBAM

Following the production of the GPLM, the same techniques were applied to the Downstream Business Activity Model (DBAM). As with the GPLM, an online version was not part of the brief, but the structure of the document was developed with online delivery very much in mind, and the design of the pages mimicked a static representation of a dynamic HTML page.

In 1997, the expected call came for online delivery, with navigation, behaviour and presentation which brought to life the 'pseudo-hypertext' of the printed page, which had gained wide user acceptance. Recognising the opportunity to build on the work which had already been done, Shell Oil Products agreed on a strategy of storing and editing the content in XML, then in its infancy. As there was at that time no reliable way of presenting it in the browser, approval was also given for development of a simple browser plug-in (for Netscape, later cloned for IE) to transform the XML to HTML on the fly - known as RivComet. RivComet used its own stylesheet language, RivComet Stylesheet Language (RSL) to provide the behaviour in the browser that MSXML does now with XSLT. RSL also included the interface functionality now covered by JavaScript, DOM manipulation and CSS. This allowed us to manipulate an XML tree in memory, and for example use it to hold user preferences to drive the showing and hiding of sections. Functionality also included the ability to run queries between one window and another, and to specify in RSL direct communication with the browser engine from the interface.

The RivComet version of the DBAM was for a number of years a core resource within Shell Oil Products, and used to support business process development throughout the world.

More recently in 2001, new requirements and constraints began to emerge. First, on the delivery side of the picture, Shell was moving towards implementation of a global 'locked-down' desktop environment, and third-party browser plug-ins didn't sit easily within this approach. RivComet development was barely keeping up with developments in browser architecture, and standards-based approaches were beginning to provide much (though not all) of the functionality in the plug-in. Second, on the content side, business drivers were moving away from a single all-encompassing 'template' representation of business model, and towards a series of independent models. These needed to be mapped to each other through a common framework of generic activities, contexts and patterns, which could be used as reference points for the much more diverse range of business activities that users needed to model. Figure 2 shows the overall content architecture which the new version of the system needed to be able to support.

Figure 2. DBAM4 Content Architecture

In this phase of development, the focus for the client was strongly on getting content in place, and there was no strong requirement to fund a long-term editing and publishing infrastructure. On the other hand, it was clear that we needed to put the foundations in place for a system which would potentially in due course form the basis for something which would have much wider scope and degree of integration with other systems than it does now.

<activity ID="se12.m05.05" name="Establish costs and margins" refcode="05">
 <descrip>
  <para>Evaluate current operational costs and <glref glidref="margin">margins</glref>.
   Evaluate the forecasts of future demand and their likely implications on costs and margins.
   <crefs>
    <cref type="proc" pridref="se10.m10.20"/>
   </crefs>
  </para>
 </descrip>
</activity>

4.2. Editing

With this component in place, it remained to build and editing interface able to create XTM structures, and a delivery mechanism to the browser.

The decision on the editing interface was constrained by a need for pragmatism, working for the moment within the Shell global desktop environment and the tools it provided. In effect this meant a Microsoft Office based approach. The familiarity and wide acceptance of the Excel interface for both editing and presentation in Shell was the strongest factor in its adoption. To support the creation of structured business models, VB automation was developed for tasks such as creating links between model objects and grouping and outlining. An example of the resulting interface is shown in Figure 3.

Figure 3. Example Excel interface

For some parts of the DBAM site, in particular those dealing with the data models which supported the business process models, Excel did not provide an editing interface which was robust or simple enough for the more complex data structures involved. This led to the use of Microsoft Access as the principle editing tool for data models, with an integration interface with the core system. Updates generated in Access are incrementally imported into the core XTM data using an XSLT-driven pipeline of validation and refresh modules.

4.4. Activity Descriptions

Text descriptions were the final component in the system which needed to be integrated. In all the data structures described so far, descriptions were treated as external resources, referenced in whatever format they were currently held. In most cases, descriptions were held in a simple XML format, and were edited in an XML editor. However both XHTML and Word sources for descriptions are handled in the publishing mechanism, with conversion from Word to XML carried out using upCast.

The overall processing architecture, the individual components of which are described above, is based on a simple XSLT pipeline, and aims to provide maximum flexibility to handle both known and unknown input and output requirements. Figure 4 shows this systems architecture.

Figure 4. DBAM4 Systems Architecture

As time goes on, more models are being added to the system, and requirements for tools which support end-user creation, editing and publication of models get stronger. Control over content needs to be rolled out to a wider user base, and on-demand access to a snapshot of model content made available at any stage in model development. Off-site pipeline processing of models is no longer able to adequately support the rate of development of content.

Bearing in mind the need to work within modest development budgets, and to retain compatibility with Shell software standards, a number of options are being researched. At this stage, a range of XML and non-XML architectures are being considered, including:

There are also emerging requirements on the publishing and interface domains which will require development beyond the current system. For example:

Our experience has been that XML has certainly given us flexibility over the years, and has allowed us to develop incrementally with little or no licensing outlay either on our part or that of our clients. The use of standards-based data structures has given us a set of tools which can be applied in other circumstances, and while they are applied in this instance to the delivery of business process models, they can easily be adapted to deliver any set of hierarchical data. Adding new input and output formats to the core system is not a major task, and one that is becoming easier as mass-market tools such as MS Office adopt native XML functionality.

It is clear that both development of stable XML standards, and solid support of these standards within mainstream browser software has been slower than we might have anticipated, and this has held us back from full implementation of certain of our long-term goals. With SVG dependant on third-party viewers, for example, there are difficulties in delivering SVG to the desktop in a managed environment where third-party tools are not actively embraced. XForms 1.0 is still only a candidate recommendation, so the addition of the tightly integrated XML-based business process model editing interface interface we know is possible will have to wait. In practice, while the route forward for this application seems clearly to be an XML-based one, there are more barriers than we would have hoped for in 1998 to large-scale mission-critical development using XML.