Technology Profile: Automatic Support for Enterprise Modelling and Workflow

Web homepage:
Author: Dr. Yun-Heh (Jessica) Chen-Burger
Owner: Yun-Heh Chen-Burger and The University of Edinburgh
Affiliation: AIAI, CISA, Informatics, The University of Edinburgh
Addresses KM Challenge(s): Knowledge Acquisition, Modelling, Sharing and Reuse, and Maintenance
Builds on other technologies: KBST-BM, KBST-EM, Ontologies, Prolog, IBM Business Modelling Method, IDEF3, IDEF0, PIF, PSL, Organisational Modelling Methods, Case Based Reasoning, Knowledge Representation and Engineering.

What's the Problem?

Towards a Solution

Providing a Holistic Support Framework for Informal Modelling Activities

We propose a holistic support modelling framework to assist informal modelling that may be applied throughout the design-build-test-refine-use lifecycle. The framework is under-pinned by formal methods and illustrated in Figure 1.

                            Figure 1: A Holistic Support Framework for Informal Modelling Activities

To support the building of an enterprise model, an iterative cycle of knowledge-based support may be provided. KBST-EM is a generic modelling system that has been built on top of Hardy - a programmable hypertext diagram tool that has been built in AIAI. Below is a list of example support facilities that are provided by KBST-EM (Knowledge Based Support Tool for Enterprise Modelling) and a workflow engine:

Currently, 29 different modelling methods are supported by the KBST-EM and around 40 models are stored in the KBST-EM. Under the AKT project, two new methods were devised, AKT research map [3] and FBPML [5][8][9] and five new models have been developed. In KBST-EM, all modelling methods are supported with generic knowledge based support, some of them also have method-specific facilities.  

Figure 2 is a screen shot of KBST-EM. It shows a part of the ontology that has been used in the application domain of PC Configuration that is a part of the AKT work item: KRAFT-IX TIE (see KRAFT-IX TIE technology profile web page for more details [12]).

                   Figure 2: Partial Ontology in the PC Configuration domain (screen shot from KBST-EM)

Figure 3 shows another screen shot of KBST-EM which is part of a process model. This process model is written in FBPML (Fundamental Business Process Modelling Language) that has been developed as a part of AKT.

                                 Figure 3: Process Model for PC Configuration Application (screen shot from KBST-EM)

Knowledge Sharing and Inconsistency Checking between Multiple Models

To support knowledge sharing and improve consistency between models, an ontological mapping framework has been devised to enable the mapping between primitives of different modelling methods and concepts that have been captured in different models. Figure 4 shows an ontology based framework that shows how knowledge may be shared between different models.[4]

Figure 4: A common ontology captures the concepts that are being shared between different models

Figure 5 gives an example where the same or similar information has been captured in different types of models, i.e. in the process, data and business-oriented models. In this example, and through the use of the underlying shared ontology, it was derived that D1, D1' and D1'' are compatible, and that O1, O1' and O1'' are compatible. These shared common knowledge can be used to provide a basis for exercising consistency checking in different models.

For instance, in the model (a), D1 is an output of Process 1 that is followed by Process 2. Upon finishing the execution of Process 1, Process 2 takes D1 as an input and generates O1 as an output. In other words, model (a) specifies the existence of O1 is depended upon the existence of D1. On the other hand, model (b) indicates that the existence of O1' is depended upon the existence of D1'. This dependency is illustrated through the total participation relation of Rel'. As independently, through the underlying ontology we already know that D1 is compatible/the same to D1', and that O1 is compatible/the same to O1', we can say that the above relations that have been defined in the two models are consistent. Inconsistencies however may occur if model (b) defined that D1' is required to be total participated in O1'. 

This consistency checking technique is based upon the knowing of the meta-knowledge of modelling primitives used by the different models involved and the mapping of the underlying domain ontology that the models based upon. The matching approach for similar concepts in the domain was described in Figure 4. When consistency checking activities are repeatedly applied, the similar parts of different models can be mapped with each other and errors found. 

Figure 5: The same and similar information are often captured in different types of models, but described in different format 

Support for Workflow System development: From design of process models to generation of workflow systems

Figure 3 gave a graphical description of a process model using FBPML notation [5][8][9]. Since FBPML has declarative execution semantics for processes, process models written in FBPML give precise instructions for implementing a workflow system. Given a set of workflow functions that implement the corresponding components that are included in the FBPML process model, a workflow engine interprets the process model (against dynamics in the world) and invokes the appropriate functions for execution. Figure 6 gives the overall architecture of a workflow engine. More details are given in [8].

Figure 6: Overall Architecture of Workflow Engine

Take a Guided Tour

Example Applications

Further Readings

Example Key documents

Other relevant documents