| author(s): | Wolfgang Emmerich, Sergio Bandinelli, Luigi Lavazza, Jim Arlow |
| title: | Fine grained Process Modelling: An Experiment at British Airways* |
| organisation(s): | - |
British Airways is a large software developer in the UK, with some 2,000 IT staff. An increasing number of operations research programs (such as fleet or crew allocation) are now being developed with object-oriented techniques. To increase productivity and quality, BA have founded a group called Infrastructure who is in charge of maintaining the design, implementation and documentation of reusable C++ class libraries.
The Infrastructure group has created a process handbook entitled Standard Development and Release Procedures. It elaborates on the process to be used for class library development and maintenance. The handbook suggests, in a rather informal manner, the various actions to be taken for class library development and maintenance. It identifies a number of document types, including Booch class diagrams, C++ class interface definitions, C++ class implementations, class documentation, Makefiles and the like.
Two main problems were identified by Infrastructure with their approach to process management. The first problem is that their informal definition of the process easily leads to misunderstandings. Two Infrastructure developers, who have worked in the same office for two years, discovered a serious misunderstanding of a key concept defined in the handbook when we discussed their process in a meeting. It turned out that they did not have a shared understanding of the semantics of a library configuration in beta test as opposed to development mode. The second problem is mentioned in the following quote from Infrastructure members:
``Within Infrastructure, we have had to apply an excessive amount of effort to establish change control procedures, but these procedures are only partially effective as they are not enforceable by our current toolset. As BA's stock of reusable components grows, the problems of effective change control will become more and more pronounced.''
In the experiment we report about in this paper, we set out to solve the first problem by modelling the BA class library development and maintenance process with SLANG, a high-level Petri net-based process modelling language with precise formal semantics. The second problem was addressed through the construction of a dedicated set of tools for the definition of Booch class diagrams, C++ class interface definitions, C++ method implementations and class documentations. The user interface of this tool set is displayed in Figure 1. The toolset was integrated with the enactable SLANG process model to enable the enforcement of the process and to support process automation at the required granularity level.
Figure 1:User Interface of BA PSEE Tools
2. SLANG Process Model
SLANG facilitates the decomposition of a complex process into a structured set of fairly independent m activities. The activity construct was also used to model the BA process. Figure 2 presents the model of the overall process model (the root activity), which contains sub-activities SessionManager, AccessControl, ConfManagement, and VersionManager, each modeling a specific sub-process.
Figure 2:Root Activity
Activity invocations are represented graphically by embedding an activity interface into a SLANG net. Activity interfaces are provided with interface transitions, i.e., starting transitions (placed on the upper side of the activity box) and ending transitions (on the lower side). When a starting transition fires, a new instance of the activity (called active copy) is created. Active copies are executed in parallel; this feature was used to model the concurrent work of BA engineers. For instance, two tokens in place LoginMsg cause the starting transition of activity Session Manager to fire twice, thus creating two instances of that activity. These active copies are executed in parallel with the root activity. When an ending transition fires, it deposits the resulting tokens into some output places (e.g., SessionManEnd), belonging to the calling activity, then the terminated active copy is deleted. An activity can also exchange data with the calling activity through shared places. For instance, the SessionManager sends CMRequests to the root activity and receives CMAnswers.
White transitions represent elementary process steps. Their execution is atomic, in the sense that no intermediate state of the transition execution is visible outside the transition. Each transition is associated with a guard and an action. The guard is a predicate indicating whether the transition is enabled to fire or not. The action specifies how output tokens are computed. An example is the Restart transition in the root activity of the BA model.
3. Lessons Learned
The main result of our experiment at British Airways is the demonstration that process technology could reduce the gap between the process that is actually happening and the process described in the Infrastructure group's process handbook.
Experience of Technology Provider: A first concern was to assess the expressiveness for process automation of both the process modelling concepts of SLANG and its support environment SPADE. Through the BA experiment, we learned how complex process policies can be in industry. Policy implementation has an impact on tools, on the communication protocol between tools and on the process model fragment managing that protocol. This introduced additional complexity to the already complex process model. SLANG provides abstraction mechanisms that facilitated the hiding of complexity at the lower levels of the process model. For instance, activity SessionManager is completely independent from the access policy, which is hidden in the AccessControl activity and in the definition of owner data. However, industrial scale process modelling also requires high-level, easily combinable, process-oriented abstractions or building blocks, which are missing in SLANG.
People who were not involved in the process modelling experiment are little able to understand the enactable process model. Actually, this did not surprise us, since SLANG was initially conceived mainly to support process enactment. The BA experience showed, however, that it is important to provide different views, which may require different levels of abstraction, different ways of structuring the process model and different formalisms to express them. However, there are no satisfactory answers yet as to how such views may be kept consistent during modelling and enactment.
British Airways did not deploy the BA SEE developed in GOODSTEP. One of the reasons was that the impact of the deployment was too radical a change. The lessons that we have learned from this is that process technology adoption has to be done in an evolutionary rather than a revolutionary way and should focus on mature processes first. For the purpose of bringing process technology into industrial practice, it would have been more appropriate to start with partial process monitoring support which, for instance, provided context-sensitive process guidance on user demand, rather than support that attempted to completely controll and automate the process. After some period of technology assimilation and process maturation, it might have been possible to introduce process automation facilities and more advanced tools.
The enactment experience has shown that, during process model execution, the process engine is idle for most of the time. The engine works as a reactive system, which wakes up whenever a process relevant event occurs. This observation seems to support the argument that performance issues are not relevant in process engines. However, fine-grained tool integration implies that the process engine becomes active during interactions of users with tools. To avoid low user acceptance of such an environment, response time constraints below a second have to be met. Being a pre-commercial prototype, the BA SEE has very reasonable performance characteristics with response times between 0.5 and 2 seconds on a SparcStation-20. However, the environment would need to be re-engineered to be used as a commercial development environment in industrial applications. Much of the overhead introduced in the process engine execution is due to SPADE's evolution mechanism, which was not used in this experiment.
Experience of Technology Users: Much process understanding was gained through the process modelling process. The use of a formal process modelling language has lead to the removal of inconsistencies in the ``Official Process'', represented by Infrastructure's process handbook, and in the ``Observed Process'', represented by what process agents thought the actual process was. In addition, the modelling activity was accomplished in considerable detail in order to obtain an enactable process representation. This facilitated discussions on solid ground and prompted the removal of ambiguities in the process model.
The process modelling activity highlighted flaws in the process, offering an opportunity to improve the process. In some cases, the introduction of process technology naturally leads to changing the process during modelling. To a certain degree, this process improvement was achieved by the BA experiment. However, to reduce the risk inherent to the introduction of process technology, it is advisable to apply it to already stable and well understood processes.
Although process automation has initially been perceived as a fascinating idea, not all processes are amenable to complete automation. Automated processes are less adaptable to unforeseen situations and, as pointed out above, their execution may introduce some performance overhead. Thus, while established administrative processes are better suited to process automation, less clearly defined creative processes can only be supported by, for example, providing guidelines or help information on demand.
Footnotes: * This work has been partly funded by the CEC within ESPRIT-III project 6115 (GOODSTEP). The work was done while W. Emmerich was with University of Dortmund (Germany), S. Bandinelli was with CEFRIEL (Italy) and J. Arlow was with British Airways (UK)
| ISPA Homepage - This information last updated October 1997 |
| Copyright © 1996-7. All rights reserved. |
