=Paper= {{Paper |id=Vol-363/paper-15 |storemode=property |title=Assessing Business Processing Modeling Languages Using a Generic Quality Framework |pdfUrl=https://ceur-ws.org/Vol-363/paper15.pdf |volume=Vol-363 |dblpUrl=https://dblp.org/rec/conf/emmsad/NysetvoldK05 }} ==Assessing Business Processing Modeling Languages Using a Generic Quality Framework== https://ceur-ws.org/Vol-363/paper15.pdf
      Assessing Business Processing Modeling Languages
            Using a Generic Quality Framework

                        Anna Gunhild Nysetvold and John Krogstie

                       Norwegian University of Science and Technology,
                        Institute of Computer and Information Sciences
                        and SINTEF Telecom and Informatics, Norway.
                                      krogstie@idi.ntnu.no


       Abstract. We describe in this paper an insurance company that has recently
       wanted to standardize on business process modeling language. To perform the
       evaluation, a generic framework for assessing the quality of models and
       modeling languages was specialized to the needs of the company. Three
       different modeling languages were evaluated according to the specialized
       criteria.
         The work illustrates the practical utility of the overall framework, where
       language quality features are looked upon as means to enable the creation of
       models of high quality. It also illustrates the need for specializing this kind of
       general framework based on the requirements of the specific organization.



1 Introduction

There exists a large number of business process modeling languages. Deciding which
modeling language to use for a specific task is often done in an ad-hoc fashion by
different organizations. In this paper we present the work within an insurance
company, which have a perceived need for using process modeling to support the
integration of their business systems across different functions of the organization.
   We have earlier developed a general framework for assessment of quality of
models, where one type of means to support different quality goals, is criteria for the
language to be used for modeling, also termed language quality (Krogstie, 2001). This
paper presents an example of using and specializing the quality framework for the
evaluation and selection of a modeling language for enterprise process modeling for
the insurance company. The need for such specialization is grounded on work on
task-technology fit (Goodhue et al, 1995). A similar use of the framework for
comparing process modeling languages in an oil company has been reported in
(Krogstie and Arnesen, 2004). Although similar, we will see that due do different
overall goals of process modeling, the criteria derived from the quality framework
ended up different in the work reported in this paper. This is also due to that we in this
investigation have added aspects of organizational appropriateness of the approach.
1.1 The structure of this paper

The next section describes the quality framework, with a focus on language quality.
Section three describes the case in more detail, and is followed by the results of the
evaluation. The conclusion highlights some of our experiences from using and
specializing the quality framework for evaluating modeling languages for enterprise
modeling.


2 FRAMEWORK FOR QUALITY OF MODELS

The model quality framework (Krogstie, Lindland and Sindre 1995; Krogstie and
Sølvberg 2003; Krogstie 2001) is used as a starting point for the discussion on
language quality. We have taken a set-theoretic approach to the discussion of model
quality at different semiotic levels, which has been defined as the correspondence
between statements belonging to the following sets:
• G, the (normally organizationally defined) goals of the modeling task.
• L, the language extension, i.e., the set of all statements that are possible to make
   according to the graphemes, vocabulary, and syntax of the modeling languages
   used.
• D, the domain, i.e., the set of all statements which can be stated about the situation
   at hand.
• M, the externalized model.
• Ks, the relevant explicit knowledge of the set of stakeholders being involved in
   modeling. A subset of the audience is those actively involved in developing
   models, and their knowledge is indicated by KM.
• I, the social actor interpretation, i.e., the set of all statements which the audience at
   a given time thinks that an externalized model consists of.
• T, the technical actor interpretation, i.e., the statements in the model as 'interpreted'
   by different modeling tools.

The model quality types are defined as relations between these sets.
• Physical quality: The basic quality goals on the physical level are externalization,
  that the knowledge K of the domain D of some social actor has been externalized
  by the use of a modeling language, and internalizeability, that the externalized
  model M is persistent and available to the audience.
• Empirical quality deals with HCI-ergonomics for documentation and modeling-
  tools.
• Syntactic quality is the correspondence between the model M and the language
  extension L of the language in which the model is written.
• Semantic quality is the correspondence between the model M and the domain D.
  The framework contains two semantic goals; Validity which means that all
  statements made in the model are correct relative to the domain and completeness
  which means that the model contains all the statements which is found in the
  domain.
• Perceived semantic quality is the correspondence between the audience
   interpretation I of a model M and his or hers current knowledge K of D.
• Pragmatic quality is the correspondence between the model M and the audience's
   interpretation of it (I).
• The goal defined for social quality is agreement among audience members’
   interpretations I.
• The organizational quality of the model relates to that all statements in the model
   directly or indirectly contributes to fulfilling the goals of modeling (organizational
   goal validity), and that all the goals of modeling are being addressed through the
   model (organizational goal completeness).
   Language quality relates the modeling languages used to the other sets. It is
distinguished between two types of criteria:
                                                   Social actor
                                                     explicit
                                                   knowledge             Participant language
                                                       Ks                knowledge appropriateness



                        Modeller                                                 Social
                         explicit                Modelling Goal                   actor
                       knowledge                       G                     interpretation
                          Km                                                        I

                                                                    Organisational
                            Knowledge externalizability             appropriateness
                            appropriateness                                               Comprehensibility
                                                                                          appropriateness




            Modeling                                 Model                                     Language
            domain                               externalization                               extension
               D                                       M                                           L

                                                Domain appropriateness




                                                                                 Technical actor
                                                    Technical                      interpretation
                                                       actor                    appropriateness
                                                  interpretation
                                                        T


Fig. 1. Language quality related to the quality framework



As illustrated in Figure 1, six quality areas for language quality are identified:

Domain appropriateness
Ideally, the language must be powerful enough to express anything in the domain, i.e.
not having construct deficit (Wand & Weber, 1993). On the other hand, you should
not be able to express things that are not in the domain; i.e. what is termed construct
excess (Wand & Weber, 1993). The only requirement to the notation is that it is able
to represent all concepts in the language. Domain appropriateness is primarily a mean
to achieve physical quality, and through this, to be able to achieve semantic quality.
Participant language knowledge appropriateness
This area relates the knowledge of the stakeholder to the language. The conceptual
basis should correspond as much as possible to the way individuals perceive reality.
This will differ from person to person according to their previous experience, and thus
will initially be directly dependent on the stakeholder or modeler. On the other hand
the knowledge of the stakeholder is not static, i.e. it is possible to educate persons in
the use of a specific language. In that case, one should base the language on
experiences with languages for the relevant types of modeling, and languages that
have been used successfully earlier in similar tasks. Participant language knowledge
appropriateness is primarily a mean to help achieve physical and pragmatic quality.

Knowledge externalizability appropriateness
This area relates the language to the knowledge of the modeler. The goal is that there
are no statements in the explicit knowledge of the modeler that cannot be expressed in
the language. Knowledge externalizability appropriateness is primarily a mean to
achieve physical quality.

Comprehensibility appropriateness
This area relates the language to the social actor interpretation. For the concepts of the
language we have:
• The concepts of the language should be easily distinguishable from each other.
   (Vs. construct redundancy (Wand & Weber, 1993)).
• The number of concepts should be reasonable. If the number has to be large, the
   concepts should be organized hierarchically and/or in sub-languages of reasonable
   size linked to specific modeling tasks. or viewpoints.
• The use of concepts should be uniform throughout the whole set of statements that
   can be expressed within the language.
• The language must be flexible in the level of detail.
As for the notation, the following aspects are important:
• Symbol discrimination should be easy.
• It should be easy to distinguish which of the symbols in a model any graphical
   mark in the model is part of (What Goodman (1976) terms syntactic disjointness).
• The use of symbols should be uniform i.e. a symbol should not represent one
   phenomenon in one context and another one in a different context. Neither should
   different symbols be used for the same phenomenon in different contexts.
• One should strive for symbolic simplicity.
• One should use a uniform writing system: All symbols (at least within each sub-
   language) should be within the same writing system (e.g. non-phonological such as
   pictographic, ideographic, logographic, or phonological such as alphabetic).
• The use of emphasis in the notation should be in accordance with the relative
   importance of the statements in the given model
   Comprehensibility appropriateness is primarily a mean to achieve empirical and
through that, pragmatic quality.
Technical actor interpretation appropriateness
This area relates the language to the technical actor interpretation. For the technical
actors, it is especially important that the language lend itself to automatic reasoning.
This requires formality (i.e. both formal syntax and semantics. The formal semantics
can be operational, logical, or both), but formality is not sufficient, since the
reasoning must also be efficient to be of practical use. This is covered by what we
term analyzability (to exploit the mathematical semantics) and executability (to
exploit the operational semantics). Different aspects of technical actor interpretation
appropriateness are a mean to achieve syntactic, semantic and pragmatic quality
(through formal syntax, mathematical semantics, and operational semantics
respectively).

Organizational appropriateness
relates the language to standards and other organizational needs within the
organizational context of modeling. These are a mean to support organizational
quality.

A number of sub-areas are identified for each of the six areas of language quality, and
in (Østbø, 2000) approximately 70 possible criteria were identified. We will return to
how this extensive list has been narrowed down and specialized for the task at hand.


3 Description of the case and the evaluation approach

The insurance company in our case has a large number of life insurance and pension
insurance customers. The insurances are managed by a large number of systems of
different age and using different technology. The business processes of the company
go across systems, products and business areas, and the work pattern is dependant on
the system being used. The company has modernized its IT-architecture. The IT-
architecture is service-oriented, based on a common communication bus and an EAI-
system to integrate the different system. To be able to support complete business
processes in this architecture, there is a need for tools for development, evolution and
enactment of business processes.


Goals for business process modeling in the insurance company

Before discussing the needs of the case organization specifically, we outline the main
uses of enterprise process modeling. Five main categories for enterprise modeling
can be distinguished:
1. Human-sense making and communication: To make sense of aspects of an
   enterprise and communicate this with other people.
2. Computer-assisted analysis: To gain knowledge about the enterprise through
   simulation or deduction.
3. Business process management e.g. in connection to following up ISO-certification.
4. Model deployment and activation: To integrate the model in an information system
   and thereby make it actively take part in the work performed by the organization
5. To give the context for a traditional system development project, without being
   directly deployed and activated.

Company requirements
The main goal of the insurance company was related to the fifth area above, to give
the context for traditional systems development to support the integration of their
business systems across different functions of the organization, and at the same time
support human sense-making and communication (area 1). A general set of
requirements to a modeling language based on the discussion of language quality in
section 2 is outlined in (Østbø, 2000). These were looked at relative to the
requirements of the case organization, and their importance was evaluated. The
analysis together with the case organization resulted in the requirements in table 1.

Table 1. Overview of evaluation criteria


No          Requirement                                                      Type of

1.1      The language should support the following concepts              Domain
         (a) processes, that must be possible to decompose               appropriate
         (b) activities                                                  ness
         (c) actors/roles
         (d) decision points
         (e) flow between activities, tasks and decision points
1.2      The language should support                                     "
         (a) system resources
         (b) states
1.3      The language should support basic control patterns (van der     "
         Aalst, 2003)
1.4      The language should support advanced branching and              "
         synchronization patterns
1.5      The language should support structural patterns                 "
1.6      The language should support patterns involving multiple         "
         instances
1.7      The language must support state based flow patterns             "
1.8      The language must support cancellation patterns                 "
1.9      The language must include extension mechanisms to fit the       "
         domain
1.10     Elements in the process model must be possible to link to a     "
         data/information model
1.11     It must be possible to make hierarchical models                  “
2.1      The language must be easy to learn, preferably being based on   Participant
         a language already being used in the organization               language
                                                                         knowledge
                                                                         app.
2.2     The language should have an appropriate level of abstraction       “
2.3     Concepts should be named similarly as it is in the domain          “
2.4     The external representation of concepts should be intuitive to     “
        the stakeholders.
2.5     It should exist good guidelines for the use of the language        "
4.1     It must be easy to differentiate between different concepts        Comp.app.

4.2     The number of concepts should be reasonable                        “
4.3     The language should be flexible in precision                       "
4.4     It must be easy to differentiate between the different symbols     "
        in the language
4.5     The language must be consistent not having one symbol to           "
        represent several concepts, or more symbols that express the
        same concept.
4.6     One should strive for graphical simplicity                         “
4.7     It should be possible to group related statements                  “
5.1     The language should have a formal syntax                           Technical
                                                                           actor app.
5.2     The language should have a formal semantics                        “
5.3     It must be possible to generate BPEL –documents from the           “
        model
5.4     It must be possible to represent web-services in the model         “
5.5     The language should lend itself to automatic execution and         “
        testing
6.1     The language must be supported by tools that are either            Organizati
        already available or can be made easily available in the           onal app.
        organization
6.2     The language should support traceability between the process       “
        model and any automated process support system
6.3     The language should support the development of models that         “
        can improve the quality of the process.
6.4     The language should support the development of models that         “
        help in the follow-up of separate insurance cases


4 Evaluation

The overall approach to the evaluation was the following: First a short-list of relevant
languages was identified by us and the case organization in co-operation. The chosen
languages were then evaluated according to the selected criteria on a 0-3 scale. To
look upon this in more detail, all languages were used for the modeling of several real
cases from the insurance company using a modeling tool that could accommodate all
the selected languages (which in our case was METIS (Lillehagen, 1999)). By
showing the resulting models and evaluation results to persons from the company, we
got feedback and corrections both on the models and our grading. The models were
also used specifically to judge the participant language knowledge appropriateness
and comprehensibility appropriateness. We also received feedback from modeling
experts on the grading.
   Based on discussions with persons in the case-organization and experts on business
process modeling, three languages were selected for comparison. These will be briefly
described: For a longer description see the report (Nysetvold, 2004) and the cited
references.

EEML (Extended Enterprise Modeling Language) (EXTERNAL, 1999) was
originally developed in the EU-project EXTERNAL as an extension of APM
(Carlsen, 1997), and has been further developed in the EU projects UEML and
ATHENA. The language has constructs to support all modeling categories described
above.
    The following main concepts are provided:
• Task with input and output ports (which are specific types of decision-points)
• General decision-points
• Roles (Person-role, Organization-role, Tool-role, Object-role)
• Resources (Persons, Organizations and groups of persons, Tools (manual and
    software), Objects (material and information)
    A flow links two decision points and can carry a resource. A task has several parts:
An in-port and an out-port, and potentially a set of roles and a set of sub-tasks. Roles
'is filled by' resources of the corresponding types. In addition EEML contains
constructs for goal modeling, organizational modeling and data-modeling.

UML 2.0 activity-diagrams (Fowler, 2004)
  An activity-diagram can have the following symbols
• Start,
• End,
• Activity,
• Flow (between activities, either as control or as object-flows),
• Decision-points,
• Roles using swimlanes
  In addition, a number of constructs is provided to support different kinds of
control-flows.

BPMN (BPMN, 2005) is a notation aiming to be easily understandable and usable to
both business users and technical system developers. It also tries to be formal enough
to be easily translated into executable code. By being adequately formally defined, it
is meant to create a connection between the design and the implementation of
business processes.
   BPMN defines Business Process Diagram (BPD), which can be used to create
graphical models especially useful for modeling business processes and their
operations. It is based on a flowchart technique - models are networks of graphical
objects (activities) with flow controls between them.
   The four basic categories of elements are:
• Flow Objects
• Connecting Objects
• Swimlanes
• Artifacts (not included here)


Overview of evaluation results

Below the main result of the evaluation is summarized. For every language, every
requirement is scored according to the below scale on 0-3 (earlier evaluations of this
sort (Krogstie and Arnesen 2004) have used a 1-10 scale)

Table 2. Grading scale


Grade       Explanation
0           There is no support of the requirement
1           The requirement is partly supported
2           There is satisfactory support of the requirement
3           The requirement is very well supported

   The reasoning behind the grading can be found in (Nysetvold, 2004), and is not
included here due to space limitations. Table 3 gives an overview of the results. The
last three rows summarize the results.

Table 3. Comparison table with all the evaluations collected


                                                                 Grading of languages
No.      Requirement description                               UML BPMN EEML
                                                               AD
1.1      Listed concepts                                       3      3         3
1.2      Listed concepts                                       2      2         3
1.3      Basic control patterns                                3      3         3
1.4      Advanced branching and synchronization                0      0,5       3
         patterns
1.5      Structural patterns                                   0      1,5     1,5
1.6      Patterns involving multiple instances                 1,5    1,5     2
1.7      State based flow patterns                             1      1       2
1.8      Cancellation patterns                                 3      3       3
1.9      Extension mechanisms to fit the domain                3      1       1
1.10     Elements in the process model must be                 3      1       3
         possible to link to a data/information model
1.11     Hierarchical models                                   3      3       3
2.1      The language must be easy to learn,                   2      3       1
         preferably being based on a language
         already being used in the organization
2.2     Appropriate level of abstraction                 3         3         3
2.3     Concepts should be named similarly as it is      1         3         2
        in the domain
2.4     Intuitive representation to the stakeholders     2         2         2
2.5     Good guidelines for the use of the language      2         2         1
4.1     Easy diff. between different concepts            3         3         2
4.2     Number of concepts should be reasonable          3         3         1
4.3     The language should be flexible in precision     1         2         3
4.4     Easy to differentiate between the different      2         2         1
        symbols in the language
4.5     The language must be consistent.                 3         3         3
4.6     One should strive for graphical simplicity       3         2         1
4.7     Grouping of related statements                   1         1         2
5.1     The language should have a formal syntax         3         3         3
5.2     Formal semantics                                 1         3         2
5.3     Generate BPEL –documents from the model          2         3         0
5.4     Represent web-services in the model              1         3         1
5.5     Automatic execution and testing                  1         3         2
6.1     The language must be supported by                3         3         1
        available tools.
6.2     Traceability between the process model and       2         3         1
        any automated process support system
6.3     Models that can improvement the quality of       1         1         1
        the process.
6.4     The language should support                the   1         1         2
        development of models that help in the
        follow-up of separate cases
        Sum                                              63,5      72,5      63,5
        Sum         without       technical      actor   55.5      57,5      55,5
        appropriateness
        Sum without participant language                 53,5      59,5      53,5
        knowledge appropriateness

None of the languages satisfies all the requirements, but BPMN is markedly better
overall. With 72.5 points BPMN scores 75% of maximum score, whereas the others
score around 66%.
   BPMN has the highest score in all categories, except for domain appropriateness,
which is the category with highest weight, due to the importance of being able to
express the relevant business process structures. EEML is found to have the best
domain appropriateness, but loses to BPMN on technical actor appropriateness and
participant knowledge appropriateness.
   Comprehensibility appropriateness is the category which has the second highest
weight, since the organization regards it to be very important that it is possible to use
the language across the different areas of the organization, to improve communication
between the IT-department and the business departments. In this category BPMN and
Activity diagrams scores the same, which is not surprising given that they use the
same kind of swimlane metaphor as a basic structuring mechanism. EEML got a
lower score, primarily due to the graphical complexity of some of the concepts,
combined with the fact that EEML has a larger number of concepts than the others.
    Participant language knowledge appropriateness and technical actor
appropriateness was scored equally high, and BPMN score somewhat surprisingly
high on both areas. When looking at the evaluation not taking technical actor
appropriateness into account, we see that the three languages score almost equal. Thus
it is in this case the focus towards the relevant implementation platforms (BPEL and
web services) that in this case is putting BPMN on top. On the other hand, we see that
this focus on technical aspect do not destroy for the language as a communication tool
between people, at least not as it is regarded in this case.
    In the category organizational appropriateness, BPMN and Activity diagrams score
almost the same. The organization had for some time used activity diagrams, but it
also appeared that tools supporting BPMN was available for the organization. The
organization concluded that it wanted to go forward using BPMN for this kind of
modeling in the future.


5 Conclusions and further work

We have in this paper described the use of a general framework for discussing the
quality of models and modeling languages in a concrete case of evaluating business
process modeling languages.
   The case illustrates how our generic framework can (and must) be specialized to a
specific organization and type of modeling to be useful, which it was also found to be
by the people responsible for these aspects in the case organization. In an earlier use
of the framework, with a different emphasis, UML activity diagrams got a much
higher score than EEML, whereas here, they scored equally. (Krogstie and Arnesen,
2004).
   It can be argued that the actual valuation is somewhat simplistic (flat grades on a 0-
3 scale that is summarized). On the other hand, different kinds of requirements are
weighted since the number of criteria in the different categories is different. An
alternative to flat grading is to use pair-wise comparison and AHP on the alternatives
(Krogstie, 1999). The weighting between expressiveness, technical appropriateness,
organizational appropriateness and human understanding can also be discussed. For
later evaluations of this sort, we would like to use several variants of grading schemes
to investigate if and to what extent this would impact the result.
   This said, we should not forget that language quality properties are never more
than means for supporting the model quality (where the modeling task typically has
specific goals on its own). Thus instead of only evaluating modeling languages
'objectively' on the generic language quality features of expressiveness and
comprehension, it is very important that these language quality goals are linked to
model quality goals to more easily adapt such a generic frameworks to the task at
hand. This is partly achieved by the inclusion of organizational appropriateness,
which is not used in earlier work applying the framework. The evaluation results are
also useful when a choice has been made, since those areas where the language does
not score high can be supported through proper tools and modeling methodologies.


REFERENCES

W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros (2003).
   Workflow patterns. In Distributed and Parallel Databases, pages 5–52.
BPMN (2005) Business Process Modeling Notation. http://www.bpmn.org , last visited 12/3-
   2005
Carlsen, S. (1997). Conceptual Modeling and Composition of Flexible Workflow
   Models.unpublished Ph.D.-thesis Information Systems Group, Department of Computer and
   Information Science, Faculty of Physics, Informatics and Mathematics, Trondheim, Norway,
   NTNU - Norwegian University of Science and Technology.
EXTERNAL (1999) EXTERNAL - Extended Enterprise Resources, Networks And Learning,
   EU Project, IST-1999-10091, New Methods of Work and Electronic Commerce, Dynamic
   Networked Organizations. Partners: DNV, GMD-IPSI, Zeus E.E.I.G., METIS, SINTEF
   Telecom and Informatics, 2000-2002.
Fowler, M. (2004) UML Distilled: A Brief Guide to the Standard Object Modeling Language,
   third edition, Addison-Wesley
Goodhue, D. and Thompson, R. (1995) Task-Technology Fit and Individual Performance, MIS
   Quarterly June.
Goodman, N. (1976). Languages of Art: An Approach to a Theory of Symbols. Hackett,
   Indianapolis
Krogstie, J., Lindland, O.I., & Sindre, G. (1995). Defining Quality Aspects for Conceptual
   Models. In E. D. Falkenberg, W. Hesse, & A. Olive (Eds.). Proceedings of the IFIP8.1
   working conference on Information Systems Concepts (ISCO3); Towards a consolidation of
   views, March 28-30 (pp. 216-231), Marburg, Germany.
Krogstie, J. (1999). Using Quality Function Deployment in Software Requirements
   Specification. In A. L. Opdahl, K. Pohl, & E. Dubois. Proceedings of the Fifth International
   Workshop on Requirements Engineering: Foundations for Software Quality (REFSQ’99),
   June 14-15, (pp. 171-185), Heidelberg, Germany.
Krogstie, J. (2001) Using a Semiotic Framework to Evaluate UML for the Development of
   Models of High Quality in Unified Modeling Language: Systems Analysis, design, and
   Development Issues. K. Siau and T. Halpin, IDEA group.
Krogstie, J. & Sølvberg, A. (2003) Information Systems Engineering: Conceptual Modeling in
   a Quality Perspective, Kompendiumforlaget, Trondheim, Norway.
Krogstie, J. and S. Arnesen, (2004) Assessing Enterprise Modeling Languages using a Generic
   Quality Framework, in Information Modeling Methods and Methodologies, J. Krogstie, K.
   Siau, and T. Halpin, Editors. 2004, Idea Group Publishing.
Lillehagen, F. Visual Extended Enterprise Engineering Embedding Knowledge Management,
   Systems Engineering and Work Execution, IEMC '99, IFIP International Enterprise
   Modeling Conference, Verdal, Norway, 1999.
Nysetvold, A. G. Prosessorientert IT-arkitektur, Project Thesis (In Norwegian), IDI, NTNU,
   November 2004.
Wand, Y. & Weber, R. (1993). On the Ontological Expressiveness of Information Systems
   Analysis and Design Grammars. Journal of Information Systems 3(4), 217-237.
Stephen A. White: Introduction to BPMN. IBM Corporation, 2004.
Østbø, M. (2000). Anvendelse av UML til dokumentering av generiske systemer (In
   Norwegian). unpublished Master Thesis Høgskolen i Stavanger, Norway, 20 June.