# Evolution of an Enterprise Modeling Method – Next Generation Improvements of EKD

Janis Stirna, Anne Persson

► To cite this version:

Janis Stirna, Anne Persson. Evolution of an Enterprise Modeling Method – Next Generation Improvements of EKD. 5th Working Conference on the Practice of Enterprise Modeling (PoEM), Nov 2012, Rostock, Germany. pp.1-15, 10.1007/978-3-642-34549-4_1 . hal-01484385

HAL Id: hal-01484385

https://inria.hal.science/hal-01484385

Submitted on 7 Mar 2017

**HAL** is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Evolution of an Enterprise Modeling Method – Next Generation Improvements of EKD

Janis Stirna¹, Anne Persson²

¹Department of Computer and Systems Sciences, Stockholm University, Forum 100, SE-1644 0, Kista, Sweden
js@dsv.su.se

²University of Skövde, Informatics Research Centre, P.O. Box 408, SE-541 28 Skövde, Sweden
anne.persson@his.se

**Abstract.** The field of Enterprise Modeling (EM) consists of many methods and method development is one of the key activity areas of EM practitioners and researchers. This paper ponders on future improvements for one EM method, namely Enterprise Knowledge Development (EKD). A number of improvements to the EKD method are identified and discussed, based on empirical observations. The improvements fall into four categories: the modeling language, the modeling process, tool support, and other improvements. The paper can be seen as a step towards a new and improved version of EKD.

**Keywords.** Enterprise Modeling, Enterprise Modeling method, method evolution

## 1 Introduction

Enterprise Modeling (EM) is a process where an integrated and negotiated model describing different aspects of an enterprise is created. In [1] and [2] we have argued that EM usage is heavily influenced by a large number of situational factors, one of which is the intention behind its use. Knowledge about the purpose of a particular EM venture is essential when making decisions about which modeling language, way of working, tool support etc. is appropriate. It is important to bear in mind that organizations do not use EM methods only for the sake of using methods. They want to solve a particular business problem and EM is only one of several instruments in the problem solving process. In [1] and [2] we have stated that EM projects usually have the following purposes:

- *To develop the business.* This entails, e.g., developing business vision, strategies, redesigning business operations, developing the supporting information systems, etc. Business development is one of the most common purposes of EM. It frequently involves change management – determining how to achieve visions and objectives from the current state in organizations. Business process orientation is
a specific case of business development – the organization wants to restructure/redesign its business operations.

- *To ensure the quality of the business operations.* This purpose primarily focuses on two issues: 1) sharing the knowledge about the business, its vision, and the way it operates, and 2) ensuring the acceptance of business decisions through committing the stakeholders to the decisions made. A motivation to adopt EM is to ensure the quality of operations. Two important success factors for ensuring quality are that stakeholders understand the business and that they accept/are committed to business decisions. Recently, organizations have taken an increased interest in Knowledge Management (KM), which concerns creating, maintaining and disseminating organizational knowledge between stakeholders. Sharing business knowledge becomes instrumental when organizations merge or collaborate in carrying out a business process. One aspect of this is terminology. EM has a role to play here as it aims to create a multifaceted “map” of the business as a common platform for communicating between stakeholders. One KM perspective is keeping employees informed with regard to how the business is carried out. Most modern organizations consider that the commitment of stakeholders to carry out business decisions is a critical success factor for achieving high quality business operations. Differences in opinion about the business must hence be resolved, requiring that communication between stakeholders be stimulated. EM, particularly using a participative approach, can be effective to obtain such commitment.

- *To use EM as a problem solving tool.* EM is here only used for supporting the discussion among a group of stakeholders trying to analyze a specific problem at hand. In some cases making an EM activity is helpful when capturing, delimiting, and analyzing the initial problem situation and deciding on a course of action. In such cases EM is mostly used as a problem solving and communication tool. The enterprise model created during this type of modeling is used for documenting the discussion and the decisions made. The main characteristics of this purpose are that the company does not intend to use the models for further development work and that the modeling activity has been planned to be only a single iteration. In some cases this situation changes into one of the other EM purposes because the organization sees EM as beneficial or the problem turns out to be more complex than initially thought and more effort is needed for its solution.

EM usually is organized in the form of a project or it is a part of a larger, e.g. organizational or information system (IS) development, project. The resulting models, however, might be used on a more permanent basis e.g. during run-time of an IS or for knowledge management purposes.

In this paper we focus on a particular EM method, Enterprise Knowledge Development (EKD) [3]. Both authors of the paper have been involved in developing and using its previous and current versions since the beginning of the 1990-ies. We firmly believe that it is essential that method developers from time to time critically assess their method/s, take potential improvements into consideration and consequently develop a new and improved version of the method.

The goal of the paper is to identify and discuss next generation improvements to the EKD method, based on empirical observations. The improvements fall into four categories: 1) the modeling language, 2) the modeling process, 3) tool support, and 4)
other improvements. Hence, the paper is a step towards a new and improved version of EKD.

The remainder of the paper is organized as follows. Section 2 describes the research method while section 3 introduces the EKD EM method in its recent version. Section 4 presents the potential developments in terms of the EKD's modeling language, while section 5 focuses on how the proposed modeling process of EKD can be improved. Section 6 addresses requirements for tool support and section 7 outlines some other possible directions for improvement of EKD. The paper ends with some concluding remarks in section 8.

## 2 Research Approach

The empirical sources of this paper are:

* Extensive fieldwork applying versions of EKD to a variety of problems,

* Interview studies involving experienced EM consultants and method developers.

The most influential fieldwork cases were, for the most part, carried out within international research projects financed by the European Commission. An overview of the cases is given in Table 1. The applications that contributed to this paper took place in the years 1993-2008. Their processes and their outcomes were observed and analyzed. Collected data and experiences from method development, fieldwork and interviews were analyzed. Two interview studies focusing on the intentional and situational factors that influence participatory EM and EM tool usage as reported in [1] and [4] were also carried out. A more extensive presentation of these cases is available in [5]. In addition, EKD and its earlier versions have been used in a number of smaller problem solving and organizational design cases at many organizations in Sweden and Latvia.

<table><caption>**Table 1.** Overview of main application cases</caption><thead><tr><th>Organization</th><th>Domain</th><th>Period</th><th>Problems addressed</th></tr></thead><tbody><tr><td>British Aerospace, UK</td><td>Aircraft development and production</td><td>1992-1994</td><td>Requirements Engineering</td></tr><tr><td>Telia AB, Sweden</td><td>Telecommunications industry</td><td>1996</td><td>Requirements validation<br>Project definition</td></tr><tr><td>Volvo Cars AB, Sweden</td><td>Car manufacturing</td><td>1994-1997</td><td>Requirements engineering</td></tr><tr><td>Vattenfall AB, Sweden</td><td>Electrical power industry</td><td>1996-1999</td><td>Change management, Process development,<br>Competence management</td></tr><tr><td>Riga City Council, Latvia</td><td>Public administration</td><td>2001-2003</td><td>Development of vision and supporting<br>processes for knowledge management</td></tr><tr><td>Verbundplan GmbH, Austria</td><td>Electrical power industry</td><td>2001-2003</td><td>Development of vision and supporting<br>processes for knowledge management</td></tr><tr><td>Skaraborg Hospital, Sweden</td><td>Health care</td><td>2004-2007</td><td>Capturing knowledge assets and development<br>of a knowledge map of a knowledge<br>repository.</td></tr><tr><td>SYSteam AB, Sweden</td><td>Management consulting</td><td>2008</td><td>Development of a vision for an employee<br>knowledge management portal</td></tr></tbody></table>
The application context if these cases have been change management – the organizations have had intentions to either develop new solutions to their business problems or to improve the efficiency of the existing once. All these projects have applied the participatory approach to EM involving one or two modeling facilitators. There have been projects with more than 30 EM sessions (e.g. at Vattenfall and Riga City Council) involving people from all management levels as well as from operational levels. There have also been projects where the modeling has been limited to a few (2-4) modeling sessions with top and middle level management (e.g. at Verbundplan and SYSteam). Most of the modeling participants did not have any prior training with EKD, but some of them were experienced with other Conceptual Modeling methods

Empirical data from modeling activities of the above mentioned types were documented as written notes and analyzed. In addition, interviews with EM practitioners about EM practice were transcribed and analyzed using Grounded Theory [6] data analysis. The data and analyses have then been used as input for a series of argumentative syntheses targeting:

1. Requirements on EM related to the purposes of using EM, reported in [2],

2. Core competencies of an EM practitioner, reported in [7], and

3. The relationship between core competencies and the purposes of EM, reported in [8].

The goal of this series of analyses has been to establish a line of research that addresses different aspects of EM from a purpose and situational perspective.

Throughout the research process we have also reflected on the advantages and drawbacks of the EKD EM method as related to different purposes, in particular when analyzing the requirements that different purposes pose on an EM method. Most relevant to this paper are the requirements on the *modeling language, modeling process and tool support*.

Hence, the results from these analyses in combination with our general knowledge about the field of EM have guided the identification of a number of potential improvements to the EKD method.

## 3 The EKD Enterprise Modeling Method – History and Current State

In Scandinavia, methods for Business or Enterprise Modeling (EM) were initially developed in the 1980-ies by Plandata, Sweden [9] and later refined by the Swedish Institute for System Development (SISU). A significant innovation in this strand of EM was the notion of business goals as part of an Enterprise Model, enriching traditional model component types such as entities and business processes. The SISU framework was further developed in the ESPRIT projects F3 – “From Fuzzy to Formal” and ELEKTRA – “Electrical Enterprise Knowledge for Transforming Applications”. The current framework is denoted EKD – “Enterprise Knowledge Development” [3]. The method is, hence, a representative of the Scandinavian strand of EM methods.
In our view, an EM method is more than a modeling language. An EM method has an intended process - including ways of working, EM project management and competency management - by which the enterprise models are produced. It also proposes which tools should be used during that process.

## 3.1 The EKD modeling language

EKD – Enterprise Knowledge Development method [3] is a representative of the Scandinavian strand of EM methods. It defines the modeling process as a set of guidelines for a participative way of working and the modeling product in terms of six sub-models, each focusing on a specific aspect of an organization (see table 2).

The modeling components of the sub-models are related between themselves within a sub-model (intra-model relationships), as well as with components of other sub-models (inter-model relationships). Figure 1 shows inter-model relationships. The ability to trace decisions, components and other aspects throughout the enterprise is dependent on the use and understanding of these relationships. For instance, statements in the GM need to be defined more clearly as different concepts in the CM. A link is then specified between the corresponding GM component and the concepts in the CM. In the same way, goals in the GM motivate particular processes in the BPM. The processes are needed to achieve the goals stated. A link therefore is defined between a goal and the process. Links between models make the model traceable. They show, for instance, why certain processes and information system requirements have been introduced.

<table><caption>**Table 2.** Overview of the sub-models of the EKD method [10]</caption><thead><tr><th></th><th>Goals Model (GM)</th><th>Business Rules Model (BRM)</th><th>Concepts Model (CM)</th><th>Business Process Model (BPM)</th><th>Actors and Resources Model (ARM)</th><th>Technical Component & Requirements Model(TCRM)</th></tr></thead><tbody><tr><th>Focus</th><td>Vision and strategy</td><td>Policies and rules</td><td>Business ontology</td><td>Business operations</td><td>Organizational structure</td><td>Information system needs</td></tr><tr><th>Issues</th><td>What does the organization want to achieve or to avoid and why?</td><td>What are the business rules, how do they support organization's goals?</td><td>What are the things and "phenomena" addressed in other sub-models?</td><td>What are the business processes? How do they handle information and material?</td><td>Who are responsible for goals and process? How are the actors interrelated?</td><td>What are the business requirements to the IS? How are they related to other models?</td></tr><tr><th>Components</th><td>Goal, problem, external constraint, opportunity</td><td>Business rule</td><td>Concept, attribute</td><td>Process, external proc., information set, material set</td><td>Actor, role, organizational unit, individual</td><td>IS goal, IS problem, IS requirement, IS component</td></tr></tbody></table>

While different sub-models address the problem domain from different perspectives, the inter-model links ensure that these perspectives are integrated and provide a complete view of the problem domain. They allow the modeling team to assess the business value and impact of the design decisions. There are two alternative approaches to notation in EKD: (1) A fairly simple notation, suitable when the domain stakeholders are not used to modeling and the application does not require a high degree of formality and (2) a semantically richer notation, suitable when the application requires a higher degree of formality and/or the stakeholders are more
experienced with modeling. The modeling situation at hand should govern the choice of notation, which will be shown in the subsequent discussion about the method. The full notation of EKD can be found in [3].

## 3.2 The EKD Modeling Process

In order to achieve high quality results, the modeling process is equally important as the modeling language used. There are two levels of EM process – the EM project level and the modeling level.

*The EM project level*, where the modeling activities are placed in a context of purpose. In [7] we described the generic process including the activities listed in Table 3.

<table><caption>**Table 3.** Activities in EM (adapted from [7])</caption><tr><td>Define scope and objectives of the modeling project</td></tr><tr><td>Plan for project activities and resources</td></tr><tr><td>Plan for modeling session</td></tr><tr><td>Gather and analyze background information</td></tr><tr><td>Interview modeling participants</td></tr><tr><td>Prepare modeling session</td></tr><tr><td>Conduct modeling session</td></tr><tr><td>Write meeting minutes</td></tr><tr><td>Analyze and refine models</td></tr><tr><td>resent the results to stakeholders</td></tr></table>

*The modeling level* where domain knowledge is gathered and enterprise models created and refined. When it comes to gathering domain knowledge to be included in enterprise models, the main EKD way of working is facilitated group sessions. In facilitated group session, participation is *consensus-driven* in the sense that domain stakeholders “own” the models and govern their contents. In contrast, *consultative* participation means that analysts create models and domain stakeholders are then consulted in order to validate the models. In the participatory approach stakeholders meet in modeling sessions, led by a facilitator, to create models collaboratively. In the sessions, models are often documented on large plastic sheets using paper cards. The resulting “plastic wall” is viewed as the official “minutes”, for which every domain stakeholder in the session is responsible. [11]. There are two main arguments for using the participative approach, namely:

1. The *quality of models is enhanced* if they result from collaboration between stakeholders, rather than from consultants’ interpreting stakeholder interviews.

2. The approach involves stakeholders in the decision making process, which facilitates the *achievement of acceptance and commitment*. This is particularly important when modeling is focused on changing some aspect of the domain, such as e.g. its visions/strategies, business processes and information system support.

In a modeling session, the EKD process populates and refines the sub-model types used in that particular session gradually and in parallel. When working with a model type, driving questions are asked in order to keep this parallel modeling process going. This process has three goals: (1) define the relevant inter-model links, (2) to
drive the modeling process forward, and (3) ensure the quality of the model. Figure 1 illustrates driving questions and their consequences for establishing inter-model links in the model. It is also argued that shifting between model types while focusing on the same domain problem enhances the participants’ understanding of the problem domain and the specific problem at hand. More about the modeling process used in EKD and about facilitating modeling group sessions can be found in [11 and 12].

<figure><img src="image_2.png" /><figcaption>**Figure 1:** Working with inter-model links (dashed arrows) through driving questions</figcaption></figure>

## 2.3 Tool Support

The EM process needs to be supported by tools. The tool requirements depend on the organization's intentions (e.g. will the models be kept “alive”) and situational factors (e.g. the presence of skillful tool operators and resources). More on how to select and introduce EM tools in organizations is available in [13]. There are several categories of tools that can be considered.

*Group meeting facilitation tools.* There are a variety of tools supporting collaboration and meeting, e.g. GroupSystems, Adobe Connect, CURE. These tools can be used to support modeling. They have become more sophisticated and popular. However, they still lack specific support for participative EM, e.g. for guiding the modeling process or “close to reality” graphic resolution. We recommend using a
large plastic sheet and colored notes to document the model during a modeling
session. Then modeling can be set up in almost any room with a sufficiently large and
flat wall. Also, it allows the participants to work on the model without impeding each
other. If a computerized tool and a large projection screen are used, the participants
have to "queue" in order to enter their contributions. This usually slows down the
creative process. In addition, the "plastic wall" is also cheap and does not require
technicians to set it up.

After the modeling session the models on plastic may be captured with a digital
camera. If they are to be preserved, e.g. included in reports, posted on the intranet,
they need to be documented in a computerized *modeling tool*. This category of tools
includes simple drawing tools and more advanced model development and
management tools. In "stand-alone" projects only drawing support may be needed. If
so, simple drawing tools such as Microsoft Visio and iGrafx FlowCharter have proven
to be useful and cost-effective [1]. In other cases, e.g. when enterprise models need to
be communicated to large audiences or linked with existing information systems,
more advanced tools should be used. In this category of tools we find, for instance,
Aris (IDS Scheer) and Metis (Troux Technologies). Apart from modeling tools EM
projects need group *communication and collaboration tools*. We have successfully
used Basic Support for Collaborative Work (BSCW) tool (Fraunhofer).

Business requirements for EM tools include integration of EM tools with MS Office, model visualization and presentation requirements (often in web-format) as well as reporting and querying requirements. We have also observed a growing need to connect models to information systems, thus making the models executable. An extended presentation of requirements for EM tools is available in [13]

In the following sections we now discuss potential developments of the EKD
method, based on previous research and experiences from using the method in various
contexts and for various purposes.

3 Evolution of the Modeling Language

The EKD modeling language was intended to be fairly simple and flexible in order to
be effective in diverse modeling contexts. We intend to keep this principle. There are
however several improvement area that need to be worked on.

*Attributes of modeling components.* In the current version of EKD only a few modeling components have attributes namely, “supports” and “conflicts” relationships in the Goal Model have attribute “strength”. Other properties of modeling components we have expressed either within the textual formulation, in a comment field linked to the relevant modeling component, or with a certain loosely defined annotation symbol. The benefit of this way of working is flexibility of representation, but the drawback is a lack of formalism, reduced reusability, and poor scalability. We also envision that future modeling situations will need visualizing various prioritized solutions and alternatives as well as deal with other kinds of model annotations. Hence, EKD models should include attributes similar to those used for requirements management such as priority, risk, status, iteration, difficulty, and cost to implement. More on requirement attributes is available in e.g. [14]. In addition, there should be a
possibility for a modeler to define custom attributes. A considerable limitation in this regard is tool support. The use of simple drawing tools for up to medium size projects and models is still widespread and management of such attributes in tools like Visio is cumbersome. Hence, a shift to more advanced tools is needed.

*Use of known (modern) modeling languages.* The EKD notation has been assembled from a number of known modeling notations, such as Data Flow Diagrams and Crow Foot notation for data modeling. The benefit of the current notation is its simplicity. At the same time we have argued that the notation does not really influence the modeling result and hence different notations can also be used. The same is true for modeling languages. In principle, a modeling language used for a specific EKD sub-model can be replaced with another language addressing the same modeling perspective. E.g. the EKD goal modeling language could in principle be replaced with the MAP approach [15], and business process modeling language with BPMN [16]. Using these languages in the EKD framework could be seen as quite close to their overall design. A more advanced interchange could also be possible, e.g. we should investigate the possibility for using RuleSpeak [17] for representing business rules instead of the current BRM. In this case new guidelines for modeling would also have to be developed. Use of ontologies for documenting the domain language could be used instead of the current EKD Concepts Model. Similar approaches of integrating ontologies with enterprise models have been proposed in [18]. The challenge is to develop the meta-model in a way that facilitates these customizations of the modeling language. Using many such customizations would require new modeling guidelines and the meta-model should have a “placeholder” for documenting them.

*New modeling dimensions.* The current principle of modeling with EKD assumes that in most modeling cases everything that needs to be modeled can be modeled with the existing sub-models and modeling components. Hence, if a new modeling requirement emerges, e.g. to model new and specific perspective of the enterprise, two alternatives can be followed. (1) use the existing modeling constructs and, for example, define a concepts model with a specific purpose. This approach is useful if the modeling perspective needed is similar to one of the EKD sub-models. E.g. if we would like to model products and product structures, we could make a specialization of the Concepts Model and call it a Product Model. Another approach (2), is to tailor the EKD meta-model by defining new modeling components and/or sub-models/perspectives to represent the required perspectives. Examples of the need for new modeling components could be the following:

* *capability* expressing an ability to reach a certain business objective within the range of certain contexts by applying a certain solution. Capability would essentially link together business goals with reusable business process patterns that would be applicable to reach the goals within the specified contexts.

* *Key Performance Indicator (KPI)* linked with goals in the goal model. In this case we would have to establish a stereotyped concept and new type of association between the KPI concept and business goal. Having such a construct would also require defining modeling guidelines e.g. driving questions, for defining the KPIs during the modeling session or discovering them from the existing management IS.
Examples of new modeling perspectives that could potentially be needed in the future are:

* *Context modeling.* In this case we could be able to use the Concepts Model to represent the contexts and context properties. A new set of inter-model links would have to be established to Goals Model and to Business Process Model.

* *Reuse modeling.* Enterprise Models are reused, and often they become part of patterns. This transformation of models into reusable artifacts often should be modeled. Hence, introducing a reuse perspective in EKD is potentially useful. Modeling components of the reuse perspective would be modeling problem, context, consequences, and usage guidelines.

# 4 Evolution of the EKD Modeling Process

The EKD modeling process is participatory as described in section 3.2. This section discussed areas for its improvement.

*Two levels of EM process* – the EM project level and the modeling level. We consider the development of knowledge about the project level of the process related to the intended use of enterprise models to be necessary in order for the potential benefits of EM to appear. Taking this view of the process means that other issues than the modeling language and the way of working come into play – issues that target the whole model life cycle as well as EM project management. Examples of more detailed issues that need to be addressed are model quality assurance, model implementation in real life organizational/systems development, model maintenance, reuse of models, model retirement, model project preparation and management, competency management. Some of these issues are addressed in the EKD method handbook, but the guidelines need to be refined, complemented and structured according to the project level process.

*Competence of EM actors.* In order to manage this more complex EM process, a number of different competencies are needed. In [7] and [8] we have outlined a few core competencies based on the two levels of in the EM process and also related them to the purposes of EM. These developments constitute preliminary steps towards the creation of competency profiles for different roles and purposes in EM that can be used both for EM project planning and for training of EM practitioners. As modeling projects become more and more complex, we believe that there is a need to clearly identify essential roles that can be played by one or different individuals. This would contribute to the quality of EM project planning and execution. One side effect is also that these roles can function as a career path for modeling practitioners. A novice could initially assume the more simple roles (e.g. assistant facilitator) and then develop towards being an advanced modeling practitioner in a planned manner.

*Integration with pre-existing models.* It is quite unusual that an EM project starts from scratch without models previously existing in the organization. For every EM method it is then necessary to describe how such pre-existing models should be integrated in the project at hand. On the whole this is somewhat contradictory with the EKD view that the domain experts create the models in facilitated modeling sessions, but we have to be able to adjust the method for such cases as well.
*Selection and adoption of an EM method in a project* is an important issue that needs to be addressed in the process of modeling, particularly on the project level. Since most organizations already use various organizational development methods, EKD needs to provide guidance for how to connect to such methods creating “method chains” that will help solve the problem at hand on the project level. This can be facilitated by defining how the output from these other methods can be used as input to EKD enterprise models. This kind of guidelines can improve the possibility of new or non-commercial methods to be actually used in practice. Otherwise there is a risk that only methods and tools with strong vendor and/or consultant support will be used.

*Method customization and packaging* is a potential development that also relates to the project level of the process and the purposes of EM. Method support for this would address need for “bundling” parts of the generic method into customized method versions i.e. “dialects” to fit certain situations. The aspects of customization could be modeling notation, semantics, modeling processes and guidelines, as well as tool support. Such bundles could target different types of organizational domains or different types of problems such as cloud computing, IT governance etc. This approach would also facilitate development and selling of consulting services based on EM.

# 5 Evolution of Tool Support for the EKD Modeling Process

We have addressed tool support for EM in [13] more than a decade ago. To a large extent many of the EM tool requirements and usage context still are valid. EM practitioners often use simple drawing tools such as Visio and FlowCharter to document the models because their projects do not require the models to be processed by a tool. I.e. the models are mostly used as documentation of the modeling effort and serve as input for organizational change. They are not automatically imported in some other modeling tool that takes over the development and realizes the models. There are, however, a growing number of projects where EM is a part of a larger development venture and serves “input” to subsequent development activities. At present we can see a trend of tools for business process management, IS development, ERP configuration and governance becoming more mature and widely used. This increases the overall method and tool usage maturity of organizations. As a result, the need to extend the coverage of the current tools supporting EM is more apparent than ten years ago. Hence, EKD needs tool support for managing a repository and open import/export of models.

More specifically, the tool support for EKD should evolve in the following directions:

*Generation of IS from enterprise models.* The current MDD approaches and tools do not support the early stages of system development such as enterprise modeling and requirements in an integrated manner, e.g. see [19]. In [20], this challenge is addressed by proposing a unifying meta-model that integrates EM (namely, a modification of EKD) with MDD artifacts.
*Support for various notations.* EKD has followed the principle of using simple and relatively generic modeling notation. But considering the need to share and/or reuse models among different projects and organizations, customizing or even replacing the modeling notation should be possible. Support of known (modern) modeling languages is also needed.

*Support for reuse.* There are two main cases of reuse (1) development of generic models and then instantiating them to a specific application case, e.g. by adding additional details or introducing variations. In the MAPPER project this was achieved by introducing the concept of task patterns [21] supported by the Troux Architect (formerly Metis) tool and the AKM platform [22] (2) integration of organizational and analysis patterns. Patterns have proven to be useful for EM [21, 23]. Enterprise models contain many patterns and they are often built by using patterns. Currently tool support for reuse is limited at the level of storing, searching and retrieving patterns from a corporate knowledge repository. The actual application of a pattern requiring customization and adaptation is a manual process done by developers. There is however a trend of developing consulting services based on existing best practices and patterns. Since EM is part of delivering these services the supporting tools should provide support for designing organizations with patterns.

*Simple tools and cloud based tools.* Currently EM tools chiefly consist of graphical editors, model management services and repositories. Models from the repository can also be exported and displayed on the web thus not requiring tool installation for browsing. In the future cloud-based applications could be used to support EM. An early example of offering cloud based collaborative modeling is Creately, developed by Cinegrix Pty Ltd., Australia. Cloud-based group support and collaborations tools will most likely merge with modeling tools.

*Tool support for "keeping models alive".* This means tool support for ensuring that the models are up to date reflecting the reality – the way the organization actually functions. Lately there have been significant advancements in the area of business process management at run-time, but to achieve this for other types of enterprise models (e.g. goals and actors) requires high organizational maturity [13, 24] because model maintenance roles and processes should be established within the organization. In addition, there should also be tool functionality supporting this. Key area of research towards this would be to provide an approach for collecting feedback to a model without actually manipulating the model. There should be a way to annotate and/or version a model or a model fragment.

*Efficient model presentation and manipulation.* Tools are often used for presenting models to a larger audience. Using only the scrolling and zooming functionality that is built into contemporary operating systems is insufficient and often slows down the presentation. Therefore easier and more advanced zooming and model navigation is needed, perhaps allowing to define a set of multi-touch gestures for various model presentation actions.
# 6 Other Improvements

There are other areas of improvement as well. Chiefly, EKD should also provide more explicit and formal support for various manipulations with the models. The following two areas are of primary concern:

* *Quality assurance*. The area of EM has accumulated a great deal of knowledge when it comes to improving model quality, c.f. e.g. [25, 26, 27, 28]. However, in practice quality assurance is done by modelers, largely without specific tool support. Not all quality factors can be related to formal properties of the model, but there are a significant number of factors that can be supported by tools. Hence, more development should be targeting automatic analysis and suggesting for improvements.

* *Code or model generation*. There should be algorithms for generating design models or code from enterprise models. This aspect is not currently supported in EKD. In general, transforming business and enterprise models to other development artifacts is an underdeveloped research area and more attention to it should be devoted. This improvement aspect should be seen together with generating an IS from enterprise models mentioned in the previous section.

Method deployment and user support is another additional aspect where EKD needs some development. An EM method can be seen as successful only if it is successfully used in practice. EKD has been used by a significant number of organizations in various projects. However, the uptake of EKD, i.e. that an organization has continued to use it without the support of external experts and consultants, has not been widespread. We do not have reliable data, but some evidence suggests that such organizations are not more than seven or eight. Some more organizations have chosen different EM approaches after successful experiences with EKD. This leads us to conclude, at least initially, that for an EM method to be taken up by an organization, there should be support for: (1) method acquisition and implementation throughout the organization, (2) defining roles and responsibilities, (3) method usage procedures, and (4) tool usage. These should be described in the method manual. Furthermore, the method vendor should be able to provide user support, not only by answering questions when they arise, but by informing the users about the latest developments, as well as providing training and mentoring. The latter could be considered as too resource consuming for an academic method.

The name of a method is not unimportant. EKD means Enterprise Knowledge Development and name originated from one of the projects where the method was originally developed. Preferably a name should be “pronounceable” and to some extent signal what it is all about. This is something that needs to be considered for the future version of EKD.

# 7 Concluding Remarks

EKD is an EM method that has been developed by researchers. Its usefulness for business and systems development has been established in a number of cases. However, it is clear to us that even if its principles and components are sound, it takes
considerable effort to make a research based method mature, so that it can be easily adopted by organizations and linked to other established and complementing methods and tools, (e.g. Aris), approaches, (e.g. Balanced Scorecards, SAP reference models) and consulting products and services. But at the same time, the method should not give up its overall philosophy of a participatory and agile way of working and its process of iterative and incremental development of models.

In this paper we have taken the first steps towards maturing the EKD method by identifying and describing some improvements, based on empirical research, experience, and literature on EM. Several of the improvements discussed here also pose research challenges as well as practical challenges. Future work will commence by first prioritizing the suggested improvements. Implemented improvements will then be tested in suitable empirical settings.

## References

1. Persson, A. and Stirna, J. (2001). An explorative study into the influence of business goals on the practical use of Enterprise Modelling methods and tools, Tenth International Conference on Information Systems Development (ISD2001), Royal Holloway, University of London, 5-7 September 2001.

2. Bubenko J.A. jr, Persson A., Stirna J. (2010) An Intentional Perspective on Enterprise Modeling, in C. Salinesi, S. Nurcan, C. Souveyet, J.Ralyté (eds.), An Intentional Perspective on Enterprise Modeling, Springer, ISBN 978-3-642-12543-0

3. Bubenko, J. A. Jr., Persson, A. and Stirna, J. (2001). User Guide of the Knowledge Management Approach Using Enterprise Knowledge Patterns. Deliverable D3, IST Programme project Hypermedia and Pattern Based Knowledge Management for Smart Organisations, project no. IST-2000-28401, Royal Institute of Technology, Sweden

4. Persson, A., (2008), "The Practice of Participatory Enterprise Modelling – a Competency Perspective", in Johannesson, P. and Söderström, E. (eds.), Information Systems Engineering - from Data Analysis to Process Networks, pp 129-157, ISBN-13: 978-1-59904-567-2, Idea Group Inc.

5. Stirna J., Persson A., (2008) An Enterprise Modeling Approach to Support Creativity and Quality in Information Systems and Business Development, Innovations in Information Systems Modeling: Methods and Best Practices, Halpin T., Krogstie J., Proper E., IGI Global, ISBN 978-1-60566-278-7

6. Glaser, B. G. and Strauss, A. L. (1967), The Discovery of Grounded Theory: Strategies for Qualitative Research, Weidenfeld and Nicolson, London.

7. Persson A., Stirna J., (2010) Towards Defining a Competence Profile for the Enterprise Modeling Practitioner, P. van Bommel et al. (eds.), in proc. of PoEM 2010, proceedings, Springer LNBIP 68, ISBN 978-3-642-16781-2, p. 232-245

8. Stirna J., Persson A., (2012) Purpose Driven Competency Planning for Enterprise Modeling Projects, J. Ralyté, X. Franch, S. Brinkkemper, S. Wrycza (eds.), in proc. of CAiSE 2012, Springer LNCS 7328.

9. Willars, H. (1988). Handbok i ABC-metoden. Plandata Strategi.

10. Stirna, J., Persson A., Sandkuhl K., (2007) Participative Enterprise Modelling: Experiences and Recommendations, In John Krogstie, Andreas L. Opdahl, Guttorm Sindre (Eds.): Advanced Information Systems Engineering, 19th International Conference, CAiSE 2007, Trondheim, Norway, June 11-15, 2007, Proceedings. Lecture Notes in Computer Science 4495 Springer, ISBN 978-3-540-72987-7
11. Persson A. (2001). Enterprise Modelling in Practice: Situational Factors and their Influence on Adopting a Participative Approach, PhD thesis, Stockholm University, ISSN 1101-8526.

12. Nilsson, A. G., Tolis, C. and Nellborn, C. (Eds.) (1999), Perspectives on Business Modelling: Understanding and Changing Organisations, Springer-Verlag.

13. Stirna, J. (2001). The Influence of Intentional and Situational Factors on EM Tool Acquisition in Organisations, Ph.D. Thesis, Royal Institute of Technology, Sweden.

14. Weigers K., (2003) Software Requirements, Microsoft Press, ISBN 978-0735618794

15. Rolland C., Prakash N., Benjamen A. (1999) A Multi-Model View of Process Modelling. Requirements Engineering. Volume 4, Number 4, Springer

16. OMG (2011), Business Process Model and Notation, version 2.0, OMG.

17. Basic RuleSpeak Guidelines, Business Rule Solutions, LLC, Version 2.2. 2009.

18. Gailly F., Poels G., (2007) Ontology-Driven Business Modelling: Improving the Conceptual Representation of the REA Ontology, C. Parent et al. (Eds.) in proc. of ER 2007, LNCS 4801, pp. 407–422, 2007, Springer

19. Zikra I., Stirna J., Zdravkovic J. (2011) Bringing Enterprise Modeling Closer to Model-Driven Development, P. Johannesson, J. Krogstie & A.L. Opdahl (eds), in proc. of PoEM 2011, Springer LNBIP, p. 268-282,

20. Zikra I., España S., Ruiz M., Pastor Lopez O., Stirna J. (2012) Aligning Communication Analysis with the Unifying Meta-Model for Enterprise Modeling, to appear, in proc. of ISD 2012, Springer

21. Sandkuhl K., Stirna J., (2008) Evaluation of Task Pattern Use in Web-based Collaborative Engineering, Proc. of the 34th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA), EUROMICRO, IEEE, ISBN 978-0-7695-3276-9

22. Lillehagen, F., Krogstie, J., (2008) Active Knowledge Modeling of Enterprises, Springer, ISBN: 978-3-540-79415-8

23. Rolland C., Stirna J., Prekas N., Loucopoulos P., Grosz G., Persson A., (2000), Evaluating a Pattern Approach as an Aid for the Development of Organizational Knowledge: An Empirical Study, CAiSE’00, Conference on Advanced Information System Engineering, B.Wangler (Ed.), Springer, ISBN 3-540-67630-9

24. Wesenberg H., (2011) Enterprise Modeling in an Agile World, P. Johannesson, J. Krogstie, and A.L. Opdahl (eds.), in proc. of PoEM 2011, Springer LNBIP 92, p. 126-130

25. Krogstie, J., Sindre G., and Jørgensen H., (2006) Process models representing knowledge for action: a revised quality framework, European Journal of Information Systems (2006) 15, 91–102

26. Stirna, J., Persson A. (2009) Anti-patterns as a Means of Focusing on Critical Quality Aspects in Enterprise Modeling, Terry Halpin, John Krogstie, Selmin Nurcan, Erik Proper, Rainer Schmidt, Pnina Soffer, Roland Ukor (eds.) in Enterprise, Business-Process and Information Systems Modeling, Springer LNBIP 29, ISBN 978-3-642-01861-9,

27. Mendling, J., Reijers H.A., and Cardoso J., (2007) What Makes Process Models Understandable?, In G. Alonso, P. Dadam, and M. Rosemann, (eds.), International Conference on Business Process Management (BPM 2007), Springer LNCS 4714, p. 48–63

28. Krogstie, J., (2012) Model-Based Development and Evolution of Information Systems: A Quality Approach, Springer, ISBN 978-1-4471-2935-6