Towards a coherent enterprise modelling landscape Marija Bjeković1,2,3 , Henderik A. Proper1,2,3 , and Jean-Sébastien Sottet1,3 1 Public Research Centre Henri Tudor, Luxembourg, Luxembourg 2 Radboud University Nijmegen, Nijmegen, the Netherlands 3 EE-Team?? , Luxembourg, Luxembourg {marija.bjekovic,erik.proper,jean-sebastien.sottet}@tudor.lu Abstract. When modelling enterprises, for instance as part of an enterprise (re)engineering effort, one typically uses a range of models. These models dif- fer in their intended purpose in terms of the domain which the model should pertain to and the intended usage of the model by its audience. The models are therefore generally created in purpose-specific modelling languages; i.e. not just domain-specific languages. While using purpose-specific modelling languages has clear benefits in terms of the suitability of the language to a purpose at hand, there is also a downside to it. As each of the resulting enterprise models refers to (different aspects of) the same (version of the) enterprise, it is desirable to maintain coherence across the different models. The use of a wide range of purpose-specific models (and mod- elling languages) can easily lead to a fragmentation of the modelling landscape; i.e. a break up of coherence. This leads to a natural polarity between coherence and purpose-specificity. We argue that this polarity requires careful management, but first and foremost a better understanding. To cope with, or avoid, the consequences of fragmentation, different strategies to achieve the integration of models and languages used in enterprise modelling have been suggested in the literature. These approaches, however, focus mainly on syntactic aspects of the models, while sometimes indeed including their (for- mal) semantics, and only to some extent their pragmatics. The aim of the research, reported on in this paper, is to achieve a deeper under- standing of the needs and challenges of the use of different models in enterprise modelling. Key words: enterprise modelling, model integration, modelling languages 1 Introduction When deliberately changing (parts of an) enterprise, one generally uses models to un- derstand the current situation of the enterprise, analyse the problems/challenges with regard to the current situation, sketch potential future scenario’s, and design selected future desired states of the enterprise, etc. We use the term enterprise modelling land- scape, or simply modelling landscape, to refer to the variety of models (and corre- sponding purpose-specific modelling languages) used in such efforts. The developing ?? The Enterprise Engineering Team (EE-Team) is a collaboration between Public Research Cen- tre Henri Tudor, Radboud University Nijmegen and HAN University of Applied Sciences (www.ee-team.eu). 2 Marija Bjeković et al. field of enterprise engineering [1, 2] also strongly promotes the use of a model-enabled approach to the transformation of enterprises. When modelling enterprises in an enterprise engineering context, one must do so from the perspective of different domains, such as business processes, value exchanges, products and services, information systems, etc. The fact that enterprise modelling needs to deal with different domains, within the context of a specific enterprise is certainly not new. In the field of information systems engineering, the use of a multi- perspective approach has long since been advocated, e.g. [3, 4]. In the case of enterprise modelling, however, the number of domains to be included increases. For example, en- terprise architecture frameworks suggest a much wider range of views that look beyond the traditional business-to-IT stack [5, 6, 7]. We argue that the plethora of models used in enterprise engineering efforts is brought about by the fact that models are needed for different purposes. In our cur- rent understanding, and based on our earlier work in e.g. [8, 9], we see the purpose of a model as a combination of: 1. the domain which the model should pertain to (e.g. different aspects and/or versions of the enterprise, the scope, granularity, etc.) and 2. the planned usage of the model (e.g. analysis, sketching, contracting, execution, etc.) by its intended audience. In other words, the purpose of a specific model is to capture some domain to enable some usage by its audience. Ideally, such models are created in a purpose-specific modelling language that tunes the modelling constructs of the language to the domain to be modelled, as well as adjust the precision/form of the medium, syntax and semantics of the language to the intended usage of the models. In practical modelling situations we have observed how, depending on the modelling purpose at hand, generic modelling language, such as UML [10] or ArchiMate [11], are used in different ways with regard to the ‘discipline’ with which the syntax and semantics of the generic language is obeyed to. In our view, this essentially leads to purpose-specific ‘variations’ of the same original generic modelling language (differing in their syntactic and semantic restrictions). The notion of purpose-specific modelling language is certainly related to the notion of domain-specific languages [5, 12]. We argue, however, that the intended usage of the model also has a key role to play in tuning modelling languages to the needs at hand. We also acknowledge the fact that the notion of model purpose is related to the notion of model quality [13, 9]. We will revisit this relationship in the remainder of the paper. It is also important to realize that model purpose is different from modelling purpose [13, 9]. The purpose of a model is indeed dependent on the modelling purpose, but we see them as being different phenomena. In this paper, we limit our discussions to model purpose. Since all of the models of an enterprise modelling landscape provide different views on the same enterprise, it is quite natural (and in line with an engineering perspective) to expect that the sets of models form a coherent whole; i.e. linked where relevant and con- sistent as a whole. Having such coherence among models also enables cross-cutting and impact of change analysis, traceability analysis, etc. So, while using purpose-specific modelling languages has clear benefits in terms of suitability of the language (and mod- els) to a purpose at hand, there is also a potential downside to it. A plethora of purpose- Towards a coherent enterprise modelling landscape 3 specific models can easily lead to a fragmentation of the modelling landscape; i.e. a break up of coherence, also addressed as a “Tower of Babel situation” [14]. This leads to a natural polarity between coherence and purpose-specificity. A number of strategies has been suggested to achieve integrated use of models and languages used in enter- prise modelling, e.g. [5, 15]. We argue that this polarity deserves careful management, but first and foremost requires more research to better understand the forces at work. In this paper, which is the result of an ongoing research, we present our current understanding of fundamental challenges related to coherent enterprise modelling land- scapes. We will start in Section 2 by exploring the polarity between coherence and purpose-specificity in more detail, with the aim of gaining a better appreciation of the forces that are involved. We will then continue in Section 3 by exploring some of the existing strategies to manage this polarity. This discussion is then used as a base to develop the first-most elements of a theory on managing the coherence of modelling landscapes in Section 4. 2 Fragmentation of enterprise modelling landscapes As already discussed, enterprise modelling is likely to involve a plethora of purpose- specific models covering different aspects of the enterprise. At the same time, the di- versity of models/languages increases the risk of fragmenting the modelling landscape. This section explores the forces having a potential fragmenting effect on the modelling landscape, by taking two main ingredients of a model’s purpose as a starting point. We discuss our current understanding of the “fragmenting forces”, as exerted by each of these ingredients respectively. 2.1 Domain-specificity based fragmentation The perspective from which the enterprise is to be modelled is a major force of poten- tial fragmentation. When modelling enterprises, several dimensions exist in which to identify distinct domains (aspects, viewpoints, perspectives) to model. This potentially leads to even so many domain-specific models and languages. To illustrate the diversity, without having the ambition yet to provide an orthogonal set of dimensions, consider the following possible dimensions: Intervention design – This concerns the motivation/rationalisation of a desired inter- vention3 (e.g. transformation or development effort) in an enterprise. Examples of dif- ferent models along this dimension include: – Models capturing the goals/motivations for changing the existing enterprise. – Models capturing the requirements on the desired (direction of) change of the enter- prise. 3 Note that since an enterprise is a socio-technical system that, by its nature, has a tendency to change due to the initiatives of the humans that ultimately make up the enterprise, we prefer to use the term intervention rather than system development or even implementation. The term intervention more clearly signifies the fact that an enterprise is not just a technological artefact. 4 Marija Bjeković et al. – Models (plans) of an intervention in the current enterprise to change it in the desired direction. Within the plans for the intervention, one may also distinguish between different time horizons. In other words, what one might want to achieve in the next year, in five years from now, and beyond. Enterprise design – This dimension deals with the motivation/rationalisation of the (existing/planned) design of an enterprise. In this dimension, one could for example distinguish between: – Models capturing the goals/motivation for owning/using the (parts of the) enterprise. – Models capturing the requirements on the enterprise that follow from this. – Models capturing the design of the enterprise (meeting the requirements). Design domains – This dimension concerns the domains that are considered relevant to the design of an enterprise, e.g. Zachman framework cells [4], the distinction between different levels of implementation specificity in Capgemini’s Integrated Architecture Framework [16], the distinction between business, application and technology layer in ArchiMate [17] and TOGAF [18], etc. This dimension also includes ‘cross cutting’ domains such as security and governance as in e.g.[16], and different ‘projections’ on design aspects relevant to specific concerns/stakeholders using viewpoints [11]. Granularity – This concerns different granularities at which one might want to model parts of the enterprise. Depending on the specific aspect of the enterprise, different ways to identify levels or granularity might be relevant. For example, in the case of process modelling, one could distinguish: – Level of key processes, without any triggering relationships between them. – Level of major sub-processes, with some overall triggering relationships. – Level of specific work tasks, with complete triggering relationships, including splits and joins. Governance domains – This concerns the domains from which an enterprise wants to govern itself. As argued in the GEA [7] , these are not the same as the design do- mains. The design domains are typically formulated from an “engineering” perspective (blueprint thinking), while the governance domains are formulated more from an or- ganizational and political perspective, e.g. human resourcing, compliance, acquisition, marketing, etc. These dimensions are also highly organization specific. 2.2 Usage-specificity based fragmentation Models are created with an intended usage in mind, e.g. analysis, sketching, contract- ing, forecasting, simulation, execution, etc. The intended usage of the model by some audience will have a direct impact on the requirements on the modelling language used to capture the model [19, 8]. This invites more variety in models/languages used, adding to the potential fragmentation of modelling landscape. We suggest to identify: Restriction of notation – refers to the level of restriction that is put on the notation that can be used to represent the model on a medium. The medium itself can for example be restricted to a specific form, such as graphical, textual, or video, but the notation in general can also be restricted in terms of fonts, icons and layout rules. See [20] for the role of notation in modelling. Towards a coherent enterprise modelling landscape 5 Restriction of syntax – concerns the level of syntactic restrictions that may be put for- ward by the modelling language used. For example, one might consider “free format” drawings or text on one hand, and UML diagrams or text-based specification languages on the other extreme. Restriction of semantics – refers to the extent to which a language is to be used with (an enforced!) formalized semantics. Formality in this context refers to the fact that the modelling language (graphical or textual) has an underlying semantics in some mathe- matical domain. See e.g. [21] for an elaborate discussion of formalizing the semantics of modelling language, and its relationship to the purpose of the models. 3 Managing coherence in enterprise modelling Different strategies can be used to manage this potential fragmentation of the modelling landscape. In this section we discuss some of the strategies suggested in the literature, as well as their involved trade-offs. 3.1 Unified language A classical approach to enable integrated modelling of the enterprise would involve relying on an all-encompassing and unified modelling language, to integrate all the rel- evant perspectives on the enterprise. This approach essentially boils down to preventing the fragmentation from occurring in the first place: it involves a single and stable lan- guage with an a priori defined set of concepts and their links, to be used uniformly. This would also lead to the standardisation of the language, i.e. vocabulary used for mod- elling, which in turn should facilitate knowledge transfer and communication about the system being engineered. Such a line of reasoning can for instance be observed in the definitions of UML [10] for software design modelling, or ArchiMate [17] for enterprise architecture modelling. However, in the context of enterprise modelling, the feasibility of a unified language ap- proach is questionable. First of all, it is nearly impossible to a priori identify which do- mains (and modelling concepts) should be part of an integrated language for enterprise modelling. Furthermore, the relevance of different domains is also highly situation- dependent. For example, different perspectives may be relevant for different enterprises, or even in different transformation projects of the same enterprise, or new perspectives may become relevant as the result of the evolution of the enterprise. A language such as ArchiMate was designed [11] to deal with this by enabling users to define their own viewpoints; i.e. essentially purpose-specific modelling languages where the model (the “view”) is derived from the unified/integrated model. At the same time, however, one can see how there is a drive for the ArchiMate language as a whole to be extended with additional domains, the move from the ArchiMate 1.0 standard to the ArchiMate 2.0 standard [17] included two additional domains (motivation and migration). Further integration between TOGAF and ArchiMate is likely to lead to even more extensions, while extensions dealing with e.g. value modelling, are also considered. Where will it stop? 6 Marija Bjeković et al. Secondly, in dealing with an enterprise, one has to acknowledge the heterogene- ity of communities and their (sub)languages [22, 23]. In such a context, imposing the single unified language for modelling the enterprise is likely to cause the conceptual misunderstandings around the resulting models, and a lot of time and effort would have to be put in resolving them. 3.2 Federated languages A more flexible strategy results when allowing the co-existence of different modelling languages to model different perspectives on an enterprise. Essentially, this approach acknowledges the benefits of focused modelling languages for particular purposes. The integration strategy here consists in seeking to establish the links between these dif- ferent languages and models used, in general having the ambition of interoperability of modelling languages at syntactic and semantic levels. For example, the MEMO [5] framework provides a common meta-language (i.e. the MEMO meta-metamodel) for all the special purpose modelling languages. Any special purpose language can be included in the framework, once it is expressed in the common meta-language. The integration of languages is achieved by their sharing of common conceptual foundation. The Unified Enterprise Modelling Language (UEML) [15] has the ambition of mak- ing languages definitions semantically interoperable, and in that way facilitate the inte- grated use of models in enterprise modelling. While it also allows the inclusion of new modelling languages in the framework, this approach requires full formal precision of all the enterprise modelling languages, regardless of the purpose they are intended for. The core of the UEML approach lies in a common and evolving ontology [24], in which the modelling constructs of the modelling languages are to be precisely described This approach focuses on precisely describing (only) the type semantics [25] of the language constructs based on their specifications. However, as already discussed, one can ob- serve the existence of different purpose-specific syntactic and semantic variations of the same original generic modelling language. It is our belief that the pragmatics of languages, and not only their specifications, should be considered within the efforts to integrate languages and models. We discuss these concerns in more detail in Section 4, motivating the need for its further research. Even when using a common language to express the syntax and semantics of each language, bridges between the different languages and models still need to be built. To enable the creation of such bridges between modelling languages, it has been suggested in [26] to use ontologies. The approach outlined in [25] suggests using ontologies to make the inherent semantics [25] behind the language and model constructs explicit, and that way considerably reduce mapping complexity and ambiguity. 3.3 Family of languages One can take this idea of using a common ontology a step further, by (re)designing the different purpose-specific modelling languages as specializations of a common generic meta-model. This leads to an approach in between the unified languages and federated languages approaches, which might be called a family of languages. Note that such a Towards a coherent enterprise modelling landscape 7 generic meta-model is not a meta-meta-model. It is a generalized meta-model, where the meta-models of more specific languages can be seen as specialization/refinements of the generic meta-model (i.e. not as instantiations of a meta-meta-model). The idea of using a generic meta-model is akin to older work on the so-called meta-model hier- archy [27], which has also inspired the hierarchy in the meta-model of the ArchiMate language [28]. 4 Towards a theory for coherent modelling landscapes In this section, we develop the first elements of an explanatory theory that aims to gain better insight into the needs and challenges underlying the use of different models/languages in enterprise modelling. We first explore the dimension of domain- specificity in 4.1, by analysing the interplay between domain concepts and normative re- strictions on the modelling languages. In 4.2, we discuss the relation between purpose- based model/language tuning, model quality dimensions and identified dimensions of fragmentation. 4.1 Modelling domain and modelling language To support this analysis, we introduce the matrix as shown in Figure 1. The horizon- tal dimension of the matrix corresponds to the openness to different interpretations of the domain concepts, i.e. (natural language) concepts used to communicate about the domain. Its extremes are defined as: Open – where multiple interpretations of the domain concepts are possible. This is typically the case in domains with heterogeneous communities, whose practise and use of language differs significantly, resulting in different environments of discourse within the domain [29]. Normative – where there is a single (allowed) interpretation of domain concepts. Typ- ically, domain concepts are defined within the normative documents. For example, in the insurance sector, standardized definitions of the insurance concepts exist within the i.e. Business Glossary4 , and are intended to be used as the basis for communication be- tween industry partners, in the development of services, architectures and applications etc. The vertical dimension of the matrix represents the scale of normative restriction of modelling language. We define the extremes on this scale as follows: Open – with modelling language not being restricted a priori, but being constructed along the process of domain modelling. Normative – refers to the modelling languages whose both syntax and semantics are formally defined in a mathematical language, resulting in one possible interpretation of the modelling language constructs. 4 http://acord.org/resources/framework/Pages/default.aspx 8 Marija Bjeković et al. Normative GPMLs DSMLs Modelling language definition Open Open Normative Domain concepts Fig. 1. Language construction view As already discussed, there is a natural drive towards using domain-specific mod- elling languages (DSML) in enterprise modelling [12]. Essentially, by incorporating specific concepts tuned to modelling particular problem domains, the ambition of DSMLs is to foster modelling productivity, facilitate the understanding of the mod- els by the stakeholders and increase the overall (in particular semantic and pragmatic) quality of the resulting models. By incorporating domain concepts into modelling lan- guage definition, more semantic precision is intended to be given to the language con- structs. However, as discussed in [12], the conception of a DSML is bound to complex challenges and contingent decisions, and the level of specificity of the language is a matter of trade-off with the reusability of DSML in different contexts. The more spe- cific DSML is, the more semantic precision it will have, the fewer the number of areas it can be applied to [12]. At the same time, this will increase its conceptual clarity within the intended domain of use, i.e. it will increase the quality model’s of socio-cognitive interpretation [9]. DSMLs can be defined and used at various levels of formality, e.g. as semi-formal and visual [5], or executable [30]. The formality of the DSML is a means to improve the quality of technical interpretation [31] of the resulting models. This immediately suggests that the (required) formality of the DSML depends on the intended usage of the resulting models, as will be discussed later. However, besides DSMLs, rather general-purpose modelling languages (GPML) such as i* [32], e3Value [33] or UML [10] are also used in enterprise modelling prac- tises. They are usually more expressive, but at the same time less suitable than DSMLs in dealing with specific problem domains. The concepts of a GPML are rather generic and their meaning may vary across different contexts of the language use. For example, a modelling language such as i* [32] can be used for modelling strategic goals of actors in relation to the system, but also to express information systems requirements. In each of these contexts, the inherent semantics of e.g. the modelling construct actor will vary: when modelling strategic goals of enterprise, actor can only be a human actor, while in the context of modelling software requirements, a machine may be an actor as well. Towards a coherent enterprise modelling landscape 9 This context-dependent semantic variation of GPML concepts is to be determined by taking into account the context of its use, i.e. purpose. Following these discussions, we position DSMLs across the cells on the right side of the matrix, and GPMLs across the cells on the left side of the matrix. The boundary between a GPML and a DSML is not as straightforward, but what clearly distinguishes these two families is the ambition of DSMLs to exclude as much as possible the po- tential different interpretations of the domain concepts incorporated in the language. While DSMLs offer advantages of zooming in a particular domain with its specific concepts, they also come with the cost, since they emphasize particular terminologies, do not facilitate cross-domain communication, and exert the fragmenting effect on the enterprise modelling landscape. On the other hand, GPMLs are easier to reuse for mod- elling different domains, however the interpretation challenge of the models expressed in GPMLs is more pronounced. 4.2 Model purpose and model quality The purpose for which the model is to be used influences the requirements on the in- formation conveyed by the model, but also the way the it should be represented for its intended audience). Therefore, there is a clear connection between the notions of model purpose and model quality [13, 9]: for a given purpose, different dimensions of model quality are emphasized. This in turn implies different requirements on the modelling language(s) to be used, which ideally is tuned to the purpose at hand. More specifically, in terms of the SEQUAL framework [13], we see the following relationships between the model quality dimensions and the identified purpose dimen- sions, which we discussed in Section 2: Physical quality – links directly to the restriction of notation dimension, more specif- ically referring to the actual medium that is to be used. Empirical quality – also links to the restriction of notation dimension, though refer- ring more to the way the notation is used, e.g. in terms of comprehensibility and read- ability. Syntactic quality – links directly to the restriction of syntax dimension. Semantic quality – links directly to the restriction of semantics dimension. Perceived semantic quality – covers the correspondence between actors’ interpreta- tion of the model and their current knowledge of the domain. The actor’s interpretation of the model will be influenced by a priori choice of the domain and restrictions on notation, syntax, or semantics, in particular if they support the actor’s prior knowledge and abilities to understand model’s representation. Pragmatic quality – as the correspondence between the model and its interpretation by the audience links to the spectrum of usage-specific fragmentations. Combined they enable or restrict the freedom of modellers to influence the pragmatic quality of models. In this regard, as argued in [9], we find it useful to distinguish between the quality of socio-cognitive interpretation and the quality of technical interpretation, as language restrictions are differently combined to meet these qualities. 10 Marija Bjeković et al. Social quality – is not linked directly to model purpose dimension, in our view, but embedded more in the process of modelling, and therefore linked to the modelling purpose. Organisational quality – is in our view linked mainly to the domain-specificity di- mensions, determining the primary goal of modelling in capturing some domain in terms of a model. We illustrate these considerations with several more or less typical model purposes within enterprise modelling: Collaborative domain modelling in a heterogeneous community – This variation of domain modelling is typical for the domains with heterogeneous communities, whose practice and use of language differs significantly, resulting in different environments of discourse within the domain [34, 22]. The focus of the modelling process in this context is on reaching conceptual clarity and consensus between participants and the gradual construction of a shared conceptual model. However, given the terminological heterogeneity within the domain, the consensus on the entire vocabulary would not be realistic, so concepts’ definitions are not likely to have a normative character. Given the focus on reaching common understanding and agreement, the aspects of the model such as syntactical correctness will be less relevant, therefore, informal and semi-formal modelling notations would be sufficient for this purpose. Stakeholder communication – In this context, the models are intended to provide var- ious stakeholders with needed insight in issues/problems at hand, and aid in human decision-making. As typically these stakeholders do not have an engineering back- ground, there is a clear preference towards graphical and rather informal or ‘box-and- line style’ representations [35]. On the other side, the focus on semantic precision of domain concepts used in models is strong, and to avoid misunderstandings, ideally the concepts (and notation) stemming from the stakeholders’ professional background would be used. This clearly indicates the tendency towards domain-specificity, i.e. the focus on semantic and pragmatic quality of models. Model execution – When the model is intended to be directly executable by tools (e.g. specification of the software system), what matters the most is its formality, therefore the focus is on syntactic and semantic quality of the model. The corresponding mod- elling language therefore should be a formal one, covering at least execution semantics for the model, e.g. [30, 36]. Given that these models are to be used both by human users and machines, the corresponding languages may also combine both textual and visual notations e.g. [30]. However, they need not necessarily be domain-specific. 5 Conclusion In this paper we explored the issues involved in assuring the coherence of enterprise modelling landscapes. We argued that while there is a clear need to have coherence among the set of models used to represent different aspects of the same (version of) an enterprise, the purpose-specificity which enables the tuning of models (and languages) to the purpose at hand, has a fragmenting effect on the modelling landscape. We con- cluded that the polarity between coherence and purpose-specificity should therefore be Towards a coherent enterprise modelling landscape 11 managed carefully. In this context, we discussed some of the existing strategies to reach integrated use of models and languages in enterprise modelling, including their trade- offs. Finally, we sketched some elements of an explanatory theory to better understand the use of enterprise models/languages at various level of domain- and usage-specificity. As a next step, we aim to further develop the latter theory, where we will initially focus on model purpose, but in later versions also involve modelling purpose in the equation. With such an explanatory theory in place, we can then endeavour to develop heuristics to balance the needs for purpose-specificity of models and the need for coherence. Acknowledgement. This work has been partially sponsored by the Fonds National de la Recherche Luxembourg (www.fnr.lu), via the PEARL programme. References 1. Dietz, J.: Enterprise Ontology – Theory and Methodology. Springer, Berlin, Germany (2006) 2. Op ’t Land, M., Proper, H., Waage, M., Cloo, J., Steghuis, C.: Enterprise Architecture – Creating Value by Informed Governance. Enterprise Engineering Series. Springer (2008) 3. Wood–Harper, A., Antill, L., Avison, D.: Information Systems Definition: The Multiview Approach. Blackwell, Oxford, United Kingdom (1985) 4. Zachman, J.: A framework for information systems architecture. IBM Systems Journal 26(3) (1987) 5. Frank, U.: Multi-perspective Enterprise Modeling (MEMO) - Conceptual Framework and Modeling Languages. In: Proceedings of HICSS’02. Volume 3., IEEE (2002) 6. Winter, R., Fischer, R.: Essential layers, artifacts, and dependencies of enterprise architec- ture. Journal Of Enterprise Architecture 3(2) (2007) 7–18 7. Wagter, R., Proper, H., Witte, D.: A Practice-Based Framework for Enterprise Coherence. In: Proceedings of PRET 2012. Volume 120 of LNBIP., Springer (2012) To appear. 8. Proper, H., Hoppenbrouwers, S., Veldhuijzen van Zanten, G.: Communication of Enterprise Architectures. [11] 67–82 9. Bommel, P.v., Hoppenbrouwers, S., Proper, H., Roelofs, J.: Concepts and strategies for quality of modeling. In: Innovations in Information Systems Modeling. IGI Publishing (2008) 10. OMG: UML 2.0 Superstructure Specification – Final Adopted Specification. Technical Report ptc/03–08–02 (August 2003) 11. Lankhorst, M., ed.: Enterprise Architecture at Work: Modelling, Communication and Anal- ysis. Springer, Berlin, Germany (2005) 12. Frank, U.: Some guidelines for the conception of domain-specific modelling languages. In Nüttgens, M., Thomas, O., Weber, B., eds.: EMISA. Volume 190 of LNI., GI (2011) 93–106 13. Krogstie, J., Sindre, G., Jorgensen, H.: Process models representing knowledge for action: a revised quality framework. European Journal of Information Systems 15 (2006) 91–102 14. Vernadat, F.: UEML: Towards a unified enterprise modelling language. International Journal of Production Research 40(17) (2002) 4309–4321. 15. Anaya, V., Berio, G., Harzallah, M., Heymans, P., Matulevicius, R., Opdahl, A.L., Panetto, H., Verdecho, M.: The unified enterprise modelling language - overview and further work. Computers in Industry 61 (2010) 99–111 16. Van’t Wout, J., Waage, M., Hartman, H., Stahlecker, M., Hofman, A.: The Integrated Archi- tecture Framework Explained. Springer, Berlin, Germany (2010) 12 Marija Bjeković et al. 17. Iacob, M.E., Jonkers, H., Lankhorst, M., Proper, H., Quartel, D.: ArchiMate 2.0 Specifica- tion. The Open Group (2012) 18. The Open Group: TOGAF Version 9. Van Haren Publishing, The Netherlands (2009) 19. Hoppenbrouwers, S., Proper, H., Weide, T.v.d.: Understanding the Requirements on Mod- elling Techniques. In: 17th International Conference on Advanced Information Systems Engineering, CAiSE 2005. Volume 3520 of LNCS., Springer (2005) 262–276 20. Moody, D.: The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering. IEEE Transactions on Software Engineering Software Engineering 35(6) (2009) 756–779 21. Hofstede, A.t., Proper, H.: How to Formalize It? Formalization Principles for Information Systems Development Methods. Information and Software Technology 40(10) (October 1998) 519–540 22. Hoppenbrouwers, S., Bleeker, A., Proper, H.: Facing the Conceptual Complexities in Busi- ness Domain Modeling. Computing Letters 1(2) (2005) 59–68 23. van der Linden, D.J.T., Hoppenbrouwers, S., Lartseva, A., Proper, H.A.: Towards an in- vestigation of the conceptual landscape of enterprise architecture. In: BMMDS/EMMSAD. Volume 81 of LNBIP., Springer (2011) 526–535 24. Opdahl, A., Berio, G., Harzallah, M., Matulevicius, R.: Ontology for enterprise and infor- mation systems modelling. Applied Ontology 7(1) (2012) 49–92 25. Karagiannis, D., Höfferer, P.: Metamodels in action: An overview. In Filipe, J., Shishkov, B., Helfert, M., eds.: ICSOFT (1), INSTICC Press (2006) 26. Brinkkemper, S., Saeki, M., Harmsen, A.: Meta-modelling based assembly techniques for situational method engineering. Information Systems 24(3) (1999) 209–228 27. Falkenberg, E., Verrijn–Stuart, A., Voss, K., Hesse, W., Lindgreen, P., Nilsson, B., Oei, J., Rolland, C., Stamper, R., eds.: A Framework of Information Systems Concepts. IFIP WG 8.1 Task Group FRISCO, IFIP (1998) 28. Lankhorst, M., Proper, H., Jonkers, H.: The anatomy of the archimate language. International Journal of Information System Modeling and Design (IJISMD) 1(1) (2010) 1–32 29. Hoppenbrouwers, S.: Freezing Language; Conceptualisation processes in ICT supported organisations. PhD thesis, University of Nijmegen, Nijmegen, The Netherlands (2003) 30. Kleppe, A.: Towards general purpose, high level, software languages. In: ECMDA-FA. Volume 3748 of LNCS., Springer (2005) 220–238 31. Bommel, P.v., Hoppenbrouwers, S., Proper, H., Weide, T.v.d.: QoMo: A Modelling Process Quality Framework based on SEQUAL. In: Proceedings of the 12th Workshop on Exploring Modeling Methods for Systems Analysis and Design (EMMSAD’07), held in conjunctiun with the 19th Conference on Advanced Information Systems (CAiSE’07), Trondheim, Nor- way, CEUR Workshop Proceedings (2007) 118–127 32. Yu, E., Mylopoulos, J.: Using goals, rules, and methods to support reasoning in business process reengineering. International Journal of Intelligent Systems in Accounting, Finance and Management 5(1) (1996) 1—13 33. Gordijn, J., Akkermans, H.: Value based requirements engineering: Exploring innovative e-commerce ideas. Requirements Engineering Journal 8(2) (2003) 114–134 34. Proper, H., Hoppenbrouwers, S.: Concept Evolution in Information System Evolution. In: Proceedings of CAiSE 2004. (2004) 63–72 35. Malavolta, I., Lago, P., Muccini, H., Pellicone, P., Tang, A.: What industry needs from architectural languages: an industrial study. Technical report, University of L’Aquilla (2012) 36. OMG: Semantics of a foundational subset for executable uml models (fuml), v1.0. Technical report, OMG (2011)