Diving into the world of ArchiMateBy Rebecca Latukolan, 3838609, MBI student at UU, under guidance of Dimitra Papachristou

Table of ContentIntroduction.................................................................................................................................................1

Examples.....................................................................................................................................................3

Generic example......................................................................................................................................3

Detailed example.....................................................................................................................................4

Process-Deliverable Diagram......................................................................................................................5

The way of structuring a non-structured method.....................................................................................5

ArchiMate’s overall PDD description......................................................................................................7

Activity table...............................................................................................................................................9

Concept table.............................................................................................................................................13

Related literature.......................................................................................................................................15

References.................................................................................................................................................16

Appendix...................................................................................................................................................18

A............................................................................................................................................................18

B............................................................................................................................................................18

Introduction When architecting a house, you talk about ‘rooms’ and ‘doors’, and everyone knows what is talking about. People share a common frame of reference (Lankhorst, M., 2009). With Enterprise Architecture, such ‘frame of reference’ is needed to design an enterprise. With the increasing complexity of organizations, their information systems and interactions, businesses nowadays see the importance of architecting their enterprise (Lankhorst, M., 2009). An overview of the structure of an organization, its business processes, their application support, the technical infrastructure, it is needed to express the different aspects and domains, and their relations. To make this convenient to communicate, the modeling language called ArchiMate can be used to guide business analysts into structuring the enterprise. ArchiMate’s goal is to support and improve the architects process through description, analysis and visualization of architecture within and across business domains in an unambiguous way (Vicente, M., Gama, N., & da Silva, M., 2013).

To dive in the ArchiMate modelling framework (Appendix A), decomposition happens to an enterprise along two dimensions (Quartel, D., Engelsman, W., Jonkers, H. & van Sinderen, M., 2009):

o Layers, connected by a service orientation paradigm. Each layer exposes functionality as a service to the layer above (Vicente et al., 2013), and each of these layers represent abstraction levels at which an enterprise is modelled;

o Aspects, representing different concerns of the enterprise.

The first mentioned dimension, the layers, three can be distinguished: business layer, application layer and technology layer. The business layer offers products and services to external customers realized by business processes (Quartel et al., 2009). It contains objects that model the business, and its purpose is to describe the front end interactions (Roose, D., Bernaert, M., Poels, G., 2013). The business layer focusses on the organizational structure of the way of working in- and outside a company on a high-level view by delivering and capturing, e.g., the actors and their corresponding roles which need to be fulfilled, and if there is interaction/collaboration (Jonkers, H., Lankhorst, M., van Buuren, R., Hoppenbrouwers, S., Bonsangue, M. & van der Torre, L., 2004). Quartel et al. (2009) and Roose et al. (2013) both explain that the application layer supports the business layer with application services realized by software application components. Those deliverables in this layer for supporting the business layer need to be captured. Both Quartel et al. (2009) and Roose et al. (2013) mention that the last, which is the technology layer, offers infrastructural services for applications to be able to run, realized by hardware and system software. These units are necessary deliverables to determine how the infrastructure of a company is structured, and how the way of communicating is supported.

The other dimension, the aspects, can be distinguished into the following modeling aspects: structure, behavior and information aspects. Quartel et al. (2009) elaborates on the three aspects (from a business layer point of view): the structure aspect represents the actors and their relationships; the behavior aspect represents the behavior performed by the actors, and interaction; and last, information aspect which represents the problem domain knowledge that is used by and communicated between the actors through their behaviors. Other literature (“Language structure”, 2012; Lankhorst, M., Proper, H., Jonkers, H., 2010; Groenewegen, J., Hoppenbrouwers, S., Proper, H., 2010) calls the latter, passive structure, since it represents objects on which behavior is performed.

To help structuring an enterprise with ArchiMate, a template is followed named viewpoints (i.e. domains), and are used to represent a perspective on the enterprise that is of interest to one or more stakeholders (Quartel et al., 2009). These non-overlapping viewpoints (ellipses in Appendix A) arise when the dimensions are structured which allows one to model an enterprise from different perspectives. Views which are specified within a viewpoint contain (a few of the) deliverables mentioned two paragraphs back (which were actors, services, application components, etc.). Depending on the layer and viewpoint that is modelled, you can determine what deliverables are needed to capture for the view.

It is important to keep viewpoints consistent. A viewpoint functions as a template from which to develop individual views (Lankhorst et al., 2010; Steen, M., Akehurst, D., Doest, H., & Lankhorst, M., 2004). Documents are produced by an Enterprise Architect, containing different view(s) within viewpoint(s) of different layers. With ArchiMate, a convenient and easy to communicate modeling language is available for the creation of documents, describing the Enterprise’s architecture with capturing their complex interactions. But what are we missing?

A later version of ArchiMate added two extensions to the method. The first being the motivation extension, that covers the elements that motivate the design and operation of an enterprise. It encapsulates motivational concepts to address the management of goals, principles, and requirements (Azevedo, C.L.B., Almeida, J., Guizzardi, G., 2011; Quartel et al., 2009). Second, being the implementation and migration extension, which is concerned with capturing its focus on the change and implementation of new aspects of a business (Jonkers, H., van den Berg, H., Iacob, M., Quartel, D., 2010). How these extensions fit in the ArchiMate Framework can be seen in Appendix B.

ArchiMate was developed in the Netherlands by a project team from the Telematica Instituut in cooperation with several Dutch partners: Ordina, Radbout Universiteit Nijmegen, the Leiden Institute for Advanced Computer Science (LIACS) and the Centrum Wiskunde & Informatica (CWI). Later, organisations also participated with pilot tests, such as ABN AMRO, the Dutch Tax and Customs Administration and the ABP. The development process lasted a little over 2 years, dated from July 2002 to December 2004. And in 2008 the ownership of ArchiMate was transferred to the Open Group. Where in February 2009, the Open Group first published the ArchiMate® 1.0 standard as a formal technical standard. Newer versions were released later on in the process (“The ArchiMate project”, n.d.).

It is not explicitly said in literature (or other scientific resources) who ArchiMate’s exact creators are, therefore no explicit pronunciations will be done. Though, two important people are mentioned. Marc Lankhorst and Henk Jonkers were (among others in the core development team) the key developers of the ArchiMate development process. Marc Lankhorst is described on Wikipedia as “key developer of ArchiMate” and “Lankhorst managed the development of enterprise architecture modelling language ArchiMate”. Lankhorst also confirms this on his LinkedIn profile. Whereas Henk Jonkers, just as Marc Lankhorst, is introduced (multiple times) on the website of The Open Group as one of the key developers of the Core team of ArchiMate. There is no record available about the other developers in the core team of ArchiMate, or if there even are any besides Lankhorst and Jonkers.

ExamplesIn this section two different, own made examples of the ArchiMate method are provided in order to get an idea of what this method does. Although trying to narrowing it down by simplifying the examples, since ArchiMate is a LARGE method which involves many layers, aspects, concepts, views to take into consideration. First a generic example is given, where we dive into an example where the different ‘steps’ of the ArchiMate method are followed, and secondly, a more detailed example in which one of the deliverables of the method is shown and explained.

Generic exampleA fictitious company, called MisterTicket, has a platform on which it wants to sell tickets for all kinds of different films at the cinema which people can reserve their seat.

This example is viewed from a business process viewpoint. This viewpoint contains only the business layer (“ArchiMate® 2.1 specification”, 2013). ArchiMate is a modeling language that does not strictly follow a step-by-step process. It can be done in multiple different ways and it can range in scope. Below, one possible procedure is described. Since only one layer here needs to be taken into account for this viewpoint, there is no need to have a look at all the other layers per aspect; only the business layer. And in this viewpoint the behavioral aspect is the most relevant.

1. Identify organizational structure: Structure aspect: Actors and roles: customers.

2. Define servicesBehavior aspect: Business services, functions and processes: seat selection, handle seat reservation, login, accept, valuate, pay

3. Determine objectsPassive aspect:

Business objects: customer file, security policy, notification.4. Create architectural description

Use the information generated from the dimensions and construct all elements in a view for the specific viewpoint* (This is done in the next section: Detailed example). Make sure the model is consistent with the other models. This is for this example of non-relevance, since we only model one model in one view from one viewpoint. This consistency should be taken into account with designing multiple models of a view in a viewpoint as well as consistency between the different views. Provide the ArchiMate model in the viewpoint with a rich description explaining it with creating the viewpoint.

Detailed exampleOne of the deliverables is an ArchiMate model created and described with the business process viewpoint. It is illustrated in Figure 3. The model here is provided with a description as well.

Figure 3: Seat reservation process

This ArchiMate model is created from a view of the template: Business Process viewpoint. This is a typical view created for stakeholders such as domain and process architects and operational managers. This view arises concerns such as the structure of the business processes; consistency and completeness and responsibilities. The business layer of ArchiMate functions in this view as a leading role.

Figure 3 shows the process from the inception to the eventual end deliverable of making a reservation for a seat in the cinema from the MisterTicket’s website. Consider the following situation in which a customer wants to go to the movies and picks its own seat. The customer therefor selects the seat on the website and after that, the website needs to know who this person is that wants to reserve this seat. This

event triggers the login. This login needs to be verified and needs to obtain the correct customer file which then has to be updated with current actions of the customer. When the customer does not have too many reservations on his account for movies, and does not have a reservation already at that exact time, it can make a reservation. This information first needs to be read and accepted. When this is valid, the price needs to be valuated (rank of returning customer for possible discount), where after, the customer can pay. There might be a limitation concerning customer – website interaction, which is the number of options to pay for the ticket. This is due to security measures. At last, when the customer has paid for its ticket it receives a notification of payment and a barcode with its reservation through email.

Process-Deliverable DiagramIn this section a Process-Deliverable Diagram (PDD) is created of ArchiMate. Weerd, I. van de, & Brinkkemper, S. (2008) mention that PDDs have proven to be effective means for the meta-modeling of methods, especially for the analysis and design stages. In their paper they introduce PDDs; where is explained that it is used as a meta-modelling technique that handles both process- and deliverable side of methods/techniques. The left side of a PDD consists of all processes using the UML activity diagram notation. The right side of the PDD consist of all deliverables using the UML class diagram notation. Both sides put together through a dotted arrow, only from left to right (from process to deliverable), forms the PDD. This one way direction is due to the fact that deliverables are generally available to every process that needs it, after the deliverable is produced.

The way of structuring a non-structured method An approach of ArchiMate and its three main layers and cross-layers are modelled, illustrated in figure 1. A more in depth approach of one of its particular layers, namely the business layer, is illustrated in figure 2. Table 1, the activity table, provides a detailed description of all activities involved in both PDDs. Table 2, the CONCEPT table, provides a description of all produced CONCEPTs in both PDDs. With the support of the paper of Jonkers et al. (2004), both PDDs were eventually modelled. Occasionally, additional information was required for the complete understanding of the processes between different concepts, and this was gathered from other resources (Lankhorst, M., 2009; “ArchiMate® 2.1 specification”, 2013). Jonkers et al. (2004) discusses the concepts (i.e. the deliverables) of the method, and while elaborating on each deliverable, activities could be derived. Literature study ruled out a structured way of executing ArchiMate; a particular stepwise process is not contained in this method. That is also the strength of this framework, because Enterprise Architects are in this way not bound to a particular way of acquiring their Enterprise components. It is argued that it is logical to first start with the business layer, followed by the application layer and ending with the technology layer (Lankhorst, M., 2009; “ArchiMate® 2.1 specification”, 2013 & Lankhorst, M., 2004). This is because in line with service orientation, the higher layers make use of the services of lower layers. Nonetheless, this order also depends on the perspective of the stakeholders. If approaching it from the IT strategy as the enabler, the order is the other way around (Henderson & Venkatraman, 1999). For instance, an artifact might realize a data object. Layers mutually are in contact with the direct layer above or beneath its own; meaning the business layer cannot directly share components with the technology layer, and vice versa. Berrisford & Lankhorst (2009) argue that within the layer, a bottom up approach is most desired. This means starting with the structural concepts and working your way up from providing their behavior to acquiring the objects. There are a numerous ways to execute the ArchiMate method. There is no particular way in doing this. When modeling an enterprise architecture in ArchiMate, one has to know for who to model the views; what kind of culture the company has; what product or idea it wants to incorporate into the organization;

what the goals are et cetera. In order to design the method’s process side of the deliverable, according to Jonkers et al. (2004) and Lankhorst (2009), a logical order of activities could be derived.

Note that the Motivational and Implemention & Migration extensions are left out, due to limited space and (possibly) cluttered diagrams.

Figure 1: ArchiMate’s Process-Deliverable Diagram

ArchiMate’s PDD descriptionsFigure 1 illustrates ArchiMate’s main activities (with its corresponding sub-activities): Business layer, Application layer, Technology layer and Cross-layer dependency. Starting with the business layer; its main focus is to identify its actors and assigned roles in the organization to determine how they interact with one another and what services are delivered and provided to execute processes and fulfill their functions. For the application layer, the components first need to be defined in order to determine how they communicate/interact; this is in Jonkers et al. (2004) referred to as “application collaboration” and “application interface” activities. Here, the umbrella term “application communication” is used. This process occurs at the same time when application services and data objects need to be specified. This is because services are exposed when defining interfaces. This activity intertwines, and at the same time there needs to be thought of specifying the objects required for an application service. These three activities automatically cannot leave each other’s sight. When thinking about one of these three activity logically leads to the other activity, and vice versa. This is a continuous process. The technology layer is executed (almost) similar to the other two layers only from a more abstract perspective, but at the same granularity level (Lankhorst, M., 2009).

Observing closely, one can see that after every layer activity, the “create architectural description” activity is executed. This means that for every layer there is one VIEW or several views created, constructed out of the elements obtained in previous activities from the corresponding layer, for precisely one VIEWPOINT. Each VIEWPOINT, and its corresponding attributes, can be updated to a newer version in VIEWPOINT HISTORY (Steen, M., Akehurst, D., ter Doest, H., Lankhorst, M., 2004).

The cross-layer dependency is an activity which requires 2 or 3 layers to align to create specific views within a viewpoint.

Note that additional rules and notation are specified in the models. Again, this is only one way to follow this method. It can for example be that according to organizational standards and culture it seems more logical to start with the technology layer and work up to the most abstract level. It could also be the case that the stakeholders whom you create the views for are only interested in the business layer, in that case the other layers can be dismissed et cetera.

Figure 2 illustrates the business layer in depth. This is one possible way to acquire the elements to construct business layer views, there are several more. In the Generic Example section the structure of the business layer PDD can be traced back. An important aspect to mention regarding this PDD, is that a VIEW not only needs consistency among each other in a VIEWPOINT, but that a VIEWPOINT also needs consistency between views of other VIEWPOINT.

Figure 2: ArchiMate’s business layer Process-Deliverable Diagram

Activity tableActivity Who

performs (and are involved with) the activity

Sub-activity Sub-sub activity

Description

Business layer Architects (i.e. enterprise, domain and process), managers, employees, shareholders

Identify organizational structure

Identify actors Is where an ACTOR needs to be specified that has certain competences. This delivers a directory of ACTOR and ROLE.

Assign roles Is where a ROLE is linked to ACTORs. Competences located in the deliverable of the previous activity determine what ROLEs ACORs will receive. A ROLE eventually wants to use and provide SERVICE to the organization.

Determine collaboration

Is where 2 or more ROLEs can collaborate with each other and is (at this stage) determined who is in COLLABORATION with each other.

Determine business interaction

Is where COLLABORATION involves BUSINESS INTERACTION or multiple interactions. So there needs to be determined what interaction there is (if there is any)

Architects, operational managers

Define services Define products Is where a SERVICE, which can consist of internal/external SERVICEs is defined to know how different functions/stakeholders interact and what is provided to its

customers. A SERVICE consist of a CONTRACT, which is some sort of BUSINESS OBJECT.

Identify organization service

Is where an EXTERNAL SERVICE needs to be accessed through an interface’s LOCATION.

Identify internal behavior

Is where an INTERNAL SERVICE realizes an EXTERNAL SERVICE (to customers)

Developers, managers, architects

Determine objects Define business interface

Is where LOCATIONs are determined where the SERVICEs that a role offers to the environment are accessed

Derive business objects

Is where BUSINESS OBJECT’s representation (format or medium), meaning/contribution to the existing knowledge, and value/contribution to a party is derived

Application layer Architects (i.e. enterprise, process and domain, application)

Define application components

Is where all APPLICATION COMPONENTs are identified and determined in order to eventually provide certain APPLICATION services

Architects Acquire application communication

Is a way to determine and acquire APPLICATION COLLABORATION and APPLICATION INTERFACE components to see how different elements fit in the way of

communicationarchitects Determine

application services

Is used to describes the interaction and the functions of the applications. APPLICATION SERVICE needs to access DATA OBJECT in order to be able to provide the SERVICE to one or several APPLICATION COMPONENTs. This is determined in this phase

architects Specify required data objects

Specify all important DATA OBJECTs that need to be accessible and manipulated

Technology layer Infrastructure architects, operational manager

Gather nodes Identify devices Is to determine on what hardware the software is going to run. A device is some sort of NODE

Identify system software

Is to determine what software is going to be used. A system software is also some sort of NODE

Infrastructure architects, operational manager

Capture infrastructure interface

Is a way to determine what INTERFACE is being used for a SERVICE to be assigned to. INFRASTRUCTURE SERVICE from a NODE can be accessed through INFRASTRUCTURE INTERFACE. Those INTERFACEs are necessary to capture in order to be able to provide and acquire SERVICEs through the organization

Infrastructure architects, operational manager

Determine communication path

Is a way of COMMUNICATION that is necessary between devices and

software. A NETWORK is a sort of COMMUNICATION PATH

Infrastructure architects, operational manager

Provide infrastructure services

Is where a SERVICE is needed to keep information flowing

Infrastructure architects

Identify artifacts Is a physical piece of information, convenient for an organization to know what is tangible for them to use.

Cross-layer dependency

Enterprise architect

Align different layers

Is a way to see how the different layers can communicate with each other and create VIEWs of different layers

Create architectural description

Enterprise architect

Construct elements Are the elements that are glued together, like LEGO, to create VIEWs

Enterprise architect

Trace consistency Address consistency between VIEWs

Create architectural document

Enterprise architect

Is a way to ssemble and documents all created VIEWPOINTs in one ARCHITECTURAL DOCUMENT in a structured way

Table 1: Activity table PDDs

Concept tableCONCEPT DESCRIPTIONACTOR Business ACTORs may be individual persons, but also groups of people

and resources that have a permanent (or at least long-term) status within the organization (Jonkers et al., 2004).

ROLE A business ROLE here is defined as the responsibility for performing specific behavior, to which an ACTOR can be assigned. An ATOR can have multiple ROLEs and vice versa. (Jonkers et al., 2004; Lankhorst, M., 2009).

COLLABORATION COLLABORATION defines an aggregate of two or more business ROLEs that work together to perform collective behavior. (Jonkers et al., 2004; “ArchiMate 2.1 specification”, 2013).

BUSINESS INTERACTION BUSINESS INTERCATION is a unit of behaviour similar to a business process or function, but it is performed in a COLLABORATION of two or more ROLEs within the organization (Jonkers et al., 2004).

SERVICE A BUSINESS SERVICE is defined as a service that fulfills a business need for a customer (internal or external to the organization) (“ArchiMate 2.1 specification”, 2013)

APPLICATION SERVICE APPLICATION SERVICE is an externally visible unit of functionality, provided by one or more components, exposed through well-defined interfaces, and meaningful to the environment. The service conceptprovides a way to explicitly describe the functionality that components share with each other and the functionality that they make available to the environment (Jonkers et al., 2004).

EXTERNAL SERVICE EXTERNAL SERVICE represents a unit of functionality that is meaningful from the point of view of the environment (Jonkers et al., 2004).

INTERNAL SERVICE INTERNAL SERVICE (service within the organization) are realized by business processes, business functions or business interactions (Jonkers et al., 2004).

CONTRACT A CONTRACT is defined as a formal or informal specification of an agreement that specifies the rights and obligations associated with a SERVICE. (Jonkers et al., 2004; “ArchiMate 2.1 specification”, 2013).

BUSINESS OBJECT BUSINESS OBJECTs are the passive entities that are manipulated by behaviour such as business processes or functions. BUSINESS OBJECTs represent the important concepts in which the business thinks about a domain. (Jonkers et al., 2004).

LOCATION Logical or physical LOCATION, i.e., BUSINESS INTERFACE: the SERVICEs that a ROLE offers to the environment that can be accessed (Jonkers et al., 2004).

VIEW VIEW is a representation of a system from the perspective of a related set of concerns. (Lankhorst, M., 2009).

VIEWPOINT VIEWPOINT defines a specification of the conventions for constructing and using a VIEW; a pattern or template from which to develop individual VIEWs by establishing the purposes and audience for a VIEW and the techniques for its creation and analysis. (Jonkers et al., 2004; Steen, M., 2004).

VIEWPOINT HISTORY VIEWPOINT HISTORY is a storage to constantly put new versions of the

VIEWPOINT.APPLICATION COMPONENT APPLICATION COMPONENT is used to model any structural entity

(Jonkers et al., 2004).APPLICATION COLLABORATION

2 or more APPLICATION COMPONENT that provide other components of APPLICATION SERVICE

APPLICATION INTERFACE APPLICATION INTERFACE is the (logical) LOCATION where the services of a component can be accessed. In a broader sense, an APPLICATION INTERFACE also has some behavioural characteristics: it defines the set of operations and events that are provided by the component, or those that are required from the environment. Thus, it is used to describe the functionality of a component. A distinction may be made between a provided interfaceand a required interface (Jonkers et al., 2004).

DATA OBJECT DATA OBJECT can be compared to a UML ‘class’. A DATA OBJECT is a passive component (Jonkers et al., 2004).

NODE A NODE is defined as a computational resource upon which artifacts may be stored or deployed for execution. NODE come in 2 flavours: DEVICE and SYSTEM SOFTWARE (Jonkers et al., 2004; “ArchiMate 2.1 specification”, 2013)

INFRASTRUCTURE INTERFACE

An INFRASTRUCTURE INTERFACE is the (logical) location where the INFRASTRUCTURE SERVICE offered by a NODE can be accessed by other nodes or by APPLICATION COMPONENT from the application layer. (Jonkers et al., 2004).

INFRASTRUCTURE SERVICE An INFRASTRUCTURE SERVICE is defined as an externally visible unit of functionality, provided by one or more NODEs, exposed through well-defined INTERFACEs, and meaningful to the environment (Jonkers et al., 2004; “ArchiMate 2.1 specification”, 2013).

COMMUNICATION PATH The COMMUNICATION PATH models the relation between two or more NODEs, through which these nodes can exchange information. The physical realization of a COMMUNICATION PATH is a modelled with a NETWORK (Jonkers et al., 2004).

NETWORK NETWORK is the physical realization of a COMMUNICATION PATH (Jonkers et al., 2004).

ARTIFACT An ARTIFACT is a physical piece of information that is used or produced in a software development process, or by deployment and operation of a system (Jonkers et al., 2004).

ARCHITECTURAL DOCUMENT

ARCHITECTURAL DOCUMENT is a document containing all created VIEWPOINTs to archive and to keep up to date.

Table 2: CONCEPT table PDDs

Related literatureHere, topics are elaborated on derived from the observations depicted from the literature search. Information is given about the origins of ArchiMate; the position ArchiMate takes in its related field; and descriptions about previous work and the application of ArchiMate.

The Open Group mentions on its website (“The ArchiMate project”, n.d.) that ArchiMate is not a standalone development method. That it can thank its existence to existing methods and techniques, like UML and BPMN, but also TOGAF and Zachman’s framework. ArchiMate for example distinguishes itself from UML and BPMN due to its enterprise modelling scope. Lankhorst et al. (2010) mentions that the ArchiMate meta model defines concepts between two extremes: a set of generic concepts focusing on domain modelling and concepts used by project-level modelling languages (e.g. UML and BPMN). He also elaborates that ArchiMate’s conceptual framework consist of layers and aspects of classification, which is of similarity with Zachman’s framework. Same goes for ArchiMate’s concepts, which can be derived from UML. However, he distinguishes UML and Zachman’s framework from ArchiMate by discussing ArchiMate’s ability to explicitly model the dependencies between the different layers, domains and views of the enterprise architecture, eventually becoming a coherent whole. Lankhorst (2009) acknowledges the resemblance of ArchiMate with UML notations, but highlights the observation that ArchiMate focusses more on semantics than the UML language. Zutterman, S., Poels, G., Bernaert, M. (2013) mention that the layers in ArchiMate have similarities with the architectural layers in TOGAF. Zutterman (2013), but also Jonkers, H., Proper, E., Turner, M. (2009) say that from ArchiMate’s version 2.0 there can be safely said that the language is fully aligned with TOGAF, when the Motivational extension was included, which relates to Zachman’s ‘Why’ focus.

ArchiMate is an open and independent enterprise architecture modeling language. The ArchiMate language is broadly compared with other languages and standards in (Jonkers, H., Lankhorst, M., Van Buuren, R., Hoppenbrouwers, S., Bonsangue, M., & Van Der Torre, L., 2004). Jonkers et al. (2004) mainly positions ArchiMate in the organization and process modelling language domain. Methods, techniques, languages for modelling enterprise architectures. He argues that many other languages cover certain domains of an enterprise, but not all. RM-ODP’s enterprise viewpoint covers ArchiMate’s business layer, but not the other two layers. And BPMN covers the business layer as well, but neglects the other two (Jonkers et al., 2004; Penicina, L., 2013). UML on the other hand does cover all layers on the behavior and structure level, but differ with ArchiMate due to its required detail. Compared with ArchiMate, the domain relations are often weakly defined in the other languages (Jonkers et al., 2004). However, ArchiMate does have room for languages such as UML to add to its model in providing a more detailed model. At last, Jonkers et al. (2004) explains that ArchiMate fits well with the Model Driven Architecture (MDA) philosophy. The abstraction level of ArchiMate simplifies the construction of integrated models.

ArchiMate has been applied to a proof of concept for a game based approach, which aimed at validating ArchiMate models (Groenewegen et al., 2010). A case study that looks at implementation of a student internship programme in the University of West London with its objective to guarantee placement within three years. ArchiMate was used here as an extension to the other modeling languages for using ArchiMate’s ‘meaning’ element (Quartel et al., 2009) and complex event (Kim, H., Oussena, S., 2012). Also, Meertens, L., Iacob, M, Nieuwenhuis, L, Van Sinderen, M., Jonkers, H., & Quartel, D. (2012) compared Business Model Ontology (BMO) to ArchiMate. In Quartel et al. (2009), ArchiMate is used as a tool for implementing ARMOR.

ReferencesAzevedo, C. L., Almeida, J. P. A., Van Sinderen, M., Quartel, D., & Guizzardi, G. (2011, August). An ontology-based semantics for the motivation extension to ArchiMate. Proceedings of the 15th IEEE International Enterprise Distributed Object Computing Conference (EDOC), 2011, Helsinki, Finland, 25-34.

Berrisford, G., & Lankhorst, M. (2009). Using archimate with an architecture method. Via Nova Architectura, 6.

Groenewegen, J., Hoppenbrouwers, S., & Proper, E. (2010). Playing ArchiMate models. Proceedings of the 11th International workshop BPMDS and 15th International conference EMMSAD, 2010, Luxembourg-Kirchenberg, Luxembourg, 182-194.

Henderson, J. C., & Venkatraman, N. (1993). Strategic alignment: Leveraging information technology for transforming organizations. IBM systems journal,32(1), 4-16.

Jonkers, H., Lankhorst, M., Van Buuren, R., Hoppenbrouwers, S., Bonsangue, M., & Van Der Torre, L. (2004). Concepts for modeling enterprise architectures. International Journal of Cooperative Information Systems, 13(03), 257-287.

Jonkers, H., Proper, E., & Turner, M. (2009). TOGAF™ and ArchiMate®: A Future Together.  White Paper W, 192.

Jonkers, H., van den Berg, H., Iacob, M., Quartel, D. (2010) "ArchiMate® Extension for Modeling the TOGAF™ Implementation and Migration Phases." Reading, Berkshire: Whitepaper, The Open Group.

Kim, H., & Oussena, S. (2012). A Case Study on Modeling of Complex Event Processing in Enterprise Architecture. Proceedings of the 14th International Conference on Enterprise Information Systems, ICEIS (3), Ealing, United Kingdom, 173-180.

Lankhorst, M. (2004). Enterprise architecture modelling—the issue of integration. Advanced Engineering Informatics, 18(4), 205-216.

Lankhorst, M. (2009). Enterprise Architecture at Work: Modelling, Communication and Analysis (The Enterprise Engineering Series).

Lankhorst, M. M., Proper, H. A., & Jonkers, H. (2010). The anatomy of the ArchiMate language. International Journal of Information System Modeling and Design (IJISMD), 1(1), 1-32.

Meertens, L. O., Iacob, M. E., Nieuwenhuis, L. J., Van Sinderen, M. J., Jonkers, H., & Quartel, D. (2012, March). Mapping the business model canvas to ArchiMate. Proceedings of the 27th Annual ACM Symposium on Applied Computing, Riva del Garda (Trento), Italy, 1694-1701.

Penicina, L. (2013). Linking BPMN, ArchiMate, and BWW: Perfect match for complete and lawful business process models?. Short pap. Proceedings of the 6th IFIP WG 8.1 Work. Conference pract. Enterprise Model, PoEM, 156-165.

Quartel, D., Engelsman, W., Jonkers, H., & Van Sinderen, M. (2009, September). A goal-oriented requirements modelling language for enterprise architecture. Proceedings of the 13th IEEE International Enterprise Distributed Object Computing Conference, EDOC'09, 3-13.

Roose, D., Vansteenlandt, J., Bernaert, M., Poels, G. (2013). Development of a common base for enterprise architecture (Doctoral dissertation). Retrieved from https://www.researchgate.net/profile/Maxime_Bernaert/publication/235336535_Development_of_a_common_base_for_enterprise_architecture_building_the_bridge_between_CHOOSE_and_ArchiMate/links/0912f51101a597859d000000.pdf

Steen, M. W., Akehurst, D. H., Doest, H. W. L. T., & Lankhorst, M. M. (2004, September). Supporting viewpoint-oriented enterprise architecture. Proceedings of the 8th IEEE International Enterprise Distributed Object Computing Conference, EDOC 2004, 201-211.

The Open Group. (n.d.). The ArchiMate project. Retrieved February 15, 2016, from http://www.archimate.nl/en/about_archimate/archimate_project.html

The Open Group. (2012). Language Structure. Retrieved February 14, 2016, from http://pubs.opengroup.org/architecture/archimate2-doc/chap02.html#top

The Open Group (Standard) (C13L). (2013, December). ArchiMate® 2.1 Specification. Retrieved February 11, 2016, from http://pubs.opengroup.org/architecture/archimate2-doc/.

Vicente, M., Gama, N., & da Silva, M. M. (2013, June). Using ArchiMate and TOGAF to understand the enterprise architecture and ITIL relationship. In Franch, X. & Soffe, P. (Eds.), the 8th International Workshop on Business/IT-Alignment and Interoperability, CAiSE 2013: Vol. 148. Lecture notes in Business Information Processing (pp. 134-145). Springer Berlin Heidelberg.

Weerd, I. van de, & Brinkkemper, S. (2008). Meta-modeling for situational analysis and design methods. In M.R. Syed and S.N. Syed (Eds.), Handbook of Research on Modern Systems Analysis and Design Technologies and Applications (pp. 38-58). Hershey: Idea Group Publishing

Zutterman, S., Poels, G., Bernaert, M. (2013). Development of a Tool for Business Architecture Modeling in Eclipse (Doctoral dissertation). Retrieved from https://www.researchgate.net/profile/Maxime_Bernaert/publication/239627425_Development_of_a_Tool_for_Business_Architecture_Modeling_in_Eclipse/links/00b4951c1b49f5cbb3000000.pdf

Appendix

A

Figure 1: ArchiMate modeling framework by Quartel et al. (2009)

B

Figure 2: ArchiMate Architectural Framework view model [retrieved from: https://en.wikipedia.org/wiki/ArchiMate#History]