Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 A Deep Perspective on the ArchiMate Modeling Language and Standard 1
A Deep Perspective on the ArchiMate Modeling Language and Standard
Colin Atkinson*,a, Thomas Kühneb a University of Mannheim, Germany b Victoria University of Wellington, New Zealand
Abstract. Given the scale, complexity and variety of enterprise architectures, approaches for modeling them need to be as simple and flexible as possible in order to minimize the accidental complexity within enterprise architecture models. Multi-level modeling techniques offer an effective way of achieving thisbut to date there has been little research into how they could contribute to enterprise architecture modeling. In this article we therefore explore how the former could be best leveraged within the latter by considering the modeling goals, architecture and principles of one of the most concrete and widely used enterprise architecture modeling standards: ArchiMate. More specifically, we discuss how the conceptual integrity of the ArchiMate standard and modeling experience could be enhanced using multi-level modeling principles. In our discussions, we focus on a specific variant of multi-level modeling, called deep modeling, whichis based on the notions of orthogonal classification and deep instantiation.
Keywords. Enterprise Architecture Modeling • Multi-Level Modeling • Deep Visualization • ArchiMate
Communicated by Ulrich Frank. Received 2017-03-01. Accepted on 2019-09-08.
1 Introduction need to have a broad scope and be able to por- tray enterprise architectures in the large variety of Enterprise Architectures play a pivotal role in forms expected by their many different stakehold- enabling companies to align their processes with ers. In other words, they need to be multi-view their IT infrastructures. With the increasing trend approaches which allow an enterprise architecture towards digitization and automation, companies and/or its parts to be described from multiple view- need effective enterprise architectures to remain points using a suite of different (sub)languages. competitive and respond rapidly to change. Poorly In addition, given the large number of different understood and/or aligned processes, information kinds of stakeholders and tasks that EA models in systems and IT infrastructures significantly reduce different companies need to support, it is impor- a company’s ability to respond agilely to change tant that EAM frameworks allow new view types and deliver services in a cost-effective way. and view-representation languages to be added by In general, the notion of “Enterprise Architec- users (Frank 2002). Defining a single language ture” (EA) encompasses all aspects of a company’s framework to support all view languages needed assets, relationships, stakeholders and processes out-of-the-box is not a realistic proposition. over its entire lifetime, from inception and design Several EAM approaches have become de to operation and retirement. Approaches for En- facto standards over recent years. Some, such as TOGAF (The Open Group 2010) and Zach- terprise Architecture Modeling (EAM) therefore mann (Zachman 1987), do not prescribe the spe- * Corresponding author. cific languages to be used to portray information in E-mail. [email protected] different kinds of views (e. g., processes, data types Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 2 Colin Atkinson, Thomas Kühne
etc.) while others, such as RM-ODP (ISO/IEC • promotes adaptability of models, and 1997) and ArchiMate (The Open Group 2017a), • helps to protect the integrity of models. define their own specialized languages to repre- sent their specific view types. However, only one In combination, the above aid the maintainability of these, ArchiMate, explicitly encourages the of models and thus lower typical maintenance definition of new viewpoints and language vari- costs, as mistakes that are often provoked by overly ants by end users through a dedicated “extension” complex models and may be costly to fix, can be mechanism. avoided in the first place. Of the well-known EAM standards, therefore, In this article we specifically aim to reinforce ArchiMate may be regarded as the most advanced the arguments for multi-level modeling in the in terms of supporting viewpoint/language engi- domain of EAM by investigating how a multi- neering. However, like most modeling environ- level framework could better support the modeling ments today, the ArchiMate approach to modeling goals and principles outlined by the ArchiMate and language engineering is rooted in modeling standard (The Open Group 2017a) and its design- infrastructure principles that go back to the first ers (Lankhorst 2013; Lankhorst et al. 2010). As generation of modeling tools. In particular, its part of this investigation we are interested in the definition and use is based on the traditional four way the ArchiMate language is defined as well level hierarchy popularized by the UML infrastruc- as used. We focus on ArchiMate for this study ture (Object Management Group 2007), where the because (a) it includes one of the most compre- bottom level is considered to be the “real world” hensive and well-defined languages and (b) it is and the top two levels are language definitions, defined as a meta-model in a publicly available i. e., a language for defining modeling languages standard. (i. e., the meta-meta model) and a language for The remainder of this article is organized as defining EA models (i. e., the ArchiMate meta follows. In the next section we provide an introduc- model). This leaves only one level to accom- tion to ArchiMate and summarize the language modate all domain modeling content, including designers’ explicitly stated goals in relation to instances, classes and potentially domain meta viewpoint language usage and definition. After classes. that we provide a general introduction to multi- Numerous authors have pointed out that multi- level modeling, followed by a description of the level modeling environments generally offer a specific variant we use in this article known as better platform for flexible, domain-specific lan- deep modeling (Atkinson and Kühne 2003). The guage engineering than two-level modeling envi- following two sections then analyze the pros and ronments (Atkinson and Kühne 2003). Frank, in cons of deep modeling approaches in terms of the particular, has specifically made this case in the requirements outlined in the ArchiMate standard context of EAM by clarifying the requirements and by its designers. Sect. 4 does so in terms EAM languages should support and developing of the underlying concepts involved in language a new prototype EAM modeling environment to definition and use (i. e., the abstract syntax) while showcase the benefits of multi-level modeling in Sect. 5 does so in terms of the presentation (or this domain (Frank 2014). visualization) of those concepts. Sect. 6 then The use of multi-level modeling holds the continues by considering how, in the context of promise of economic benefits (Frank 2016) due ArchiMate, deep modeling could provide support to reducing accidental complexity (Atkinson and for other desirable modeling features identified by Kühne 2007), which Frank and others, but not yet included as explicit • minimizes the effort involved in understanding goals of ArchiMate. Sect. 7 concludes with final and changing models, remarks and observations for future work. Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 A Deep Perspective on the ArchiMate Modeling Language and Standard 3
2 ArchiMate Language Goals Passive Behvior Active Structure Structure
ArchiMate is an EAM standard managed by the Business Layer Open Group, a vendor and technology-neutral in- dustry consortium that manages a wide range of Application Layer open standards. The Open Group characterizes Layers ArchiMate as “. . . the standard visual language for communicating and managing change and Technology Layer
complexity through architecture descriptions de- } velopment Aspects } ” (The Open Group 2017b). It is com- plemented by the TOGAF standard (The Open Figure 1: ArchiMate Core Framework (The Open Group 2010) which provides a broader picture Group 2017a) of how to create, evolve and leverage enterprise architectures in a disciplined way. This article focuses on ArchiMate version 3.0 released in June period of years based on user experience and re- 2016 (The Open Group 2017a). search. Rather the goal of this article is to critique The main value of ArchiMate is the set of the architecture of the language infrastructure and modeling concepts it provides for representing discuss whether the goals of the language de- different aspects of enterprise architectures from signers could be better satisfied using multi-level multiple viewpoints. These modeling concepts modeling. Thus, the focus is more on how the are organized in a two-dimensional “core frame- language is defined and what overall properties work”, illustrated in Fig.1. The rows of this figure, it exhibits rather than what it actually contains referred to as layers, represent the different levels in terms of abstract and concrete syntax. This of abstraction at which properties of the enterprise requires close scrutiny of the ArchiMate standard are described (business, application and technology), which constitutes the official definition of the lan- while the columns, referred to as aspects, repre- guage. In the following subsections we clarify sent the kinds of concepts used to represent that the main sets of goals outlined by the language information (passive structure, behavior and active designers. The standard itself does not devote a lot structure). These concepts, along with the rest of space to explaining ArchiMate’s concrete goals, of ArchiMate are defined by a metamodel in an instead it explicitly refers to other sources where a analogous way to the UML. full description of the ArchiMate language design ArchiMate also places a great deal of emphasis goals are described (Lankhorst 2013; Lankhorst on defining a “default iconography for describing, et al. 2010). analyzing, and communicating many concerns Overall, the language designer’s articulated of Enterprise Architectures as they change over three main kinds of requirements. These are time”. Most other open EAM approaches such as discussed in the following subsections. TOGAF and Zachman do not define any iconog- raphy while others such as RM-ODP do so in a 2.1 Conceptual Integrity limited way. ArchiMate is the only major EAM According to Lankhorst (2013) one of the core standard that attempts to define a comprehensive goals of the ArchiMate language is to maximize range of symbols specifically for modeling EAs the conceptual integrity of EA models. Brooks from multiple viewpoints using metamodel-based describes conceptual integrity as resulting from language engineering techniques. “simplicity and straightforwardness” and from en- It is not the goal of this article to critique the suring “unity of design” in which “every part must concrete EAM concepts defined in the ArchiMate reflect the same philosophies and the same bal- language which have been carefully refined over a ancing of desiderata” (Brooks 1975). Lankhorst Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 4 Colin Atkinson, Thomas Kühne
(2013) characterize conceptual integrity as “the – avoid ambiguity. degree to which a design can be understood by a – be brief (avoid unnecessary concepts and single human mind, despite its complexity” and relations). state that it has the following subordinate design – be orderly. principles: Of these, the fourth, “Maxim of Manner”, is the • orthogonality - do not link what is independent, most relevant to language design. As Lankhorst • generality - do not introduce multiple functions et al. point out, in order to avoid ambiguity and that are slightly divergent, ensure concepts can be “mapped easily to and • economy (aka parsimony) - do not introduce from those used in the project level” a strong what is irrelevant, relationship should exist between the modeling • propriety - do not restrict what is inherent. concepts used at the project level and those used in the enterprise architecture (Lankhorst et al. The core idea of simplicity and making the 2010). It is therefore important that the language language as “compact as possible” (Lankhorst et be “set up in such a way that project level model- al. 2010) is explicitly highlighted in the standard ing concepts be expressed easily in terms of the which states that: “the most important design more general concepts defined in the language restriction on the language is that it has been (e. g.„ by specialization or composition of general explicitly designed to be as small as possible, concepts)” (Lankhorst et al. 2010). but still usable for most Enterprise Architecture modeling tasks” (The Open Group 2017a). These 2.2 Customizability authors also explain that “similar things should The designers of ArchiMate faced the same be expressed in a similar way, using a simple dilemma as the designers of the UML when de- set of core concepts that are easy to learn and ciding what to include in the language standard understand” (Lankhorst 2013). since they both have huge numbers of users with Another set of principles that aim to maximiz- greatly diverging requirements. The ArchiMate ing conceptual integrity by ensuring “economy designers therefore took the same approach as of communication” are Grice’s Maxims (Grice the OMG by defining a small core language (to 1975): maximize conceptual integrity) accompanied by extension mechanisms to allow users to customize • Maxim of Quantity the language to their own domain-specific needs. – make your model as informative as necessary. However, in contrast to the UML, which only – do not make your model more informative has one built-in extension mechanism (the profile than necessary. mechanism), ArchiMate defines two: • Maxim of Quality 1. adding attributes to ArchiMate elements and relationships, and – do not model what you believe to be false. 2. specialization of elements and relationships. – do not model that for which you lack adequate evidence. The first is seen as essential for supporting spe- cial kinds of analyses on models and allowing • Maxim of Relevance more information to be communicated about the – be relevant (i. e., model things related to the model elements. This can be done at modeling modeling goal). time by a modeler (called user-defined customiza- tion), or it can be done when a modeling tool is • Maxim of Manner first configured for use (called pre-defined cus- – avoid obscurity of expression. tomization). The purpose of the second form of Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 A Deep Perspective on the ArchiMate Modeling Language and Standard 5
customization is “to define new elements or rela- tionships based on the existing ones” by logically defining subclasses of the model elements inthe predefined metamodel. The ArchiMate standard states that “specialized elements inherit the prop- erties of their generalized elements (including the relationships that are allowed for the element), but some of the relationships that apply to the specialized element need not be allowed for the generalized element”. The ArchiMate standard envisages that both forms of customization are defined using some kind of “profiling” mechanism such as the tex- tual profiling language described by Eertink etal. (1999) or the UML profiling mechanism. How- ever, the standard gives very little information about the precise nature of the mechanisms, and equivocates on whether, in the second case, the mechanism is meant to be exactly the same as the UML profile mechanism or just “similar”. For example it states that “A specialized element or relationship strongly resembles a stereotype as it is used in UML” (The Open Group 2017a, p. 111). Profiles are also described in extension packages that can be loaded and unloaded at modeling time as desired. Figure 2: Business Layer Notation (Excerpt of tab. 6 from The Open Group (2017a)) 2.3 Visualization Flexibility The extensions mechanisms discussed in the pre- vious section are concerned with extensions of well as the abstract syntax, but that they should the abstract syntax of the language (i. e., what “ideally” do so in a way that specializes the ex- information the extensions capture). However, isting notation. The standard also clarifies that the ArchiMate standard also envisages extensions the “default is the guillemet notation of UML for to the concrete syntax (i. e., how language con- stereotypes (‘«specialization name»’)” and that cepts are represented). For example, the standard other “options include specific icons, colors, fonts, states that the aforementioned profile mechanism or symbols.” is intended to make it possible to “define a spe- Fig.2 shows a summary of the built-in nota- cific notation to denote the specialization” (The tion used to represent the static structural and Open Group 2017a, p. 112). Moreover, it explains behavioral elements of the behavioral layer (an ex- that “new graphical notation could be introduced cerpt of tab. 6 from the ArchiMate Standard (The for a specialized concept, but preferably with a Open Group 2017a)). As can be seen from this resemblance to the notation of the generalized figure, model elements are either visualized by concept; e. g., by adding an icon or other graphi- (a) a single icon corresponding to the element’s cal marker, or changing the existing icon.” This type (the icon notation) or (b) a rectangle with the means that end users should be able to extend element’s type icon in the top right hand corner the iconography of the ArchiMate language, as (the box notation). This generic visual syntax, Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 6 Colin Atkinson, Thomas Kühne
however, is mainly intended for use by enterprise technologies usually hardwire their metamodels architects. Various end users (i. e., stakeholders of into their code (such as contemporary ArchiMate a system) are intended to use viewpoints offering tools), and thus reduces opportunities for exchang- domain-specific visualizations. ing, reusing and extending models. This in turn Although no semantics are formally assigned tends to lock users into particular vendor solutions to colors, in practice they are frequently used in leading to significantly higher costs and potential the standard to distinguish between the layers of platform migration changes in the future. the ArchiMate Core Framework as follows: One way of realizing such a level-agnostic mod- eling environment is through the Orthogonal Clas- 1. yellow for the Business Layer, sification Architecture (OCA) shown in Fig.3. 2. blue for the Application Layer, In such an architecture, all model elements are 3. green for the Technology Layer. typed by two types, their ontological type which In addition to colors, other notational cues can originates from the problem domain, and their lin- be used to distinguish between the layers. For guistic type which is defined in the deep modeling example, a letter such as ‘B’, ‘A’ or ‘T’ can be language. Another key ingredient of deep model- placed in the top-left corner of an element to ing is the notion of “potency” which essentially denote a Business, Application or Technology captures the “characterizing” power of concept over multiple classification levels. There are sev- element, respectively. The standard notation also eral deep modeling approaches offering slightly uses a convention based on the corners of symbols differing forms of potency. However, these dif- to distinguish element types. More specifically: ferences are irrelevant to the arguments presented 1. square corners indicate structure elements, in this article. For the purpose of presenting con- 2. round corners indicate behavior elements, crete examples in the rest of the article we used the 3. slanted corners indicate motivation elements. deep modeling variant developed by the authors of this paper. It supports three distinct variants 3 Deep Modeling of potency: clabject potency which establishes an upper bound on the instantiation depth of a clab- Deep modeling describes a family of modeling ject, attribute existence potency (aka “durability”) approaches that support seamless, level-agnostic which defines over how many instantiation levels modeling across an unlimited number of classifi- an attribute has to exist, and attribute value po- cation levels. The approach uses a linear hierarchy tency (aka “mutability”) which specifies over how of models in which the elements at one level many instantiation levels the value of an attribute are all instances of model elements at the next can be changed. Any instances created beyond level, organized according to the principles of that level must retain the value set at the lowest strict modeling (Atkinson and Gerbig 2016). As changeable level. a consequence, all classification levels are equally A schematic example of the use of the OCA is accessible to modelers for viewing and modifica- displayed in Fig.3 where linguistic classification tion, and changes made to one classification level is indicated by dotted arrows and ontological clas- are immediately available at all other classifica- sification is indicated by dashed arrows. Manager tion levels without the need for recompilation or in the middle level, O1, has Clabject as its linguistic re-deployment steps. type and ActorType as its ontological type. Note This flexibility brings additional economic ben- that Manager is not only an instance of ActorType efits beyond those provided by reduced model but also a type for Ann. This type/instance duality complexity and error proneness because it makes of model elements residing in the middle levels EAM modeling environments much more open motivates the term “clabject” - a portmanteau of and extensible. Tools based on two-level modeling the terms “class” and “object”. Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 A Deep Perspective on the ArchiMate Modeling Language and Standard 7
lead to improvements. In this section we start with the goal of conceptual integrity. As explained in the introduction, the definition and use of the ArchiMate core language essentially takes place in the context of a traditional two-level L 1 modeling platform or infrastructure. This is illus- O O O 2 1 0 trated schematically in Fig.4. The left hand side ActorType2 of this figure depicts a traditional modeling stack
L0 such as the MOF/UML as usually presented by the OMG (e. g., the UML Infrastructure specifi- cation (Object Management Group 2006, 2007)). W The two levels explicitly supported by ArchiMate are the two non-shaded levels in Fig.4. The up- Figure 3: Example of a Deep Model in an Orthogonal per of these two levels, labeled “Metamodel” is Classification Architecture the place where the abstract syntax of the core language is modeled using a language akin to The potency of a clabject can be displayed the MOF. It is called a “metamodel” because its next to its name as a superscript. ActorType has a instances are parts of a model. The lower of these potency of two allowing it to have (deep) instances two levels, labeled “Model”, is the level where end two ontological levels below it, in this case Ann. users of an ArchiMate modeling tool add their do- The potency of an instance of a type must be main content. Note that, in general, ArchiMate’s lower than the potency of the type, but cannot be model level is used to represent both domain types negative, so the clabject Ann, with potency zero, and domain instances. cannot have instances itself. The meta-meta model is not part of the Archi- Attribute and value potencies (i. e., mutabili- Mate language per se, it is the language used to ties) are displayed as superscripts next to attribute describe (i. e., model) the abstract syntax of the names and values respectively. In the case of Ac- ArchiMate language. Nevertheless, since it is torType, the name attribute has an attribute potency explicitly used in the standard to model the Archi- of two and a mutability of two. Hence, instances Mate language, it conceptually constitutes the top of ActorType instances (i. e., two levels down from of the stack of languages depicted on Fig.4, just ActorType) have to have name values and these as the MOF constitutes the top level of the OMG’s name values may differ. To minimize the amount four level modeling infrastructure. The role of the of information displayed in a deep model, deep meta-metamodel used in the ArchiMate standard modeling tools may apply elision rules for all is therefore exactly the same as the role of the MOF forms of potency. For example, one approach is in the UML specification, even though it is not ex- to display attribute potency (i. e., durability) only plicitly represented in the ArchiMate standard or when it is not equal to the potency of the clabject documentation. In fact, the ArchiMate meta-meta containing the attribute and to display mutability model appears to be a simplified version of the only when it is not equal to the durability. MOF. Level contents at both the model and metamodel 4 Conceptual Integrity in ArchiMate levels of the ArchiMate modeling infrastructure In the next three sections we consider how well are represented using concepts which originate ArchiMate’s core language and architecture satis- from the same underlying object-oriented model- fies the requirements discussed in section2 and ing principles that underpin the UML, and thus investigate whether multi-level modeling could also the MOF - namely, the concepts of classes Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 8 Colin Atkinson, Thomas Kühne
Figure 4: ArchiMate Modeling Infrastructure
(whose “standard” presentation is roughly a rect- working with ArchiMate. This leads to the first, angle), specialization/generalization (whose “stan- language duplication issue: dard” presentation is an arrow with a triangle The ArchiMate language (i. e., metamodel) is head), and associations of various kinds (whose defined using a language (i. e., meta-metamodel) “standard” presentation is a line annotated with which appears to have “very similar” core features certain symbols to provide particular meanings). to the language itself (i. e., classes, associations, We can therefore observe that the ArchiMate meta- inheritance etc.). However, the meta-metamodel is modeling language and modeling language are not explicitly defined in the ArchiMate standard or based on the same foundation. literature. The ArchiMate standard therefore faces a situation similar to that which existed between 4.1 Language Duplication the MOF and UML before the OMG’s initiative Although the ArchiMate standard makes no refer- to align them in the 2.0 versions of the languages. ence to the language used to define the metamodel, In the worst case, features in the meta-metamodel the fact that the metamodel is explicitly modeled may only be “similar” to, but not exactly the same in the standard using an object-oriented model- as, corresponding features in the metamodel (e. g., ing language means that, conceptually at least, specialization) leading to confusion and errors. there is an additional level above the ArchiMate Ideally, the semantics of corresponding features metamodel describing the language used to define should therefore be “aligned”, as with the UML it. In Fig.4 this is referred to as the meta-meta core and MOF since UML 2.0, but there is cur- model. Although the ArchiMate standard only rently no indication that this is intended to be the refers to, and only intends tools to support, the case in the ArchiMate standard. Either way, the middle two levels, ArchiMate users must at least conceptual integrity of the standard is compro- conceptually be aware of all four levels when mised. At the very least, when there is alignment, Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 A Deep Perspective on the ArchiMate Modeling Language and Standard 9
the infrastructure fails to live up to the spirit of an insurance application process may result in a minimality and unity of design that underpins con- specific instance of the insurance policy business cept integrity, and in the worst case, when there object, but that is not modeled in the Enterprise is no alignment, two of the aspects of the Maxim Architecture”. of Manner - avoiding “ambiguity” and avoiding An analysis of the examples in the standard “unnecessary concepts and relationships” - are shows that, across all levels, behavior and pas- directly contradicted. One of the four subordinate sive structure views indeed typically show types. principles of conceptual integrity identified by However, active structure views typically show Lankhorst et al. (2010) explicitly warns against instances and there are many examples of models introducing “multiple functions that are slightly that contain a mixture of types and instances. In divergent”. general, ArchiMate is rather relaxed about the dif- The deep modeling approach naturally ad- ference between instances and types and how they dresses this issue because the OCA can be used may be mixed in a domain model. The standard to unify the definition of these common concepts even explicitly states (sect. 8.2.1) that “Business and make them available at both the metamodel actors may be specific individuals or organiza- and model levels, as shown in Fig.5. In this fig- tions; e. g., ‘John Smith’ or ‘ABC Corporation’, ure, instead of a meta-meta model which defines or they may be generic; e. g., ‘Customer’ or ‘Sup- the MOF-like modeling feature just for the meta- plier’”. An example model illustrating this is model level, a level-spanning linguistic model (or shown in Fig.6 (Example 22 from the standard). “metamodel”) exists which defines the concepts Here Travel Insurance Claims Analyst, Home In- for use in both the metamodel and model levels. surance Product Specialist and Customer Service This not only avoids redundancy, it ensures, and Representative are clearly types since they all in- explicitly declares, that a given linguistic concept herit from Specialist, while Greg, Joan and Larry has the same meaning at both levels. Thus, the are individuals. Although the latter are clearly two left-hand levels in Fig.5 are guaranteed to instances of the former the assignment relation- have the same semantics for the common elements ships used to connect them in the model does not they share (i. e., classes/object, inheritance, asso- convey classification, but rather the assignment ciations/links, attributes/slots) because they are of responsibilities. Finally, all the structural el- defined in the single, overarching linguistic model. ements in the model (both types and instances) Moreover, there is no need for a meta-meta model are regarded as instances of the same metamodel at the top of Fig.4 because this role is performed element - Active Structure Element. ArchiMate by the linguistic model. therefore has a type/instance ambiguity issue: It is not, in general, clear whether a model 4.2 Type/Instance Ambiguity element in an ArchiMate model (i. e., at the model Sect. 3.6 of the ArchiMate standard states that level in the infrastructure) represents an instance “The ArchiMate language intentionally does not or a type in the domain. Moreover, types and support a difference between types and instances. instances can be mixed and interrelated in uncon- At the Enterprise Architecture abstraction level, trolled ways. This lack of discrimination directly it is more common to model types and/or exem- conflicts with the Maxim of Manner (avoid ambigu- plars rather than instances. Similarly, a business ity) and the propriety subprinciple of conceptual process in the ArchiMate language does not de- integrity which warns against restricting “what is scribe an individual instance (i. e., one execution inherent”. In Fig.6 the most natural (i. e., inher- of that process). In most cases, a business object is ent) relationship between the types and instances therefore used to model an object type (cf. a UML is “instance of” but there is no way of representing class), of which several instances may exist within such “ontological” instance of relationships in the organization. For instance, each execution of ArchiMate. Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 10 Colin Atkinson, Thomas Kühne
Figure 5: OCA Core Language Definition (Atkinson and Kühne 2003)
distinction between types and instances also means that modeling well-formedness constraints may not apply as intended. For example, sect. 5.4.1 of the specification statesA “ specialization relation- ship is always allowed between two instances of the same element”, where “element” here refers to a metamodel element such as Business Actor. However, since instances of Business Actor can also be individuals (i. e., uninstaniatable objects) Figure 6: Example Business Active Structure Ele- in the domain of discourse (e. g., Greg, Joan and ments (The Open Group 2017a, Example 22) Larry in Fig.6) this rule unintentionally enables specialization relationships between individuals. Note that while most two-level approaches, Mixing instances and types in the same level is such as the UML, strictly separate instances (as not a problem per se as long as the types of the modeled by objects) from types (as modeled by instances do not appear together (i. e., as long as a classes), they fail to properly distinguish between type in a level has no instances in that level) (Atkin- types and metatypes (Atkinson and Kühne 2007). son and Kühne 2002). However, when types and ArchiMate’s single-level approach to accommodat- instances can be arbitrarily mixed within levels, ing both types and instances therefore essentially without any notational support for discrimination, transposes all issues arising from the conflation of modellers can easily become confused and fail to levels to a lower part of the modeling stack than adhere to basic modeling principles. The lack of is typically the case. Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 A Deep Perspective on the ArchiMate Modeling Language and Standard 11
Figure 7: Business Active Structure Elements with Potency
Deep modeling can be used to address issues Figure 8: Domains Types and Instance related by caused by an insufficient separation of elements Ontological Classification at different classification levels by introducing a notation to explicitly indicate whether a model 5 Customizability in ArchiMate element represents a type that classifies multiple instances in the modeled subject domain or rep- As explained in Sect. 2, ArchiMate identifies two resents an instance that does not. In other words, customization mechanisms, one designed to ex- deep modeling can be used to explicitly show the tend the predefined core modeling concepts with location of model elements in the ontological clas- attributes and the other designed to extend the core sification hierarchy, since the location is implied language with specializations of the predefined by the ontological classification relationships in core concepts using nominal (i. e., attribute-free) the subject domain. typing. Apart from calling them both “profile” This can be seen in Fig.7 which shows the mechanisms, the standard provides little detail same model as Fig.6 but using potencies to show about how they would work and what detailed whether elements represents types or instances. features they provide. The standard only hints at The names of model elements representing types what they might be like by, in the first case refer- have a potency value “1” appearing as a super- encing the textual profiling mechanism proposed script after their name, while model elements by Eertink et al. (1999) and, in the second case representing instances have “0”as a superscript. referencing the graphical/textual profiling mecha- Note that the inheritance relationships exist only nism of the UML. There are however many forms between types. The explicit presentation of type- a “lightweight” extension mechanism could take /instance properties in this way makes it easier for that does not require full metamodel editability. tools to ensure that specialization relationships do For example Brunelière et al. (2015) describe a not erroneously exist between model element that lightweight approach based on the use of a textual represent instances, such as Greg, Joan or Larry. DSL for metamodel extension that has been used Fig.8 goes one step further and shows the model in the EAM domain. Like the UML extension content from6 separated into distinct ontologi- mechanism, this is a form of non-invasive model cal levels with the natural ontological instanceOf decoration approach which avoids making direct relationship between them. This multi-level ver- changes to the underlying metamodel because it sion also avoids the problem of domain instances is often hardwired in a propriety tool (Kolovos and types being instances of the same metamodel et al. 2010). Although these approaches differ element. in terms of the exact set of operations they offer, Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 12 Colin Atkinson, Thomas Kühne
their strengths and weaknesses relative to an ap- changes are automatically recognized by the tool. proach that allows full access and changeability of The ArchiMate standard’s implicit adoption of the metamodel are basically the same. Therefore, two-level modeling, and its lack of support for di- without loss of generality, in the remainder of the rect, user-defined specialization of the metamodel, this article we will assume the UML extension therefore leads to a superfluous language issue: mechanism when discussing the pros and cons of Because direct, user-defined specialization of deep modeling. The UML extension mechanism the metamodel is not supported or envisioned by is the most well-known, and subsumes Eertink the ArchiMate standard - despite the fact that et al.’s approach (since it is able to add attributes specialization is used in the definition of the meta- to base types). models - an additional set of modeling concepts, the profile definition and application concepts, 5.1 Superfluous Languages have to be provided to users and implemented The main problem with the ArchiMate approach to by tools. This directly contravenes the goal of customization is that it requires users to essentially brevity in the Maxim of Manner and thus lowers learn an additional language in order to understand the conceptual integrity of the language. and define an extension - namely the profile mod- For metamodels to be directly extensible using eling features (Atkinson et al. 2013). Thus, the the regular specialization mechanisms they cannot meta-metamodel depicted in Fig.4 actually has to be hardwired into tools, as is the common prac- contain two language definitions, the core “meta- tice today (Atkinson et al. 2013). They must be modeling” language used to define the standard represented as “soft” model content that can be metamodels and the profile language used to define changed just like the normal “models” at the level profiles.1 This lowers conceptual integrity because below. This, in turn, means that the metamodel the core language already contains a simpler and elements need to be explicit instances of a “high- more fundamental mechanism for extending mod- level model”, such as the metamodel in Fig.4 or els and metamodels - the specialization (i. e., inher- the level-spanning linguistic model shown in the itance) mechanism. As mentioned before, just to schematic representation of the deep modeling understand the metamodel, ArchiMate users have approach in Fig.5. to learn the meaning of the specialization relation- For the reasons explained above, a level- ship that exist between the metamodel elements spanning approach is to be preferred since it avoids anyway. However, this relationship is exactly the the language duplication problem discussed earlier. mechanism used in the second extension mecha- With such an architecture, extensions can be easily nism. Thus, if the core language were extended defined by explicitly extending the metamodel us- to support attributes, which most object-oriented ing specialization as shown in Fig.9. This shows modeling languages do, no additional mechanism how the business layer metamodel as described beyond specialization would be needed to support in the ArchiMate specification (The Open Group extensions. 2017a) can be extended to support the business The reason why direct specialization of the layer specialization example shown in sect. 15.2.1 metamodel is not available in existing tools such of the ArchiMate standard. The top package as ArchiMate is their reliance on two-level model- contains the generic business layer metamodel ing platforms in which the metamodel is hardwired. consisting of BusinessInternalActiveStructureElement Specialization can only be used for language ex- (that represent the static structure of an organiza- tension if the language is truly represented as tion), BusinessInterface (that expose functionality changeable data (i. e., a metamodel) so that any to other roles or actors), BusinessInternalBehviorEle- ment (that represent the behavior of active structure 1 This resembles the top-level UML Infrastructure library, used to define the concepts shared between the UML andthe elements), BusinessEvent (that trigger or interrupt MOF (i. e., a core modeling package and a profile packages). behavior), BusinessService (that expose business Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 A Deep Perspective on the ArchiMate Modeling Language and Standard 13
Archimate Business Layer @http://example.org/archimate/business accesses1 assignedTo1 BusinessService1 BusinessInterface1
BusinessPassiveStructureElement0 realizes1 serves1 composes1 serves1
serves1 aggregates1 BusinessInternalBehaviorElement0 BusinessInternalActiveStructureElement0 assignedTo1
1 triggers_followsTo BusinessCollaboration1 triggers_followsTo1 triggers_followsTo1
1 triggers_followsTo1 BusinessRole
assignedTo1 accesses1 BusinessEvent1 assignedTo1 BusinessActor1
Archimate Business Layer Extension @http://example.org/archimate/extensions/business
Individual1
OrganizationalUnit1
Organization1
Figure 9: Excerpt of the Business Layer Metamodel and suggested Extensions. behavior), BusinessPassiveStructureElement (that formed out-of-the-box without the need for special represent business objects which are manipulated profile mechanisms. by behavior). BusinessInternalActiveStructureEle- In the example shown in Fig.9, a package called ments are further divided into BusinessActor (that ArchiMate Business Layer Extension is added to the represent entities capable of performing behavior), model. This package contains the extensions for BusinessRole (that represent entities responsible BusinessActor suggested by the ArchiMate standard for performing specifically assigned behavior) and (sect. 15.2.1), that is - BuinsessCollaboration (two or more active structure • Individual - a natural person capable of perform- elements that perform a behavior). BusinessPas- ing behavior. siveStructureElement, BusinessInternalBehaviorEle- • OrganizationalUnit - a subdivision (e. g., depart- ment and BusinessInternalActiveStructureElement are ment) of an organization. abstract, indicated by their potencies of zero, so • Organization - an institution, corporation or as- only their subclasses can be instantiated. sociation that has a collective goal linked to an Although the ArchiMate standard conceptu- external environment. ally envisages the specialization of metamodel Both packages, the ArchiMate Business Layer elements, in common with prevailing “two-level Package and ArchiMate Business Layer Extension, modeling” practice it does not view the actual display a URL beneath their package name. They use of specialization relationships as a practical can therefore be stored on the internet and im- mechanism for achieving this. This necessitates ported when needed as described in (Atkinson the inclusion of extra extension mechanisms. In et al. 2015). contrast, since all classification levels are soft ina Note that the extensions shown in Fig.9 show deep modeling framework (i. e., not hard-coded another example of ArchiMate’s lack of distinc- into tools) metamodel customizations can be per- tion between, and clear treatments of, types and Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 14 Colin Atkinson, Thomas Kühne
instances. The existence of Individual in the meta- A simple profiling mechanism that merely sup- model suggests that its instances at the level below ports specialization is incapable of concisely defin- are individuals. However, OrganizationalUnit is ing constraints that guarantee the presence of fea- a concept that would often be instantiated to a tures (e. g., attributes, associations, etc.) two or type at the level below (e. g.,“Marketing Depart- more levels down. ment”) which in turn would have instances at the A straightforward way to achieve the afore- level below that. For example, large international mentioned requirement in a deep modeling ap- companies will usually have several marketing proach is to use so-called “deep characteriza- departments (i. e., instances) in each of the coun- tion”. The latter can be achieved through po- tries where it operates. This situation can not be tency values higher than one and/or using variants of the powertype pattern as popularized by the handled cleanly in ArchiMate. UML. As Gonzalez-Perez and Henderson-Sellers have pointed out (Gonzalez-Perez and Henderson- 5.2 Deep Characterization Sellers 2007), the application of the powertype An important notion in EAM is the notion of pattern is a form of multi-level modeling, at least “integrity”, i. e., the fact that certain principles conceptually. Powertypes are essentially domain metatypes whose instances are subtypes of prede- can be relied on with respect to both the static fined metamodel elements such as BusinessActor. structure and the dynamic behavior (Lankhorst
2013). Thus, in the previous example revolving Business assignedTo2 Business ActorType2 RoleType2 1..* 2 around business actors, while specific business «powertype» actors may vary, there are common principles
which ought to hold in all cases. For example, a instanceOf common principle is that all business actors are Business Actor1 assigned a business role, regardless of what type of business actor they are. Although these properties
Threat 1 1 Organizational Organization ultimately materialize at the instance level they Agent Unit1 have to be defined for all kinds of business actor types. Figure 10: BusinessActor Powertype The top package in Fig.9 shows an excerpt of the ArchiMate metamodel that deals with business An example of the use of the deep model- roles and business actors. This includes a rela- ing approach to achieve deep characterization is shown in Fig. 10. This shows the BusinessAc- tionship assignedTo that requires business roles tor metamodel element along with three of the be assigned to business actors. However, this specializations suggested in sect. 15.2.1 of the constraint applies generically regardless of what standard. As can be seen from this figure, an kind of business role or business actor is involved. additional domain-specific level has been added in Most enterprises, however, require that business which BusinessActorType2 and BusinessRoleType2 roles only be assigned to business actors that are have been defined, where the former is the power- qualified to perform them. Thus, in the example type of BusinessActor. This means that any instance in6, one would hope that Larry has been assigned of BusinessActorType2 must specialize supertype the customer service representative role because BusinessActor. Supertype BusinessActor may thus he is a customer service expert. However, this is prescribe certain attributes that all its subtypes not guaranteed. automatically inherit, i. e., force them to have This gives rise to the shallow characterization mandatory relationships with other types such as issue: BusinessRole. Fig. 10 shows an alternative way of Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 A Deep Perspective on the ArchiMate Modeling Language and Standard 15
achieving the aforementioned mandatory associ- ation to BusinessRole by a deep association and deep multiplicity constraint (Kühne et al. 2015). Either way, all specializations of BusinessAc- tor are thus required to have regular (potency- one) assignedTo associations to instances of BusinessActorType2. Carvalho and Almeida (2016) show that by extending standard multi-level mod- Figure 11: Business Behavioral Elements Exam- eling with some additional kinds of cross-level ple (The Open Group 2017a, Example 23) relationships, it is possible to provide even richer controls over the nature of the extensions that can be made to metamodels. the same time. In this figure, the Claims Processing business service and the Claim Filed business event 6 Visualization Flexibility in ArchiMate are presented in the iconographic form and the other elements are presented in the rectangular The previous section discussed potential enhance- form. ments that multi-level modeling can offer to the Supporting the arbitrary, on-demand switching ArchiMate language and standard in terms of ab- between notational forms is not as trivial as it may stract syntax (i. e., supported modeling concepts). at first appear, especially in a tool that aims to In this section we consider what benefits multi- allow users to define new notations themselves. level modeling can offer the ArchiMate language For example, the UML only defines one standard and standard when applied to the visualization notation for each model element type defined in mechanism (i. e., concrete syntax). the metamodel, and requires all other notation As the notation summary in Fig.2 shows, the forms to be defined using the profiling mechanism. ArchiMate core language envisages two ways of However, profiles usually can only be applied visualizing most of the element types that are used in their totality to a diagram. Either the whole to construct ArchiMate models. One uses a stan- diagram is shown in the standard form or the dard rectangle-based shape (e. g., round cornered whole diagram is shown in the profile notation. rectangle = behavioral element) to identify the This leads to the notation interaction issue: basic nature of the element, colors to denote the The ArchiMate language supports two different layer in which element appears (e. g., business = notations for model elements out-of-the-box, but yellow) and small icons to identify the particular lacks a systematic way of managing them. type of element (e. g., event, process etc.). The Deep modeling infrastructures have a natural other approach uses just the icons together with and simple way of separating “standard” and the color conventions to present the particular “domain-specific” visualizations of model ele- element types. We refer to the former as the “rect- ments thanks to the fundamental separation of angular” form and the latter as the “iconographic” linguistic and ontological concerns embodied by form. Fig.2 shows only a part of the business the OCA. As a consequence of this separation layer notation, but the principles are the same for model elements inherently have two direct types all other levels. - a linguistic one and an ontological one. By exploiting both of the dimensions to assign visual- 6.1 Notation Interaction ization symbols to model elements, a distinction ArchiMate intends that both forms be arbitrarily between the fundamental linguistic notation and mixeable within the same model. For example, the domain-oriented ontological notation is nat- Fig. 11, which is Example 23 from the ArchiMate urally available. Moreover, since both forms of standard, shows both notational forms in use at classification are always present, they naturally Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 16 Colin Atkinson, Thomas Kühne Structrural Behavior
Figure 12: OCA Based Visualization Definition
allow the arbitrary interchange and mixing of no- dimensions. This inherent ability of deep model- tations. This is true regardless of what concrete ing environments to support switching between mechanisms are used to assign domain-specific ontologically defined visualizations and linguisti- visualizations (e. g., icons) to model elements in cally defined visualization is sometimes referred the ontological dimensions and how many nota- to as “language symbiosis” (Atkinson et al. 2012). tions are assigned. It is also true regardless of how many ontological classification levels exist. Although it is theoretically possible to allow A visualization management approach that ex- end users to change the linguistic visualization ploits linguistic and ontological classification is symbols, in practice these are usually hardwired shown schematically in Fig. 12. Here the basic into tools along with the rest of the linguistic “rectangular” forms of structural and behavior ele- model. The use of the cloud notation in Fig. 12 ments (i. e., square cornered and round cornered to represent visualizer assignment in both the lin- rectangles respectively) are defined via the lin- guistic and ontological level should not therefore guistic metamodel, while the icon forms of the be taken to mean that the mechanisms are the different types of elements are defined via the same, or are equally flexible from the user point ontological metamodel. of view. In Melanee, the only tool which currently In the depicted scenario, two visualizations allows the visualization of model elements to be (i. e., notations) are available for all elements in the user-defined model at the bottom left of the controlled both by linguistic and ontological clas- figure which can be switched at will - a generic one sification (Atkinson and Gerbig 2016), an arbitrary originating from the linguistic dimension, and an number of domain-specific visualization symbols ontological one originating from the ontological can be defined for visualizing model elements. Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 A Deep Perspective on the ArchiMate Modeling Language and Standard 17
6.2 Language Customization The key requirements supporting a flexible ap- As mentioned previously, in terms of extension proach to visualization specialization is decou- mechanisms sect. 5.2 of the ArchiMate standard pling the definitions of concrete syntax from ab- states that “new graphical notation could be in- stract syntax (Espinazo-Pagán et al. 2008), and troduced for a specialized concept, but preferably allowing the former to be attached to the latter in a with a resemblance to the notation of the gener- simple and changeable way. This, in turn, requires alized concept; e. g.„ by adding an icon or other unfettered access to the abstract syntax (i. e., meta- model) of the language which is a fundamental graphical marker, or changing the existing icon.”. strength of multi-level modeling approaches (de This means that end users should not only be Lara et al. 2015) where languages definitions can able to extend the iconography of the ArchiMate be created and edited as easily as normal model language, like the abstract syntax, they should be content. able to do so in a way that specializes the existing In order to support the specialization of vi- notation. Sect. 5.2 goes on to say “The profile sualization (i. e., concrete syntax) an additional may also define a specific notation to denote the ingredient is needed to allow new icons to be specialization. The default is the guillemet no- adapted from existing one - namely, an aspect- tation of UML for stereotypes (“«specialization oriented mechanism for notation definition (Ger- name»”). Other options include specific icons, big 2017). Such an approach allows a notation colors, fonts, or symbols.” to be customized by replacing parts declared as The clear intent of the standard is that the join points. Fig. 13 shows the aspect-oriented iconography of specific model element types syntax customization applied to the example of should be derived from the iconography of the BusinessInternalActiveStructureElement. more general model element types they are de- In this example, a generic diagrammatic nota- rived from. In other words, the visualizations of tion is defined for BusinessInternalActiveStructureEle- model elements, as well as the semantics of model ment via a visualizer shown as a cloud. This no- elements, should adhere to the principle of spe- tation, realizing the ArchiMate box notation, is cialization. However, this is more easily said than named box. It consists of a box which displays the done. Although the visualization mechanisms of name attribute of BusinessInternalActiveStructureEle- many of today’s modeling tools recognize special- ments in its center. Two join points are placed in ization hierarchies in the sense that they are able the shape for further customization. One, named to find and apply more general symbols to special- J퐴, in the upper left of the figure and one, named ized classes, none currently provides systematic J퐵, in the upper right of the figure. support for building new icons from pre-existing The subtype BusinessActor contributes to the icon fragments. Unfortunately, the ArchiMate diagrammatic visualization through the definition standard provides no details about the features of of aspects. A stick man is defined for placement in its envisaged profile mechanism, but no profile join point J퐵 in the visualizer for the box notation. mechanism available at the present time allows The icon notation is additionally defined on Busi- the specialization of visualization symbols. This nessActor via a visualizer displaying icon in the leads to a visualization specialization issue: upper right. This notation shows only a stick man The ArchiMate language explicitly calls for for visualization and defines a join point in the users to be able to add new visualizations to the visualization’s upper right for further customiza- ArchiMate language in a way that specializes the tion. The subtype’s of BusinessActor further refine existing notation (i. e., concrete syntax). How- the icon and box notation by providing aspects to ever, such a mechanism is not supported by any join point J퐴. Individual contributes an I to the vi- existing profiling mechanism, nor indeed by any sualization whereas OrganizationalUnit contributes contemporary modeling tool. a “U” and Organization an “O”. Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 18 Colin Atkinson, Thomas Kühne
O 1 Archimate Business Layer the bottom center of the diagram with an“I” in @http://example.org/archimate/business
1 the upper left corner and a stick man in the upper BusinessInternalActiveStructureElement0 aggregates name1 right corner. In addition to this box notation in the icon box bottom center of the diagram, the visualizer 1 BusinessCollaboration is shown on the right and the predefined notation J [name] J A B icon,box JA
7.1 Explicitly Modeling Ontological In (Frank 2014) and (Frank 2016), Frank fur- Classification thermore proposes a prototype multi-level meta The ArchiMate standard states that “The Archi- modeling language - Flexible Executable Multi- Mate language intentionally does not support a level Modelling Language (FMMLx) - to support difference between types and instances”. In other the explicit and level-agnostic representation of words, since it sees no reason to distinguish be- ontological classification in enterprise architec- tween types and instances ArchiMate sees no ture models. FMMLx was implemented by ex- need to represent ontological classification in user- tending the XCore metamodel of the Xmodeler defined models. While this may appear justifiable tool (Clark and Willans 2014). As discussed in terms of keeping the language simple, it ex- in Sect. 2, Frank’s requirements reinforce the plicitly goes against some of the subprinciples argument for an explicit and specially designed of conceptual integrity such as the principle of ontological meta-metamodel ensuring the meta- propriety (do not restrict what is inherent) and models describing the languages for the different the Maxim of Manner (avoid ambiguity). Not viewpoints are “soft” and can be created/edited only do many papers on multi-level modeling by users. When new view types, and thus view present examples from the enterprise modeling languages, are needed they can be added by simply domain (Atkinson and Kühne 2001; de Lara and defining new metamodels. Guerra 2010; Jordan et al. 2014), a comprehen- Some of the extra capabilities that explicit sup- sive study by de Lara et al. (2014) on the use of port for modeling ontological classification would 2 the type-instance pattern in modeling reposito- offer ArchiMate modelers are shown in Fig. 14. It ries shows that one of the applications where this shows what a deep version of the “ArchiSurance pattern is most commonly used is the business Contact Center” model from Fig.7 could look like. process/enterprise modeling area. The left hand side of the diagram (a) shows the In (Frank 2002), Frank lays out a fundamental traditional “two-level” version from Fig.7 while set of requirements that EAM modeling environ- the right hand side (b) shows an alternative deep ments should ideally fulfill based on a careful version which displays potency values and uses consideration of needs and practices in EAM the well-known UML colon-notation to show the projects. Two of his so-called technical “Require- type of a model element. ments for Modeling Environments” essentially The top part of Fig. 14 (b) shows the type call for multi-level modeling and the ability to information from the original version while the support the editing of all ingredients of a deep bottom part shows the instance information. The modeling language. Quoting from (Frank 2002): essential difference is that the “fulfills role” is • Requirement TR1: A tool environment for en- now represented by the ontological classification terprise modeling should include a metamodel relationship and a new Contact Center class has editor for specifying and modifying metamod- been added, of which the ArchiSurance Contact els. Center is defined to be an instance. • Requirement TR2: A metamodel editor should At first sight, the deep version might appear to efficiently support the creation of a model editor offer few advantages over the single-level version from a metamodel. This includes the implemen- and may even appear even a bit more verbose (i. e., tation of the abstract syntax and semantics as requiring more modeling elements). However, the well as the additional definition of the concrete enhanced conceptual integrity more than justifies syntax. the addition of a single new modeling element. First, the deep model leaves much less room for 2 The type-instance pattern is a workaround technique for representing ontological classification in two-level modeling misunderstanding than the single-level version be- frameworks. cause the types and instances are clearly separated Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 20 Colin Atkinson, Thomas Kühne
1
1 1 1
1 1
0
0 0 0
(a) Flat Model (b) Deep Model
Figure 14: Flat versus Deep Contact Center Models
and labeled explicitly as types or instances (a clar- to them without duplication or change), from ity benefit). WhileGreg “ ” may unambiguously specific scenarios in order to promote reuse and refer to an instance, it is much less clear whether avoid the confounding of particular circumstances the potential alternative “Manager” refers to “Man- with universal rules. ager” the type, or to a single “Manager”, i. e., Third, type-level descriptions of the constraints an individual performing the role of a manager. and properties that all business roles in the dia- Arguably, if the latter meaning is intended the use gram should have, together with the separation of “a Manager” (rather than “Manager”) would of concerns provided by the explicit levels for be more appropriate, but it is understandable that instances and types, reduces the scope for mod- ArchiMate did not chose this option. elers to introduce errors. This benefit would be Second, Contact Center in the top ontological even greater if ArchiMate supported attributes and level in Fig. 14 (b) captures the notion of a type multiplicities, but even with the current model- abstraction whereas ArchiSurance Contact Center at ing features, the ability to define allowed patterns the bottom level captures the notation of a specific at the type level reduces the error proneness of incarnation of this abstraction. Clearly, Greg, modelers using ArchiMate (a quality benefit). Joan and Larry are associated with such a specific Frank views the lack of this kind of support incarnation, not with its Platonic idea (as suggested as one of the greatest weaknesses of ArchiMate. by Fig. 14 (b)) (a separation of concerns benefit). In (Frank 2016), he states that: In general, it is highly useful to separate common Apart from the unusual conceptualization, the information and constraints that are applicable downside of this kind of flexibility is obvious: to all instances (which may be a large number ArchiMate allows for creating models that are over the lifetime of the system and can be applied wrong in the sense that they are counter-factual, Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 A Deep Perspective on the ArchiMate Modeling Language and Standard 21
O aggregates2 2 BusinessInternalActiveStructureElementType0 name2 box box General Information [name] JB
Name Salary Ann 72 O1 Bob 36 Manager Bree 48 Jim 23 O 0 Bree Ann Jim Bob 48€ 72€ 23€ 36€
Figure 15: Multi-format and Notation Views of Model Content e. g., an ERP system could be modeled as being can be displayed next to a graph-based model. part of a DBMS, or that do not make any sense, The metamodel at O2 is extended by adding one because properties were added that are meaning- deep attribute, salary2, to BusinessActorType2 for less. demonstration purposes. An additional join point is added to the diagrammatic box notation defini- 7.2 Multi Format, Multi Notation, tion of BusinessInternalActiveStructureElementType0 Projective Editing to display such additional information as salary With the possible exception of the profile mecha- figures. The visualizer of BusinessActorType2 pro- nism which may introduce additional visualization vides two aspects to this visualizer, one for dis- types, ArchiMate only supports a graph-based con- playing the stick man in the upper right and one crete syntax. However, the ArchiMate standard for displaying the salary below the name attribute. itself points out that “it should be possible to vi- In addition to the diagrammatic visualizer sualize the same model in different ways, tailored a form and table visualizer are defined on towards specific stakeholders with specific infor- BusinessActorType2 to enable so-called dashboards. mation requirements”. Since many stakeholders The form visualizer shows the total number of all in enterprise architecture are business users with- business actors (Count), the average salary of all out experience of formal languages, text-based, business actors (Avg. Salary) and the total salary of table-based and form-based visualizations should all business actors (Total Salary) calculated through also be supported (Gerbig 2017). OCL expressions. The table visualization gives Fig. 15 shows how a deep modeling tool - in a condensed overview of all business actor in- this case the Melanee tool (Atkinson and Gerbig stances, providing information about their names 2016) - can be naturally extended to support multi- and salaries. format modeling (Gerbig 2017) such that form- The demonstrated capabilities provide the basis and table-based presentations of model content for supporting the notion of dashboards described Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 22 Colin Atkinson, Thomas Kühne
by Frank (2016) as the ultimate goal of EAM where there is no explicit support for ontological approaches - namely, the notion of concise, inte- classification. This is a lamentable situation since grated, information summaries, providing stake- the need to use workarounds directly conflicts with holders (primarily managers) with information the goal of maximizing conceptual integrity. As across all abstraction and classification levels in explained in this article, this need could easily be their preferred format and notation. reduced by employing fully-fledged, multi-level Deep modeling environments such as Melanee modeling features. and (FMMLx) essentially achieve their flexibil- One of the reasons for the lack of adoption of ity by making what the users sees and interacts deep modeling in the EAM domain may be that with as malleable as possible rather than hard- current literature arguing the case for deep model- coded. This principle of modeling rather than ing in EAM does not present the benefits in the hard-coding choices and behavior can be extended context of existing EAM standards. This article to all elements that a user sees when interacting has thus aimed to demonstrate the benefits that with a modeling tool, including ultimately the deep modeling can bring to a concrete and widely whole environment in which models exist and are used EAM standard, the ArchiMate approach. We edited, including menus, toolbars, views, nota- fully embrace the notion of conceptual integrity tions, formats, model elements, modeling layout identified by Lankhorst (2013) and Lankhorst et al. environment view and editor arrangement, the (2010) as the underlying language design princi- modeling palette available to the user and the ple for ArchiMate and support the view that any property sheet. AtomPM (Syriani et al. 2013) is introduction of further features must be justified another example from the domain of metacase by benefits. The designers of any language must tools that has taken the “modeling over coding” therefore make a fundamental trade-off between principle to heart as almost all its components the expressiveness of a language in terms of what are entirely modeled and can thus be compara- users can model and the complexity of a language tively easily adapted to different requirements. By in terms of how complicated it is to learn and making as many features as possible “soft” and apply. configurable, the whole EAM environment used Our contribution is therefore twofold: First, we by stakeholders can be configured on a view-by- investigated how the modeling experience explic- view basis, thereby supporting the overall vision itly described and envisaged by the ArchiMate of viewpoint engineering promoted by ArchiMate standard (The Open Group 2017a) could be better and other EAM approaches. supported and described. To this end, we deliber- ately restricted ourselves to using deep modeling 8 Conclusion techniques to support this experience, without enhancing it. Second, in Sect. 7, we outlined In recent years there has been increasing interest additional potential benefits of deep modeling that in the potential benefits of multi-level modeling go beyond the features and capabilities explicitly in a variety of domains, and the technology has envisioned by the designers of ArchiMate. As a been used successfully in industry for a number result, we believe we have presented cogent argu- of tasks (Aschauer et al. 2009; Igamberdiev et al. ments as to why ArchiMate’s current realization 2018). However, deep modeling concepts are of its targeted feature set could be improved by still not being applied in earnest in the enterprise using deep modeling techniques. architecture modeling industry, despite the fact We have shown that deep modeling can both – that existing EA models exhibits some of the most frequent uses of the type-instance pattern • reducing the complexity involved in understand- (de Lara et al. 2014), an approach that is used as a ing and using the ArchiMate language as cur- workaround for deep modeling in environments rently defined in the standard. Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 A Deep Perspective on the ArchiMate Modeling Language and Standard 23
• enhance the expressiveness of the language with Atkinson C., Kühne T. (2003) Model-Driven De- minimal additional complexity. velopment: A Metamodeling Foundation. In: IEEE Software 20(5), pp. 36–41 We therefore hope that this article will be help- ful not only to the ArchiMate designers in terms Atkinson C., Kühne T. (2007) Reducing Acciden- of suggesting potential concrete enhancements for tal Complexity in Domain Models. In: Software future versions, but also to the EAM community and System Modeling 7(3), pp. 345–359 in general by helping to reinforce the message that deep modeling approaches and tools can offer Brooks Jr. F. P. (1975) The Mythical Man-month: benefits in EAM projects. Essays on Software Engineering. Addison-Wesley Brunelière H., García J., Desfray P., Khelladi References D., Hebig R., Bendraou R., Cabot J. (2015) On Aschauer T., Dauenhauer G., Pree W.(2009) Multi- Lightweight Metamodel Extension to Support level Modeling for Industrial Automation Systems. Modeling Tools Agility. In: Modelling Founda- In: Proceedings of EUROMICRO 2009: 35th EU- tions and Applications. ECMFA 2015. Lecture ROMICRO Conference on Software Engineering Notes in Computer Science Vol. 9153. Springer, and Advanced Applications. IEEE, pp. 490–496 pp. 62–74
Atkinson C., Gerbig R. (2016) Flexible Deep Carvalho V., Almeida J. (2016) Toward a well- Modeling with Melanee. In: Modellierung 2016 founded theory for multi-level conceptual model- - Workshopband Vol. 255. Gesellschaft für Infor- ing. In: Software & Systems Modeling 17, pp. 205– matik e.V., pp. 117–122 231
Atkinson C., Gerbig R., Fritzsche M. (2013) Mod- Clark T., Willans J. (2014) Software Language eling Language Extension in the Enterprise Sys- Engineering with XMF and XModeler In: Com- tems Domain. In: 2013 17th IEEE International putational Linguistics: Concepts, Methodologies, Enterprise Distributed Object Computing Confer- Tools, and Applications IGI, pp. 866–896 ence. IEEE, pp. 49–58 de Lara J., Guerra E. (2010) Deep Meta-modelling Atkinson C., Gerbig R., Fritzsche M. (2015) A with MetaDepth. In: Objects, Models, Compo- multi-level approach to modeling language ex- nents, Patterns. TOOLS 2010. Lecture Notes in tension in the Enterprise Systems Domain. In: Computer Science Vol. 6141. Springer, pp. 1–20 Information Systems 54, pp. 289–307 Atkinson C., Gerbig R., Kennel B. (2012) Sym- de Lara J., Guerra E., Cuadrado J. S. (2014) biotic general-purpose and domain-specific lan- When and How to Use Multilevel Modelling. In: guages. In: ICSE ’12: Proceedings of the 34th ACM Transactions on Software Engineering and International Conference on Software Engineer- Methodology 24(2), pp. 1–46 ing, pp. 1269–1272 de Lara J., Guerra E., Cuadrado J. S. (2015) Model- Atkinson C., Kühne T. (2001) Processes and Prod- driven engineering with domain-specific meta- ucts in a Multi-Level Metamodeling Architecture. modelling languages. In: Software & Systems In: International Journal of Software Engineering Modeling 14(1), pp. 429–459 and Knowledge Engineering 11(6), pp. 761–783 Eertink H., Janssen W., Luttighuis P. O., Teeuw W., Atkinson C., Kühne T. (2002) Rearchitecting Vissers C. (1999) A Business Process Design Lan- the UML infrastructure. In: ACM Transactions guage. In: FM’99 — Formal Methods. FM 1999. on Modeling and Computer Simulation 12(4), Lecture Notes in Computer Science Vol. 1708. pp. 290–321 Springer, pp. 76–95 Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 24 Colin Atkinson, Thomas Kühne
Espinazo-Pagán J., Menárguez M., García-Molina Jordan A., Selway M., Grossmann G., Mayer W., J. (2008) Metamodel syntactic sheets: An ap- Stumptner M. (2014) Re-engineering the ISO proach for defining textual concrete syntaxes. In: 15926 Data Model: A Multi-Level Metamodel Model Driven Architecture – Foundations and Perspective. In: Service-Oriented Computing – Applications. ECMDA-FA 2008. Lecture Notes in ICSOC 2013 Workshops. ICSOC 2013. Lecture Computer Science Vol. 5095. Springer, pp. 185– Notes in Computer Science Vol. 8377. Springer, 199 pp. 248–255 Kolovos D. S., Rose L. M., Matragkas N. D., Frank U. (2002) Multi-perspective enterprise mod- Paige R. F., Polack F. A., Fernandes K. J. (2010) eling (MEMO) conceptual framework and model- Constructing and navigating non-invasive model ing languages. In: Proceedings of the 35 Annual decorations. In: Theory and Practice of Model Hawaii International Conference on System Sci- Transformations. ICMT 2010. Lecture Notes in ences. IEEE, pp. 1258–1267 Computer Science Vol. 6142. Springer, pp. 138– Frank U. (2014) Multilevel Modeling. Toward 152 a New Paradigm of Conceptual Modeling and Kühne T., Atkinson C., Gerbig R. (2015) A Uni- Information Systems Design. In: Business & In- fying Approach to Connections for Multi-Level formation Systems Engineering 6, pp. 319–337 Modeling. In: 2015 ACM/IEEE 18th International Conference on Model Driven Engineering Lan- Frank U. (2016) Designing Models and Systems guages and Systems. IEEE, pp. 216–225 to Support IT Management: A Case for Multi- level Modeling. In: MULTI 2016 – Multi-Level Lankhorst M. M. (2013) Enterprise Architecture Modelling. Proceedings of the Workshop in Saint- at Work: Modeling, Communication, and Analysis. Malo. Atkinson, Grossmann, and Clark, pp. 3– Springer 24 Lankhorst M. M., Proper H. A., Jonkers H. (2010) The anatomy of the archimate language. In: Inter- Gerbig R. (2017) Deep, Seamless, Multi-format, national Journal of Information System Modeling Multi-notation Definition and Use of Domain- and Design 1(1), pp. 1–32 specific Languages. Dr. Hut Verlag Object Management Group (2006) Meta Object Gonzalez-Perez C., Henderson-Sellers B. (2007) Facility (MOF) 2.0 Core Specification Modelling software development methodologies: Object Management Group (2007) Unified Mod- A conceptual foundation. In: Journal of Systems eling Language Infrastructure, Version 2.1.2 and Software 80(11), pp. 1778–1796 Syriani E., Vangheluwe H., Mannadiar R., Hansen Grice H. P. (1975) Logic and conversation. In: C., Van Mierlo S., Ergin H. (2013) AToMPM: A Syntax and semantics 3: Speech arts, pp. 41–58 Web-based Modeling Environment. In: CEUR Workshop Proceedings Vol. 1115. Liu et al., Igamberdiev M., Grossmann G., Selway M., pp. 21–25 Stumptner M. (2018) An integrated multi-level The Open Group (2017a) ArchiMate 3.0 Speci- modeling approach for industrial-scale data inter- fication http://pubs.opengroup.org/architecture/ operability. In: Software and Systems Modeling archimate3-doc/toc.html Last Access: 2017-02-24 17(1), pp. 269–294 The Open Group (2017b) ArchiMate 3.0 Specifi- ISO/IEC (1997) RM-ODP. Reference Model for cation Launch http://www.opengroup.org/news/ Open Distributed Processing. In: ISO/IEC 10746, press/The-Open-Group-Launches-ArchiMate-3 ITU-T Rec. X.901-X.904 Last Access: 2017-02-24 Enterprise Modelling and Information Systems Architectures Vol. 15, No. 2 (2020). DOI:10.18417/emisa.15.2 A Deep Perspective on the ArchiMate Modeling Language and Standard 25
The Open Group (2010) TOGAF 9 - The Open Group Architecture Framework Version 9 http: //www.bibsonomy.org/bibtex/24bc77b548cf18e9 b08955140208cf2a1/amitgoel Last Access: 2010- 02-26 Zachman A. (1987) A framework for information systems architecture. In: IBM Systems journal 26(3), pp. 276–292