On the architecture and form of flexible process support R.A. Snowdon1, B.C. Warboys1, C.Holland2, P. Kawalek2 and D.R. Shaw3 1
School of Computer Science, University of Manchester, Oxford Road, Manchester M13 9PL, UK rsnowdon,
[email protected] 2 Manchester Business School, University of Manchester, Booth Street West, Manchester M15 6PB, UK chris.holland,
[email protected] 3 Nottingham University Business School, Jubilee Campus, Nottingham NG8 1BB, UK
[email protected]
Abstract.
Businesses may be described as holistic systems of interacting processes. Beer’s Viable System Model is a complete formulation of such a set of processes necessary for a business to be sustainable in a volatile, changing environment. The Viable System Model can be used to describe a process architecture for the IT capabilities required to support a sustainable business. This paper explores this idea by applying it to a supply chain scenario using a reflective process enactment environment.
1
Introduction
The need for businesses to be flexible derives from the increasingly volatile nature of the business environment. Flexibility is “…the ability of a firm's processes and systems to respond quickly to changes in the business environment. It includes the capacity to accommodate shifts in consumer demand, in competitors' strategies, in rate of growth, and in suppliers' deals and shipment problems…” [1] Flexibility is inexorably linked to control. Business seeks to limit change because this lessens the problems of control. Experience shows that pressure for change will eventually emerge. Organisations which are prepared for change can maintain control over changing situations. Flexibility is categorised in [2] in terms of 1. type flexibility - arising from the variety of information 2. volume flexibility - arising from the amounts of information 3. structural flexibility - arising from the need to operate in different ways Using a scenario, this paper1 explores the relationship between a model of systems viability in the context of change (the VSM) and the architecture of IT support for businesses, developing concepts described in [3 and 4].
2
Modelling and the VSM
The notion of “IT as an active model” represents a systemic approach to the use of IT in business. The business and its supporting IT are considered as co-evolving systems. As the business system changes the IT system reacts to keep in step. In turn the behaviour of the IT system provides stimuli (e.g. as information, as constraints) to the business system (figure 1). This model embraces all of the different facets of business as a system, importantly including the development of the business itself.
1
This work was supported by the UK EPSRC under grants GR/S15914/01 and GR/S15921/01, project entitled Flexible Business Integration (FBI).
business system reaction
an effective system
proaction IT system active model
Fig. 1. The IT supporting a business system is an active model related by reaction and proaction.
The Viable System Model (VSM) (developed by Stafford Beer, e.g. [5]) describes the behaviours required of a system for it to be sustainable. The VSM distinguishes between behaviours concerned with fulfilling the business purpose (operational behaviours) and behaviours concerned with determining purpose and how it is fulfilled (meta behaviours). The usual schematic of the VSM is shown in figure 2 demonstrating its recursion.
5 Meta-system
Environment
4
3
3*
2
1
2
1
Fig. 2. The Viable System Model.
Each system comprises six sub-behaviours labelled S1, S2, S3, S3*, S4 and S5. S1 represents the operational behaviours of the system and is the site of the recursion. S2, S3 and S3* represent different meta behaviours concerned with managing the component S1s. S4 deals with the future, representing behaviours which interact with the environment for future options and with the existing system to understand the present. S5 is a policy system whereby the interaction between S4, S5 and S3 determines future behaviours for the whole. A simplified representation of the VSM behavioural structure of a system is shown in figure 3. This figure is a POSD diagram [6]. In POSD a system is considered as a composition of interacting sub-
processes, each drawn as a rectangle. Interaction between processes is shown by rectangles “touching”. Ultimately, interaction is realised by shared processes. Thus the interaction between S5 and S4 will be realised ultimately by S5 and S4 sharing a common sub-process. In more complex diagrams touching is represented by a line linking the interacting processes (see figure 4) but the meaning is the same.
S5 S4
S3 S2 S3*
S1
Fig. 3. POSD archetype of the VSM.
One difficulty with a notation such as POSD is that it does not show the dynamics of the system. The dynamic behaviour of any process is the composition of its components which in turn is formed from further compositions. Whilst the notation captures the composition structure it needs to be augmented, usually by narrative, to explain the dynamics. Thus, in figure 3, further description is required to describe the control interaction between S3 and S1, or the smoothing interaction between S1 and S2. A VSM description of a system is one in which the subsystems behave together to maintain the viability of the whole. To do this the behaviours of each subsystem will change although the process structure will remain. In the VSM the meta subsystems (S2-S5), through their mutual behaviours, change the operational behaviours (S1) and also themselves. To formalise these behaviours a richer language is needed. In this paper we use PML. A model expressed in PML can be enacted as an active model using ProcessWeb [7]
3
An example
The scenario used is developed from one originally described by Herring and Kaplan [8] and concerns the behaviour of three fictional companies. • Muzak.com - a production company (a “factory”) making digital music titles. • Eshop.com - an e-retailer selling goods to customers. • B2b.com - a business broker, providing a business introduction service for companies seeking potential partners. Herring and Kaplan [8] examine a further role of B2b.com managing a contract established between partners. This function is not considered here. The scenario starts with the establishment of the three companies as independent systems, each able to carry out its own business. Both Eshop.com and Muzak.com are aware of B2b.com and have the means of interacting with B2b.com. Next both Eshop.com and Muzak.com register with B2b.com. In both cases this requires structural change because at the outset neither Eshop.com nor Muzak.com has the capability to perform such registration although each has the ability to interact with B2b.com. To make such a structural change requires that the registration capability can be added to each. This in turn implies that the systems must have the capability to do so; structural flexibility. Eshop.com then uses B2b.com to find a supply partner. This again requires structural changes to enable Eshop.com and Muzak.com to agree a business arrangement. Further changes are then required of both Eshop.com and Muzak.com to fulfil the deal. Muzak.com supplies “titles” to Eshop.com. Eshop.com sells “titles” to its customers and periodically pays Muzak.com for shipments. As a final stage Eshop.com terminates the deal with Muzak.com with the removal of supply capabilities and payment of final invoices. The scenario then repeats with Eshop.com and Muzak.com negotiating a new supply arrangement. In addition, any of the individual systems can make changes to themselves. For example, Muzak.com may choose to make new titles (type flexibility) or Eshop.com may decide to sell titles in “bulk” (volume flexibility).
The starting position is the POSD model shown in figure 4. This shows VSM structures for each of Muzak.com, B2b.com and Eshop.com linked through their S4 behaviours. Customer is described as a VSM structure, interacting with Eshop.com through their S1s. B2b.com S5 S3
S4
S2 S3*
S1
Muzak.com
Eshop.com
S5 S3
S5 S4
S4
S3 S2
S2 S1
S3*
S3
S1
Customer S5 S4
S3 S2 S3*
S1
Fig. 4. POSD model of start of scenario.
The interaction between Muzak.com[S4] and B2b.com[S4] concerns the former asking the latter about possible retail services. B2b.com[S4] is aware of Eshop.com[S4] and uses this interaction to determine possible interest. From these interactions Muzak.com and Eshop.com decide to enter into a business arrangement. Further POSD models could describe stages in the scenario.
4
Mapping to a BPS - an active model
The POSD models provide a basic architecture for an active model supporting B2b.com, Muzak.com and Eshop.com with its customers. The language used for such a model is PML, supported by the ProcessWeb infrastructure [7]. Models expressed in PML are composed of concurrent processes interacting through message channels, allowing a close mapping to the POSD description. A fragment of the scenario is used as an illustration. Eshop.com decides to use its link with B2b.com to establish a deal with a supplier. At this time the PML encoding of the S3 component of Eshop.com supports interactions with Eshop[S4] and Eshop[S5] to react to decisions for change, and normal management interaction with Eshop[S1]. The fragment concerns how support is provided once the decision to make a deal is decided. First a further sub-structuring is introduced. This maps each POSD process into a pair, (E,P), of interacting processes. The P element is responsible for the fulfilment of the purpose of the process. The E element is responsible for evolving the process either to improve it or to change what it does. Figure 5 illustrates this in the context of the wider S3/S1 relationship.
S3 S1 E P
E P
Fig. 5. Substructure of processes. The (E,P) pair.
Within S3, the E-P interaction is concerned with ensuring that the P element continues to fulfil its purpose. The interaction between S3_P and S1_E is concerned with the function of S3 to manage S1, which it does via S1_E. In the text below processes are identified by names such as EshopS3_P, the P component of the S3 component of Eshop. PML encodes processes as sub-classes of the principal class Role. Instances of class Role are single threaded processes with a set of local variables defined in a local name space using locally defined types. The process is described as a set of guarded code fragments. The set of variables plus the set of code fragments are together described as the properties of a process, each property individually named. The guards for code fragments are predicates over the set of properties. Processes communicate with other processes through channels each being an instance of the principle class Interaction. Actions are defined to put objects into and take objects from interactions, and to test for the presence of an object in an interaction. When the decision is taken to use B2b.com to suggest a supplier and then to set up a deal, EshopS3_P does not possess the required behaviours. It only possesses an interaction with which it can communicate with B2bS1_P and details of the form of such communication. New code must therefore be added to EshopS3_P to support the required behaviour. PML is reflective. Code can be written in PML to describe a process to change a currently defined and enacting process. Such a meta process can examine the present state of a component process, compile new code via a callable compiler and change the class membership of a component process from one subclass of Role to another, binding values to the changed instance as necessary. Thus new code can be compiled and used by an E component to change its companion P component. This capability is used, interacting with a person in the business, to change EshopS3_P so that it can support interaction with B2bS1_P and again to be able to support the arrangement of a deal with its chosen supplier. Once EshopS3_P is changed it will enact the changed process, interacting with MuzakS3_P (similarly changed) in order to establish a supply deal. After the deal is agreed, EshopS3_P and MuzakS3_P then make changes to the respective S1s to implement support for the operation of the deal. Figure 6 shows an illustrative screenshot of EshopS3_P obtaining new code to change EshopS1_P.
Fig. 6. Enacting process change. Compiling new code for EshopS1_P.
5
Issues and points of discussion
Systems to support flexible business behaviours can be considered as active models in which development of the business is mirrored by support for the development of the underlying IT system. The implementation described using the VSM provides a separation between the different concerns within a business and thence of its supporting IT. In particular the VSM provides means of determining an architecture appropriate to a flexible system by making a clean distinction between the operational components (the S1s) and the development components (the S3s). It should be noted that the VSM provides much greater richness than that which has been examined here. Active models can be thought of as a co-ordination layer [9] with some similarity to the concepts of orchestration and choreography [10]. PML possesses some important features for building such systems. The experience of its application in the scenario provides some illustrations of these features and also raises some issues. These include: • reflection. PML provides a callable compiler and operations to extract the state of a process object, to modify it and then restart the process object in a new class with modified properties. Thus the S3 change behaviour can be described in PML and enacted just as any other process. PML lacks the ability for a process to determine the type of object properties which causes problems in writing generic components. • hypercode. In general the development of new code is an interactive activity involving a human developer in the business component supported by the process in the active model. One significant problem using ProcessWeb/PML to do this is that of binding values from the process to be changed to the new process. The problem is that PML does not provide source representations of all the values it can support thus requiring additional code to be included in the change process. A more consistent approach is the idea of hypercode [11] whereby a representation of every runtime value is available at the code level. • inheritance. Although PML supports inheritance, experience shows potential problems related to the granularity of change (particularly with code properties). • development support. The capabilities provided by PML allow change to be supported. However, for service use they would need to be significantly enhanced, particularly to support understanding of the potential effect of changes. Some possibilities are being examined in the Archware project [12].
• open systems. If the system being changed is not closed (that is there are relevant parts of the system’s state in some external components) then the change process has to make assumptions about the state which may not be accurate. This requires “defensive” behaviours to be described in case the assumptions are wrong and, even so, may not be complete.
6
Postscript
Details of how to use ProcessWeb to explore the scenario can be obtained from the first named author, email
[email protected].
7
References
1. Retail Information Systems News (RIS), http://www.risnews.com/Glossary/glossary.html 2. Shaw, D. R., Holland, C. P., Kawalek, P., Snowdon, B., Warboys, B., “Electronic Commerce Strategy In The U.K. Electricity Industry: The Case of Electric Co and Dataflow Software”, Proceedings of the 12th European Conference on Information Systems, ECIS'04. 3. Snowdon R.A., “Active models and process support”, in: C. Montangero (Ed.), Software Process Technology, Proceedings of EWSPT’96, LNCS 1149, Springer, Berlin, 1996. 4. Snowdon B., Kawalek P., “Active meta-process models: a conceptual exposition”, Information and Software Technology 45 (2003) pages 1021-1029 5. Beer S., “Brain of the Firm, 2nd Edition”, Wiley, Chichester, 1981 6. Henderson P., Pratten G.D.,, “POSD, a notation for presenting complex systems of processes”, First IEEE Conference on Engineering of Complex Systems, Florida, November 1995. 7. Yeomans B.S., “A process-based environment for the evolutionary development of large software systems” MRes Thesis, University of Manchester 1997. 8. Herring C., Kaplan S., “The Viable System Architecture”, Proceedings of the 34th Hawaii International Conference on System Sciences, IEEE, 2003 9. Warboys B.C., Kawalek P.J., Robertson I., Greenwood R.M., “Business Information Systems: a Process Approach”. McGraw-Hill, 1999 10. Peltz C., “Web Services Orchestration and Choreography”, Hewlett Packard, July 2003, from www.wsj2.com 11. Kirby G.N.C., Connor R.C.H., Cutts Q.I., Dearle A., Farkas A.M., Morrison R, “Persistent Hyper-Programs”, in “Persistent Object Systems, Workshops in Computing”, Albano A., Morrison R., Eds.: Springer-Verlag, pp. 86-106, 1992 12. Morrison R., Kirby G., Balasubramaniam D., Mickan K., Oquendo F., Cîmpan S., Warboys B.C., Snowdon B., Greenwood R. M., “Support for Evolving Software Architectures in the ArchWare ADL”, WICSA’04 - Fourth IEEE/IFIP Conference on Software Architecture
