The Diversity of Enterprise Modeling – a Taxonomy for Enterprise Modeling Actions

Both researchers and practitioners have recognized the need for developed knowledge about enterprise modeling. Therefore it is necessary to increase the understanding of various actions that are performed during enterprise modeling, their meaning, and their diversity. This paper proposes a taxonomy with a conceptual structure in two dimensions (hierarchy and process) that could be used to increase the knowledge about enterprise modeling actions. The taxonomy introduces a terminology that enables a better understanding of the modeling actions for a clear purpose. One important aspect of the taxonomy is to create visibility and traceability of decisions made during enterprise modeling activities. These modeling decisions have previously been of a more tacit nature and the taxonomy is supposed to make the rationale behind different modeling decisions explicit and understandable.


Introduction
Successful business management in a dynamic and evolving environment demands considerable agility and flexibility from decision makers in order to remain competitive.During business change and business redesign there is a need to have clear understanding about the current status of business operations, i.e., a so-called baseline, which will serve as a starting point for all change actions.In this context Stirna and Persson [1] argue that Enterprise Modeling (EM) is one powerful and widely used mean that meets both of these types of needs.They depict two general purposes that EM can be used for.The first purpose is business development, for instance, development of business vision and strategies, and business operations redesign, development of the supporting information systems; whereas the second purpose is to ensure business quality, for instance, knowledge sharing about business or some aspect of business operations, or decision-making.EM is, in general terms, a process of creating enterprise models (visualizations) that represent different aspects of enterprise operation, for instance, goals, strategies, and needs [2].EM has been defined in different ways over the years (cf.[3], [4], [5]).The understanding of EM in this article is based on the following definition given by Bubenko et al. [6]: "Enterprise Modeling (EM) is the process of creating an integrated enterprise model, which captures the aspects of the enterprise required for the modeling purpose at hand.An enterprise in this context can be a private company, government department, academic institution, other kind of organization, or part thereof.An enterprise model consists of a number of related sub-models, each focusing on a particular aspect of the enterprise, e.g., processes, business rules, concepts/information, vision/goals, and actors.An enterprise model describes the current or future state of an enterprise and contains the commonly shared enterprise knowledge of the stakeholders involved in the modeling process".
The ability of enterprise models to depict and represent enterprises from several perspectives to provide a multidimensional understanding makes it a powerful tool for a number of different purposes.According to Sandkuhl et al. [7] typical challenges where EM can be helpful are:  Understanding organizational dependencies  Finding the need for change  Improving business processes  Aligning organizational strategy and IT  Developing the IT strategy EM is a participative and collaborative process where two sets of parties usually are represented: participants from the enterprise itself with domain knowledge and EM practitioners (or facilitators) who lead and coordinate the modeling session(s).The first group usually consists of enterprise employees who have to share and exchange their domain knowledge about enterprise operations, management, coordination, decisions, etc.The second party of EM is the EM practitioner -a person who facilitates and coordinates the EM process (partly or fully) towards effectively achieving its goals [8], [9].
EM is intended to be a purposeful activity with well-defined goals and actions according to the aims of the modeling session at hand.In order to achieve this there is a need to develop understanding about EM and the actions that constitute EM.These actions also need to be structured in such a way that EM actors can make rational choices about what actions to perform and to understand the consequences of these actions [10].The research questions of this article are therefore defined as:

What types of actions are performed during enterprise modeling?
How can enterprise modeling actions be structured to increase the understanding of enterprise modeling?
The rest of the article is structured as follows: Section 2 describes the research method that has been applied to address the research questions, Section 3 presents the theoretical foundation for current research.In Section 4 the results in the shape of a taxonomy for EM are presented.The article ends with conclusions and future work as described in Section 5.

Research Method
The process of developing the taxonomy can be described according to Figure 1.This research process has been chosen in order to be able to answer the previously formulated research questions.The first research question will be addressed through Activity 1 (Identify and characterize modeling actions) and the second research question will be addressed through Activity 2 (Identify categories of modeling actions), and Activity 3 (Development of the hierarchy and process dimension in the taxonomy) according to what is set out in Figure 1.The arrow-like boxes in Figure 1 represent the main activities that were performed in order to develop the taxonomy that is presented in this article.The empirical base for the development of the taxonomy was 6 EM cases (projects).The upper part of Figure 1 (octagonal shapes) represents different instrumental support (ontologies, method, taxonomy, and other relevant theories) that has been used during the development of the taxonomy.For further elaboration of the instrumental support for actions cf.Subsection 3.3 of the article.During the generation of the taxonomy it has been fruitful to use the base ontology (Socio Instrumental Pragmatism, (SIP) [59]) as a generative and structuring tool for the taxonomy, i.e., a support to understand and structure the role of humans, actions, artifacts, and the social world in the context of EM.It has, for instance, been useful to utilize this ontological foundation to cope with a too narrow focus on individual models during development and alignment initiatives.
The taxonomy for EM actions presented in this article has emerged over some time.Lately the taxonomy has been formalized more actively in different ways: this paper, EM projects, research programs, academic programs, and different conceptual descriptions.The initiating basis for this EM action taxonomy is the work by Seigerroth [10] where a similar formalization of actions was made for system development practices.The foundation for the development of the taxonomy in this paper has been both theoretical and empirical according to the above.The development has been theoretical in the sense that we always deal with different theoretical domains: both as scientific contributions and in application of theories in practice.The practical basis is that in a number of research projects (cases) over the last 5 years we have collected experiences about EM.Based on the work by Seigerroth [10] and 6 subsequent cases from industry and from the public sector, we have reconstructed the modeling actions from a number of EM sessions in these research projects.This has been done by addressing and seeking answers to questions such as:  What actions have been performed in the different EM sessions? What were the results of these actions?
-What material results can be identified?-What immaterial results can be identified (acceptance, rejection, agreement, common understanding, etc.)?  What was the expressed purpose for different actions? What were the inter-dependencies between different actions? What prerequisites were required to perform different actions? Were there multifunctional dimensions for different actions? What dimensions of reality were affected by different actions? Which actions and results had a transformational or coordinational character?
The research projects (cases) used for the analysis represented a variety of practices in order to be able to capture potential variants between different types of practices (two industrial cases, one consultancy firm, one user association, one municipality, and the process design project).The profiles of these 6 cases are detailed in the list below.The list also shows what focal areas were modeled in each case.In each of these cases we have used two different EM methods: 1) Information Demand Modeling, which is a method component that was developed in our research group in earlier research projects [11], and 2) Enterprise Knowledge Development (EKD) [12] for concept modeling, goal modeling, problem modeling, and process modeling.These 6 cases were:  An industrial sub-supplier (surface finishing) for the automotive industry, where we performed: -Information Demand Modeling (a variant of process modeling) -Concept modeling -Goal modeling -Problem modeling  An industrial OEM for the turbo machinery industry, where we performed: -Information demand modeling (a variant of process modeling) -Concept modeling  An IS/IT management consultancy firm, where we performed: -Information demand modeling (a variant of process modeling) -Concept modeling  A Swedish user association for an Enterprise System, where we performed: -Information demand modeling (a variant of process modeling) -Concept modeling -Goal modeling -Problem modeling  A Swedish smaller sized municipality, where we performed: -Information demand modeling (a variant of process modeling) -Concept modeling  A Swedish sports retailer chain, where we performed: -Process modeling -Goal modeling -Problem modeling In each of these cases we have used the logbooks from the modeling sessions, and the models produced from the modeling sessions as the base to identify what modeling actions were performed and to answer the question presented earlier in this section.
We have modeled different aspects in the modeling cases in order to develop the presented conceptualization (taxonomy).Examples of such are: actions, results (material and immaterial), relations, and concepts.Based on this, we have then developed the taxonomy presented in Section 4. This conceptualization needs to be further validated; one part of the theoretical validation is through this paper.Additional empirical validation will be done through different upcoming research projects, through applications in new projects, within which this taxonomy will serve as the basis for modeling, and in EM-related education at the university.
The research method in the different research projects, which also constitute the cases for this article, was action research because this method has proven to be useful in similar types of research settings (e.g., [13]).Action research has been described as a research method suited to study technology in a human context [13], which is an essential focus in the IS discipline.In this article and in the cases used this means the study of EM actions as a base for development of information technology as an integrated part of enterprises.The EM practice thus has to be considered in a human context.In this we rely on the same arguments that are put forward by Lindgren et al. [13] where they express that action researchers see it as their responsibility to assist practitioners not only by developing but also by applying knowledge.As pragmatists we see the goals of social science to be oriented towards creating scientific knowledge that is of practical value.Such a view has its roots in practical inquiry mainly inspired by Dewey [14], and as stated by Goldkuhl [15]: practical inquiry and action research resemble each other to a high degree.Given this epistemological stance, research should be executed through inter-related processes of action, design, interaction, and reflection.
Validity claims raised for this scientific contribution are in accordance with multi-grounded theory (MGT) [16], which was used to analyze the 6 different, modeling cases.These validity claims are that the knowledge is internally, empirically, and theoretically validated (justified).In this article such claims are raised for categorical knowledge about actions performed during EM sessions.These categories of actions are derived from the research projects (cases) as well as from theoretical standpoints held by others.MGT has thus been adopted in a combined inductive and deductive research approach for the analysis.MGT was originally a reaction to grounded theory and its purer inductive approach.MGT is a process for theory development in three integrated steps that include such techniques as theory-informed open coding, axial coding, and selective coding.The first step is theory generation, the second step is explicit grounding, and the final step is research interest, reflection, and revision (cf.[16]).The 6 cases that are the basis for this study have in an iterative way been analyzed in line with these steps according to the principles reflected in Figure 1.Given that a pragmatist view on knowledge is adopted, the result of an MGT process is knowledge in the shape of practical theories.The categories constituting the taxonomy, presented later in Chapter 4, are empirically derived from the research projects (6 cases), theoretically validated, and internally validated through SIP (the base ontology).

Theoretical foundation for the taxonomy for enterprise modeling
This section presents the theoretical background and foundation for the taxonomy for enterprise modeling.The purpose of this section is mainly to increase the understanding of different dimensions of the taxonomy for enterprise modeling that will be presented in Section 4.

Ontological foundation for enterprise modeling
EM requires a solid foundation and an elaborated understanding of what to direct attention towards during different modeling initiatives.In this article such foundation for directing attention is conceived as an ontological base [17] covering different areas that are relevant for EM to focus on.This requires a congruent ontology for categorizing essential aspects to be acknowledged.Since EM is to be conceived as actions, in which both humans and artifacts have a central role, there will be an evident need for a common so called base ontology [17] capturing both social and technical dimensions.EM and other work practices are constituted by actions performed by humans and artifacts.The purpose of these actions is to produce new/refined artifacts in conjunction with the EM practice, in which the artifact is a vital part.An ontology can also serve as an aid in the aspiration to identify the scope of actions that are performed during an EM session.In this section a base ontology and a domain ontology for that purpose will be introduced.The base ontology, Socio-Instrumental Pragmatism (SIP), describes general social concepts while the domain ontology, Business Processes, describes what we need to acknowledge in the process perspective as a facet or focal area of EM.These two ontologies have mainly been used as a lens to identify and structure relevant actions that in one way or another can be regarded as EM actions.SIP (cf.[18], [58]) incorporates human, organizational, and IT-enabled actions in a coherent structure.This foundation stresses the importance of viewing the world through "lenses" of actions.Actions performed by humans, organizations, and artifacts can be captured in this way.Such an ontology is one way to capture and structure actions that are performed during EM.The concern of theorizing action has also been acknowledged by Latour´s actor-network theory (ANT) (cf.[19]), where technology and people are both seen as social actants.Goldkuhl and Ågerfalk [20] also depict that there is a need to acknowledge the social in the technical and the technical in the social.A conclusion that can be drawn from this is that there is a need to understand the actions that are performed during EM in order to be more successful with EM initiatives in terms of improving alignment between the social and the technical during these types of activities.As identified by several researchers (e.g., [20], [21]) the specific character of artifacts, in this study enterprise models, used in system development practices needs to be recognized.Within SIP, similar and diverse properties of human and artifact enabled actions are acknowledged.Artifact enabled human actions are elaborated further in Subsection 3.3 where different instrumental support for human actions is presented.
According to SIP, an action is a purposeful and meaningful behavior of humans or artifacts acting on behalf of an organization.Humans act in order to achieve ends [22], often with the purpose of achieving material changes.This gives rise to different types of actions, such as strategic, tactical, and operative actions in relation to the focused area of concern.An enterprise consists of humans, artifacts, and other resources and their performance of actions.Humans (often supported by artifacts) perform actions on behalf of the organization [23], [24], which therefore also need to be captured during EM, i.e., to be able to model the variety of actions that are performed in an organization.Human actions are about making a difference and impact in the social world as well as in the material world [22].From an organizational point of view this means that the result of the development practice becomes a concern.A social action is an action oriented towards other persons [25], and these actions can be communicative or material to their character.Communicative actions mean that someone is communicating something to another person and material actions also have a social dimension if they are directed to other persons [18].
A business processes perspective has been adopted as the main domain ontology since it has strong foundation within EM [26].It should, however, be noted that the traditional viewpoint on business processes, a transformative view [27], does not obviously provide all the facts to achieve the purpose of a certain EM initiative, for instance, to address both the social and the technical dimensions.IT and Information systems (IS) are mainly to be understood as action and communication systems [18].It is thus important to complement the traditional transformative view of business processes with a communicative view in order to stress the relationship between IT/IS and business processes [28], [29].Such a complement means that the backbone of business processes needs to be constituted by the establishment and fulfillment of expectations, founded in social exchanges, between two or several parties [30], [31].Developing a synthesis between business processes as transformation and co-ordination has been powered by the support of SIP as a base ontology [29].
A social view on system development practice has a long tradition in IS research and therefore also indirectly in EM since EM for a long time has served as a tool for specification of requirements and design.Resulting enterprise models have a close relation to IS/IT solutions and architectures, which, in turn, have a close relation to human actions, which finally are closely related to business plans and strategic goals.Since information is something that is communicated by someone to somebody, such a view on EM, system development, IS/IT solutions, and architecture becomes closely related to communication and business languages (cf.[32]).A social and organizational view for understanding information systems development has also been elaborated based on linguistics [33], [34], [31] and semiotics [35].

Challenging dimensions of enterprise modeling
The need to deal with the gap between organizational context and technology within enterprises has been recognized and discussed by the IS research community for quite some time [36].Several researchers have emphasized the need to capture dimensions of both business and IT during design and implementation of IS (cf.[37]).A challenge in this has been that we need to move beyond a narrow focus on one tradition or technology and actually deal with a number of conceptual ways to slice the enterprise in an integrated way [38].The same argument can be found in the area of enterprise architecture (EA) and EM, in which there is a need to conceptually slice the business, but where these slices or enterprise facets must be treated as parts in some total alignment context where all the slices relate to each other [39].For modeling and models this means that the produced artifacts (models) also need to be aligned, both within a certain phase and between different phases in the development cycle.Information system research has for some time also dealt with this alignment issue between organizational context and technology (cf., e.g., [36]).Several researchers have stated the need to capture both the IT perspective and the business perspective during development and implementation of IS [37], [40], [41].This dual perspective is also relevant when we expand the view of IS and say that we need to create aligned IS/IT structures as a part of the total enterprise architecture [39].This means that we need to be aware of and able to cope with a number of dimensions (facets) of the enterprise architecture and their relations in order to create alignment.Examples of such dimensions are: organization, strategies, business models, work practices, processes, and IS/IT structures [42], [43].In this context EM serves as a widely used and effective practice, because of the core capability of enterprise models to capture different aspects of an enterprise.A model can therefore be regarded as a generalized representation of a piece of reality relevant for the modeling purpose at hand.Thus, EM is gaining increasing recognition as a tool that can be used for a number of evaluation and development purposes, e.g., alignment of business with IT [44].The point of departure of IS development and business and IT alignment is usually enterprise models focusing on different business aspects that reflect the present situation.Business process modeling as a type of EM has been used for several purposes [38], [45], such as reconstructing and evaluation of existing practice (AS-IS) and consequently also as evolving models for reflection, modeling the future (TO-BE), as well as determining historical chains of events.Practitioners within the IS-field tend to engage in EM (conceptual modeling) for the purpose of analysis, design, and evaluation of enterprises and information systems [46].So far, however, little research has been conducted on EM [9], [44], the actions of EM, and how to achieve alignment between business and IT through these modeling actions and the models produced.
In this research, enterprise models are regarded as tangible descriptions of patterns of social (business) and technical (IS/IT artifacts) aspects in an enterprise.This means that enterprise models and EM actions can be used as a structured support in a transition process to take an enterprise from one state to another.
To go beyond individual models (facets or focal areas) means that models on different abstractions or organizational levels and within different levels need to be dealt with from an alignment perspective.In Figure 2 below five different dimensions (the arrows) have been proposed that describe the character of models on different levels and within different levels (cf.[47]).In the background of the figure there is a triangle, which represents an organizational alignment triangle with different levels like strategies, business models in the upper levels and work practices, processes, and IS/IT structures in the lower levels.The arrows in the foreground of Figure 2 depict how the different dimensions are relevant for EM and business and for IT alignment.
The 5 dimensions that are put forward are: 1) Degree of formalism, 2) Accuracy of the view, 3) Degree of detail, 4) Change and model dependencies, and 5) abstraction level.All these dimensions will be challenges that need to be handled from a business and IT alignment perspective with respect to different models and the development cycle that usually is applied during EM.The directions of the two arrows in this dimension depicts that there are dependencies between models that need to be handled both within a level and between levels in the triangle.5. Abstraction level refers to the way of hiding the implementation details of a particular set of enterprise models.Implementation level in this case refers to how upper levels are translated into lower levels, for instance, processes and IS/IT structures.The direction of the arrow in this dimension depicts that the abstraction level will/could increase as we move upwards in the triangle.
If, during the development cycle, there is a coherence between the actions and the models that are produced, according to the dimensions in Figure 2, we have a better chance to also achieve alignment between business and IT.Therefore, to arrive at business and IT alignment we need to understand and to be able to handle the complexity that exists in terms of different aspects or conceptual domains of an enterprise [22], [39], [48], represented through enterprise models.One way of handling this complexity is to have a clear understanding of the different actions that are performed during the production and manifestation of the enterprise models.The challenge here is once again to go beyond the individual models and to cope with the actions and the different characteristics of these different models, how they are related to each other and how they contribute to business and IT alignment [44].Similar challenges have also been identified by other researchers; layered pattern architecture by Weigand & van der Heuvel [49] and generic layered patterns by Lind & Goldkuhl [50].The need to conceptually slice enterprises into different focal areas and abstraction levels by the use of models has been identified earlier [26], [39], [51].There are many different types of models that can support such conceptual slicing.Many of these models are theoretically grounded, professionally used, and have proven themselves useful to deal with different focal areas and abstraction levels of an enterprise.The rational choice is, therefore, not to reinvent the wheel by developing new models for different focal areas and abstraction levels.The focus should rather be on developing helpful guidelines for how to handle models according to the dimensions in Figure 2 and to apply a multi-layered thinking during EM (cf.[43]).

Artifact enabled enterprise modeling to improve business and IT alignment
There are several things that can influence, guide, and inspire us to take different actions during EM. Figure 3 conceptualizes this situation, in which EM actors use various types of instrumental support to make a difference (also cf.[44]).The instrumental supports for human actions that are depicted and structured in this figure are methods, theories, knowledge & experiences, best practices, patterns, and IT implemented tools.The main reason for this elaboration is to structure, formalize, and clarify the different types of support that are used during EM (artifact mediated actions) for the purpose of business and IT alignment.The sources of guidance and influence that we use during EM can be of a tacit nature in terms of different experiences that we have and that we are recalling in the actual modeling situation.The sources for actions can also be explicitly formulated in different method descriptions that we follow.Somewhere between experiences and methods we find theories that guide us without giving the explicit prescriptive directives like methods.Guidance for action can also be found in the solution space.Here we find support in terms of best practices, which, for instance, can be instantiated through different patterns.In addition to this we can also use computerized tools, in which the method has been implemented.The use of methods, theories, patterns, and tools can therefore be regarded as action knowledge that we can agree with and seek support from during EM.One instrumental support that we use extensively for EM is methods.A method is prescriptive in its nature, since it gives us guidance on what to do (EM actions) in different situations in order to reach certain goals.During EM usually it is necessary to document various aspects, and many methods, therefore, include rules for representation, usually called modeling techniques or notations.Methods also provide procedural guidelines, which often are tightly coupled to notation.The procedure involves some meta-concepts such as process, activity, information, and object, which are parts of the prescribed procedure.They are also parts of the semantics of the notations.The concepts are the cement and the overlapping parts between procedure and notation.Methods can thus be crystallized into Perform action A in order to reach goal G.
It has now been stated that procedure, notation, and concepts, among other things, constitute methods.When there is a close link between procedure, notation, and concepts, it is referred to as a method component according to Figure 4 below, which is a conceptualization of the central parts of a method theory presented by Goldkuhl, Lind, and Seigerroth [52].The concept of method component is similar to the concept of method chunk [53], [54] and the notion of method fragment [55].A method component tells us how to perform a certain work step, e.g., the method component process modeling is executed through the procedure instructions -notation rules -and the concepts focused on.A method is often a compound of several method components into what is often called a methodology [56].Method components together form a structure called a framework, which includes the phase structure of the method.This phase structure tells us what to do, in what order, and what results to produce.All methods build on some implicit (tacit) or explicit perspective.Such a perspective includes values, principles, and categories (with definitions), which are more fully expressed in the method and its method components.The perspective is the concept and value basis of the method and its rationality.The perspective depicts epistemological, ontological, theoretical, and practical standpoints for the method, e.g., socio-technical view, component based view, process orientation, participation, etc.An additional aspect of methods is labeled cooperation and collection principles.Cooperation principles depict how different persons interact and cooperate when they are performing method-guided work.Cooperation principles have to do with roles and division of work in the process and it is conceptually important to distinguish between a procedure (what question to ask), a cooperation principle (who is asking the question), and a collection principle (how the answer is collected).A method component (with procedures) can be used with several different cooperation and collection principles, such as, for instance, seminars, brainstorming sessions, interviews, and questionnaires.

A taxonomy for enterprise modeling actions
In the analysis of the cases that was presented earlier in Section 2 the main result was to develop a structure and systematization of the EM actions that have been performed in these 6 research projects.This systematization has been manifested through the taxonomy that will be presented in this section.The main purpose of the taxonomy is to serve as a support to understand the character of EM and thus facilitate the creation and maintenance of alignment, within and between artifacts, both during the development process and in the final implemented product.The taxonomy for EM actions that is presented in this article is constituted by two dimensions, which suggest a conceptualization and structure for different actions that are performed during EM.These two dimensions are a hierarchy dimension and a process dimension.The hierarchy dimension is an elaboration on and a manifestation of the dimensions of EM and business and IT alignment that was presented in Figure 2. The process dimension is an elaboration of a generic phase structure from a lifecycle perspective.

The hierarchy dimension of enterprise modeling actions
The hierarchy dimension deals with EM actions in a conceptual division on two levels -an action level and an activity level, according to the right hand side in Figure 5.

Figure 5. Conceptualization of the hierarchy dimension
On the action level the taxonomy gives a repertoire of actions that are usually performed during EM.The activity level of the taxonomy is composed by the actions that are performed on the action level during EM.The action level is the most detailed level of EM actions, which can be used to understand and describe EM actions on a detailed level.Connected to the action level, the hierarchy dimension also puts forward 4 different characteristics connected to modeling actions: Multifunctionality, Basic function, Action type, and Dimension of reality (the left hand side of Figure 5), which will be elaborated further in this section.
On the activity level we will find activities that are more general and complex (analysis, modeling, reconstruction, etc.) and therefore not described on the action level.The activities on the activity level will be composed of several actions from the action level.The repertoire of EM actions, which in this research was identified on the action level in the taxonomy, is reflected in Figure 6.This repertoire of actions has an initial idea of what are the EM actions that are in focus on the action level in the taxonomy.As described earlier in this section, the EM actions are also related to different characteristics (action characteristics).The first characteristic is multifunctionality.In this context, multifunctionality means that EM actions, when they are performed, will have different co-existing functions (cf.[57]), i.e., there will be different types of impact in different dimensions of reality according to the previously presented base ontology (SIP).The same modeling action can, for instance, be performed for both -understanding and evaluation.In Figure 7 this is, for instance, illustrated by the modeling action Compile, which can be performed both to arrange and/or to shape something.The next characteristic presented is the basic function of EM actions.In this research we have made a distinction between two basic functions, namely, transformation and coordination (cf.[43]).Basic function means that EM actions will have different impact on the continuing modeling process, i.e., if the basic function only is transformative or if it also is coordinative.EM actions that are only transformative will change the state of some artifact, but the new result (new version of the model) does not have to have any accentuated effect in the continuing modeling process.However, EM actions that are coordinative will produce models that one should/will/must take into account in the continuing modeling process in order to be able to create and uphold alignment both during the modeling process and in the final results,-for instance, the design of some organizational IS/IT solution.The next characteristic is an action type.The basis for this characteristic is that EM actions can be grouped into more generic types of actions (action type), where the taxonomy expresses such action types as arranging, collecting, decisive, informative, shaping and validating.These action types are then used to categorize the specific EM actions into different groups of actions according to Figure 7.With this structure it is possible to categorize actions that are of a more transformative character and communicative character according to the previously presented domain ontology (process theory).

Figure 7. Grouping of actions into action level and action types
The last characteristic in the action class is dimension of reality.Based on the base ontology (SIP) this means that all actions (actions level) will have impact in different dimensions of reality (cf.[58]).The fundamental division in this characteristic is to deal with effects of actions in terms of the inner and external world.The inner world is what we, as humans, have in our heads, i.e., our mental constructions and understandings of things.The inner world can also be divided into both an intra-subjective part and an inter-subjective part.The intra-subjective part is the understanding and mental construction of things of an individual while the inter-subjective part is the shared understanding and mental construction between more than one individual.The external world is outside of us as humans and is divided into three dimensions: signs, artifacts and real things.this context signs are written text, diagrams, figures, models, and spoken language.Artifacts are something that is created by humans, and does not exist naturally in the world without human involvement.We regard an artifact as something that can be instantiated with physical and/or social properties.Examples of artifacts are computers, software, methods, models, norms, attitudes, and values [59].Real things are objects that are not made by humans, such as trees, mountains, and lakes (ecofacts).
In many cases, modeling actions can be regarded as a consequence of the use of different types of instrumental support (methods, theories, knowledge and experiences, best practices, patterns, and IT implemented tools), i.e., artifact mediated actions.Therefore it has also been important to use the conceptualization of artifact mediated actions presented in Subsection 3.3 when we identified different types of support for EM actions.In this context it has been especially important to elucidate different EM actions related to the notion of methods and the use of methods since methods constitute the main support for EM.

Action types with corresponding actions
We have presented 6 action types in Figure 7: arranging actions, collecting actions, decisive actions, informative actions, shaping actions, and validating actions.These 6 groups of actions (action types) are then constituted by different modeling actions for each action type and the meanings of these actions are summarized in Table 1.Characterize: to decide and describe the properties of an artifact.This modeling action is also multifunctional.
Identify: to perceive something as an entity based on certain properties.Properties can be of a tacit nature to start with but then they become explicit during the identification.This modeling action is also multifunctional.
Inventory: to make a list of something within a domain.This modeling action is also multifunctional.
Relate: to decide reciprocal and mutual conditions within or between different entities.This modeling action is also multifunctional.

Collecting actions
Observe: to make observations through questioning or no questions, in writing or no writing, or in dialogue or no dialogue.Prioritize: to place something in order of precedence, i.e., to say that something is more important.

Decisive actions
Settle: to decide and establish something as valid, e.g., to settle earlier definitions or priorities.
Informative actions Advice: to give prescriptive information or transfer prescriptive knowledge about something.
Present: to give information or transfer knowledge about something.

Shaping actions
Adapt: to adjust something according to changing properties.
Compile: to bring together parts into a wholeness, i.e., arrange the parts into a systematic structure.It is a stronger systematic structure than the compile as an arranging action.This modeling action is also multifunctional, see arranging actions above.
Characterize: to decide and describe the properties of an artifact.This modeling action is also multifunctional, see arranging actions above.
Define: to make a standpoint about what something is.To define something also means to express what something is not!This modeling action is also multifunctional, see decisive actions above.
Identify: to perceive something as an entity based on certain properties.Properties can be of tacit nature to start with but then they become explicit during the identification.This modeling action is also multifunctional, see arranging actions above.
Inventory: to make a list of something within a domain.This modeling action is also multifunctional, see arranging actions above.
Relate: to decide reciprocal and mutual conditions within and/or between entities.This modeling action is also multifunctional, see arranging actions above.
Systematize: to make something formal through giving it a systematic shape, often a conceptualization.

Validating actions
Falsify: to show that something is not true and not valid in certain circumstances.
Unite: to create consensus and mutual agreements between actors about something.
Verify: to show that something is true and valid in certain circumstances.

The process dimension of enterprise modeling actions
The process dimension suggests a division of the EM process and its modeling actions into three generic lifecycle phases (understanding, evaluation, and design) according to Figure 8.The process dimension gives expression for a recommended ideal typical order between modeling actions on different levels according to the list below:  First it is recommended to develop the understanding for the actual situation (AS-IS)  Then it is recommended to evaluate this developed understanding  Finally it is recommended to perform different design efforts based on the results from previous activities (TO-BE) The process dimension also gives support for iterative action patterns.It is, for instance, possible that the evaluation generates such results that it is realized that one have to develop additional understanding before it is possible to continue to the design.
In order to be able to give a richer description of the process dimension and the taxonomy as a whole, the process dimension is presented together with the hierarchy dimension.If these two dimensions are integrated, the taxonomy can be described according to Figure 9. Through integration of these two dimensions it is possible to describe what type of EM actions are mainly performed during EM in order to improve business and IT alignment process (understanding, evaluation, and design).This division also emphasizes possible multifunctionality related to some types of actions (action type in the previously presented action class).This is done through action types (such as arranging actions and decisive actions) that appear in more than one phase of the process dimension (procedural multifunctionality).Procedural multifunctionality means that even if the understanding and arranging are in the foreground (main intention) when a modeling action is performed, there will, simultaneously, exist an evaluation aspect of the arranging in the background more or less tacitly.Multifunctionality also has a temporal side when modeling actions are performed in a collective context (temporal multifunctionality),for instance, when someone (a seminar leader) during a modeling seminar relates (modeling action) two objects with each other on a whiteboard.This action will have a temporal multifunctionality because:  The seminar leader performs an arranging action (action type) as he or she relates (action level) two objects on the whiteboard. At the same time, when the seminar leader relates the two objects also performs an informative action (action type) as he or she presents (action level) this for the rest of the seminar participants.
Through that the seminar leader relates two objects on the whiteboard, the other participants of the seminar will also contribute to the temporal multifunctionality:  The seminar members will, as a result of the drawing on the whiteboard, perform a collecting action (action type) through which they observe (action level) the documentation on the whiteboard. At the same time the seminar members will perform a validating action (action type) through their mental or explicit verification or falsification (action level) of the relation performed by the seminar leader.
Another aspect of multifunctionality that is expressed through the hierarchy dimension is multifunctional effects.This means that modeling actions can have effects in more than one dimension of reality at the same time according to previously presented base ontology (SIP).An example of this is the creation of a relation between two objects on the whiteboard.In this case there will be an impact in both the inner world and the external world.With respect to the inner world we develop our mental individual (intra subjective) or shared (inter subjective) understanding about these two objects.There will also be an impact on the external world via actual relation being drawn between two objects on the whiteboard.

Conclusions and future work
The need to successfully conduct EM as a mean to improve business and IT alignment is the foundation for this paper.With this as the overall purpose the paper has addressed the constituents of EM in terms of human actions (in most cases artifact mediated actions).Correspondingly, the main contribution of this work is an action oriented conceptual structure (taxonomy) of modeling actions performed during EM.
There are some previous attempts to develop a systematic structure related to modeling actions.One example is Lankhorst et al. [39] where they have done this for modeling actions in the context of enterprise architecture (EA).EA also relies on models and is closely related to business and IT alignment.Therefore the rationale behind why this research is relevant is similar.One reason to make such systematization is to introduce a terminology that enables us to understand, to evaluate, and to make decisions about the actions and the rationale of EM for a certain purpose.More importantly -the taxonomy can increase the mental awareness about and help to understand intuitive modeling actions that are performed without really thinking about "How?" and "Why?".Finally, this can increase the possibilities to achieve an improved degree of business and IT alignment.Two important dimensions with the taxonomy are to create traceability related to decisions during EM that previously has been of more tacit nature and to make the rationale behind these decisions more explicit and understandable.This will also contribute to the process where involved modeling participants can develop their inter-subjective knowledge about the situation through the models.This means that there will be clearer mutual agreements about the situation and participants will be able to commit to the models and the rationale behind them.The basic modeling actions presented by Lankhorst et al. [39] are: Introduce, Refine, Abandon, Abstract, Translate, and Document.These actions are, in general, on a more abstract level compared to the taxonomy that is presented in this article and they can be described through the actions in the presented taxonomy.Abandon, for instance, is a result of evaluating actions where this can be the result from something being falsified.The presented taxonomy is constituted a greater degree of details and with an elaborated structure in terms of hierarchy and process.The will help to emphasize the social interactions related to modeling actions, the rationale behind them, and the possibility to better understand what is happening during an EM session.The elaborated structure can also contribute to a more visible and understandable traceability, related to decisions, rationale behind decisions, increased intersubjectivity, mutual agreements, and commitments during EM.
Even though this taxonomy has been developed based on both -an empirical and a theoretical basis it still has some limitations.The status of the current taxonomy has to be validated further, especially empirical validation through usage of the taxonomy during project planning, actual performance of projects, and for evaluation of project results/impact.Another obvious limitation is the coverage of the system lifecycle.In its state only three phases of the system lifecycle are covered, namely, understanding, evaluation, and design.As depicted concerning research below, there are at least two additional phases of the life cycle that ought to be analyzed: 1) implementation and 2) operation and maintenance.There are also additional focal areas for EM that has not been examined during the development of the taxonomy.Examples of such focal areas are; use case modeling, rule modeling, actor/resource modeling, strength modeling, etc.
In order to develop the taxonomy further, the research will be conducted for the rest phases of the system lifecycle (on the right hand side of Figure 10) Implementation, and Operations & Maintenance.The continued research will extend both the process dimension of the taxonomy and the hierarchy dimension according to Figure 11.

Figure 1 .
Figure 1.Research process for development of the taxonomy

Figure 2 . 4 .
Figure 2. Dimensions of EM and business and IT alignment[47]

Figure 6 .
Figure 6.Repertoire of EM actions Define: to make a standpoint about what something is.To define something also means to express what something is not!This modeling action is also multifunctional.Formalize: to give something legitimacy through a formal motivation.A decisive action about what should be formally valid.

Figure 8 .
Figure 8. Conceptualization of the process dimension

Figure 9 .
Figure 9. Conceptualization of EM actions and integration of the hierarchy and process dimensions

Figure 10 .
Figure 10.Continued research related to enterprise modeling actions

Figure 11 .
Figure 11.Possible extension of the EM taxonomy

Table 1 .
Actions types with corresponding actions for EM to bring together parts into a wholeness, i.e., arrange the parts into a systematic structure.It is not a strong systematic structure since the relations between the parts are not clarified.This modeling action is also multifunctional, i.e., it can have multiple coexisting purposes.