Strategy, goals, principles, and
requirementsThe current version of the ArchiMate language as specified in this Technical Standard has a strong focus on describing the operational aspects of an enterprise. Although the aim is to keep the core of the language relatively small, a number of directions for extending the language, as well as more advanced tool support for inherent features of ArchiMate models, can be envisaged. In this chapter, we identify some likely extensions for future versions of the language and associated tool support. Furthermore, we look at the construction of the language itself, which lends itself to relatively easy generalization and extension.
In the practical use of ArchiMate, four fields have been identified in which a future extension of the language may be advisable:
Strategy, goals, principles, and
requirements
Evolution and realization of
architectures
The design process
Architecture-level predictions
Recall the definition of “architecture” of ISO/IEC 42010:2007 [2]:
“The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
In the current version of ArchiMate, the emphasis is on concepts related to the first part of this definition, which we could call the “extensional” aspects of the enterprise; i.e., its appearance as an operational entity. The “intentional” aspects – i.e., its business goals, principles, policies, reasons, rules, requirements, and other aspects that influence, guide, and constrain its design and operation – are less well covered. This would be approximately equivalent to the “Why” column of the Zachman framework [5], which was intentionally left out of scope in the design of ArchiMate 1.0.
Thus, an obvious extension is the introduction of concepts to model different kinds of intentionality, both of the enterprise as a whole (e.g., business goals), and of the translation of these into restrictions on the architectural design itself (e.g., requirements, principles, rules, and constraints).
TOGAF makes a distinction between “enterprise principles” (which are closely related to business goals), “IT principles”, and “architecture principles”. Architecture principles can be either principles governing the architecture itself, the process by which it is created, or principles governing the architecture’s implementation. Architecture principles may pertain to the different types of architecture that TOGAF distinguishes; i.e., principles can be classified based on their impact on the business, data, application, or technology architecture.
A topic that is closely related to principles is the use of business rules, which can be seen as a realization of principles. Business rules separate the business logic from the processes, or put constraints on the business operations. Business can be specified not only at the detailed design level and the execution level (i.e., rules that can be directly executed by a rule engine), but also at the architecture level [22].
Second, an architecture description and the ensuing enterprise is not a static, one-shot affair. Its evolution also needs to be supported. This entails adding concepts for describing changes – for example, to define different versions of architecture elements – and the relation over time between different architecture stages; e.g., plateaus or (current and future) states.
Furthermore, these changes are to be brought about in an orderly fashion: they need to have a clear relationship with the organizational goals, principles, and rationale mentioned before, and they should be realized by means of a coherent portfolio of programs and projects that take the enterprise from one stage to another [29]. Hence, the link between ArchiMate models and portfolio management needs to be addressed in a future version of the language. This could also provide an important management tool for overseeing the realization of architectural plans, a kind of “management dashboard”, enabling informed governance.
Third, the language could provide additional support for the early stages of the architecture development process. In these early stages, architects will often use informal, sketchy, and incomplete models that later evolve into formally correct ArchiMate models. Hence, a relaxation of formal correctness criteria in the early design stages might be in order. Support for this design evolution will of course be closely related to the concepts envisaged in the previous section, since design decisions are guided by goals, principles, and requirements, and the design process is instrumental to the evolution of the architecture.
Of course, the concepts for the three areas mentioned need to be highly integrated: goals, principles, and requirements guide the architecture evolution, which in turn is operationalized in part by the design process. Full traceability from high-level goals via design decisions down to the resulting architecture elements is desirable.
When you have to make the business case for different architecture alternatives, it is useful to be able to predict different qualities of the alternatives: performance, costs, reliability, etc., as illustrated for example in [21]. This requires different computational models, from where to some extent existing results can be borrowed; e.g., petri nets [23], system dynamics [24], operations research, [25], etc. Where [21] illustrated the potential of architecture-level predictions, more work is needed to make it feasible to include this in ArchiMate tooling.
Next to the extensions in the areas mentioned above, some definitions of language concepts might also be improved and clarified. For example, the grouping concept could be given more explicit semantics. In practical use, some concepts have been used to good effect for other purposes than strictly intended; their future definitions may be updated to account for such usage.
Practical experience shows that ArchiMate is a useful and practicable tool for high-level enterprise architecture modeling. However, it intentionally does not cover the lower levels of detail of architecture and design for various domains. Rather, it intends to link to more specialized modeling languages for this. In the ArchiMate language definition, several application and technology concepts have a clear link to UML 2.0 [8], [12], as has been described in the previous sections. Similarly, business process concepts are closely related to the Business Process Modeling Notation (BPMN) [26].
Next to these two languages, there are several other relevant modeling techniques. In particular, this includes a number of other OMG standards: the Business Motivation Model (BMM) [27] for specifying the rationale behind an architecture; the Semantics of Business Vocabulary and Business Rules (SBVR) standard [28] for defining natural-language descriptions of business entities; the Business Process Definition Metamodel (BPDM) [29] for specifying detailed business process concepts. Furthermore, the link between ArchiMate and modeling techniques such as i* [30] for requirements modeling, DEMO [10] for transactional models, and e3value [31] for business and value networks could be explored further.
The links between these languages and ArchiMate need to be formally specified, possibly in the form of model transformations as defined in the Model-Driven Architecture (MDA) and the Queries, Views, & Transformations (QVT) transformation language [32]. Preferably, a generic linking mechanism based on these transformations will be defined that can also be used to relate to other, not yet identified languages.
Next to modeling languages, there is also a plethora of architecture frameworks to which ArchiMate can be related. First, there are of course the Zachman [5] and TOGAF [4] frameworks. Other relevant frameworks and conceptual models include DoDAF [33], MoDAF [33], FEA [34], and the CBDI SAE metamodel for SOA [35].
Extensions and improvements to the current version of the language need of course to be approached with caution. A central principle in creating a new language version will be backwards compatibility: a correct model expressed in ArchiMate 1.0 will still be a correct model in future language versions.
Luckily, the design of the ArchiMate language already provides us with an important advantage. Its metamodel is constructed in a stratified fashion, starting from a core set of concepts that are specialized for each of the different layers (business, application, technology) of the language (see Figure 2). This allows us to define a future version of the language explicitly in two strata, akin to the Infrastructure and Superstructure definitions of UML 2.0 [8], [12]. The current version of the language could then be viewed as a specific instantiation (i.e., Superstructure) of the ArchiMate 2.0 core (i.e., Infrastructure). Hence, ArchiMate 1.0 models will be fully correct ArchiMate 2.0 as well.
To make this happen, first a slight clean-up of the current core concepts (the Infrastructure) is needed, resulting in a version 1.1 of the language. Since these concepts are invisible to language users, who only work with the specializations at each layer, the impact of this will be minimal. Based on this version 1.1, a version 2.0 may then be defined that addresses one or more of the extensions suggested above.
Downloads of the ArchiMate documentation, are available under license from the ArchiMate information web site. The license is free to any organization wishing to use ArchiMate entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document C091.