ArchiMate (3.x) example views introduced here are organized into a layered framework according to ArchiMate standard (see ArchiMate version 3.0.1 here). These example views demonstrate how ArchiMate concepts can be used. Some of the examples can be used as design patterns.
ArchiMate Example Views
This view represents the framework that structures all the development aspects and related diagrams. The view can be modified according to what is appropriate in the case. As such, this view can be used for navigation between the diagrams. This version of the view is applied from ArchiMate (3) framework. Motivation is introduced as a “Layer” instead of an “Aspect”.
This view can be used to analysis of the motivations, or reasons, that guide the design or change of an organization and its enterprise architecture. These motivational analysis are the starting points for all the change activities or business transformations in an organization. This view represents the vision of the development endeavour – whether the scale and scope comprises the whole organization or just part of it (e.g. line of business) or single program or project (solution level). Note: a value can be added e.g. to the outcome (or to any other ArchiMate element), to indicate what is the real value add!
Motivational elements are based on Business Motivation Model (BMM) [specification v.1.3, 2015, OMG].
This view can be used to represent the organization’s mission, vision and core values. Mission expresses e.g. “What is the organization’s purpose, what is it actually doing or intents to do, what is the primary reason for its existence?” Vision is the future state towards which the organization intents to evolve. Core values are what support the vision, shape the culture, and reflect what the organization values. Strategic goals need to be accomplished in order to achieve the vision of the organisation.
Reference: Aldea, A. – Iacob, M.-E. – Hillegersberg, J. – Quartel, D. – Franken, H. (2015) Modelling strategy with ArchiMate.
Strategic Value Map View
This view can be used for visualization of the strategies of the organization. This view contains strategic value-elements, from which all the development activities have to be derived – directly or indirectly. By visualizing the strategic values, it can be possible to trace all the other elements that are involved with the actual strategy execution. With this view, the strategy can be made available: visualized, communicated and linked to the reality.
Stakeholder Analysis View
This view can be used for stakeholder analysis for business development purposes: what are the drivers for change. First identify the relevant stakeholders and then the drivers for change that are in the interests of them. The “Assesment” concepts can be used for detailed analysis of drivers, e.g. according to SWOT (Strengths, Weaknesses, Opportunities, Threats) method. As typical, distinct stakeholder view diagrams can be created from different viewpoints. Another reason for splitting large diagrams into smaller, is to keep the diagrams compact and readable – for the sake of simplicity.
This view can be used for linking stakeholder’s drivers to business goals. Goals are the key elements of development in an organization. All the subsequent elements should be traced back to these primary reasons for all the change activities.
Risk & Security View
Mapping of Risk and Security Concepts to the ArchiMate.
SWOT Analysis View
Strategy Layer Views
ArchiMate version 3 now supports business strategy related concepts such as “Course of Action”, “Capability” and “Resource”, which can be used for modeling business strategies of the organization. The value and importance of this view is in the way that the goals of the organization can be linked to strategies, and how they can be linked into enterprise architecture via capabilities. This view can be used to apply the “Goal-Based Strategic Model” (Azevedo et al. 2015), in which goals constitute a hierarchy, so that higher-level goals can be decomposed into lower-level goals.
Business Model View
This is the basic form of the Business Model Canvas (BMC) by A. Osterwalder, but it can be variated according to what is appropriate. There are also versioned approaches such as “Service Model Canvas” or “Lean Canvas”. A BMC can be used e.g. for business model design and innovation.
Modeling a BMC with ArchiMate “facilitates tracing of requirements from business demands down to the design specifications. This helps discovering the effects of business model changes on architectural design.” [L.O. Meertens et al.]
Holistic development includes built-in architecture-support for strategy and business model analysis. This enables business analysts and developers observe e.g. how well business model supports the strategy and how business model fit into the organization, and vice versa.
If the BMC is modeled within a modeling tool, an advantage of this approach is that all the elements of the BMC can be used in other views of the same model repository. And when pivoting the business model, all the changes are immediately visible. Business modelers can create new elements such as services, or utilize all the existing elements in the repository such as organization units or resources.
Business Motivation Model (BMM) View
This view can be used to gathering requirements based on the strategic goals. This is linking the strategies to implementations: it is possible to trace strategies to execution.
Strategy to Capability View
This view can be used for Capability-Based Planning (CBP) purposes, together with other ArchiMate concepts such as “Driver” and “Goal” as shown in the diagram below. This view can be used to support Strategy Planning (and -Execution) purposes. As such, this kind of views can be used in Strategy-to-Capability phase, which can be included in the “Strategy-to-Portfolio” in IT4IT.
Capability Map View
This view can be used for giving an overview of organizations capabilities: what the organization does or can do.
Capability Planning View
This view can be used for e.g. Capability-Based Planning (CBP) purposes, which is “the Link between Strategy and Enterprise Architecture”. This view can be used for e.g. mapping strategies to required capabilities, and mapping capabilities to resources and other building blocks.
Capability Realization View
Business Architecture Layer Views.
In each layer there are several “maps” of elements that are managed within the EA-tool, such as Business Services Map, Process Map etc. After identified and introduced maps, those elements may be used in other diagrams (such as layered views). The purpose of the maps is to manage catalogs of “EA assets” as “portfolios” (analogous to portfolios of ideas, services and projects etc.). EA-tools typically provide other features for each element, e.g. properties or attributes. Those can be used to provide additional information per each element. This kind of extra information can also be used in different kinds of analysis purposes.
There can be several maps on each layer e.g. as follows:
- In Business Layer: Business Service, Business Actors, Business Processes
- In Application Layer: Application Services, Applications
- In Technology Layer: Technology Services, Platforms, Technologies etc.
Some example business layer maps are introduced here.
Business Services Map View
This view gives an overview of the business services of the organization. This kind of view can be used as “Service Catalog” or “Service Portfolio” management purposes. It is important to identify what are the business services the organization is providing to its customers. In addition, a business service is a starting point for modelling all the underlying organizational processes and structures. As such, business services are the most important elements of the enterprise architecture.
Business Process Map View
This view can be used as “Process Map” which gives an overview of the business processes of the organization.
Business Process Co-Operation View
This view can be used e.g. for modelling the operating model.
Business Actors Map View
Business Actors can be a) internal or b) external. Internal business actors are e.g. organization units, and external business actors are e.g. customers, business partners, or other stakeholder groups that co-operate with the organization (such as public sector organizations or other governance authorities).
Business Actor Co-Operation View
a) Intra-Enterprise View: Business actor co-opertation view that depicts how internal business actors co-opearte, how they switch information.
b) Inter-Enterprise View: The Ecosystem viewpoint that depicts the operational environment in which an organization operates is a network of organizations and business partners, what are the concerned interactions and collaborations. There are suppliers, sub-contractors and other b2b partners, customers etc.
Business Process View
This business process view provides a “high-level structure and composition of a business process (or several processes), the services that are offered, the assigned roles of actors, and the information used by the business process” [ArchiMate 2.1 specification]. This process diagram contains “Junction” -elements to model “fork” and “join” in the process flow.
Business Process View With Roles As “Swimlanes” of a Process – A Layered Approach
Customer Journey Map View
This customer-centric viewpoint is focusing on customer experience. This “service design” related approach is concentrating the “outside-in” development of the service that is to be designed. This highlights the services and products as essential aspects that produces value to customers – and indirectly to the organization itself. A customer journey path can be used to visualization of a customer value stream, which spans over several application services and applications.
Service Blueprint View
This viewpoint is customer- and service-centric, but it emphasizes also the “inside-out” part of the service. With the help of this approach the service-driven development can identify the underlying behavioral and structural impacts of the service that is to be designed. As such, this viewpoint complements the customer-experience driven approach with process- and functional aspects.
There are several variations of this view. This example above focuses on information flows between the layers and elements.
User Story View
This view can be used to visualization of user stories.
Cloud-Service Models View
Information can be modelled on different abstraction levels as follows: a) conceptual, b) logical and c) physical levels. The diagram above illustrates these abstraction levels.
Conceptual Data Model View
Information architecture of EA contains business objects a.k.a. concepts, that are used in business processes. These concepts and their relations can be represented in a conceptual data model (see figure below).
The service-concept is quite often problematic, as can be understood in many different ways. To make clear distinction which service type is in question, good practice is to mention the prefix: business-, application- or technology service. The IT Service is related to production service according to ITIL. As such. IT Service maps to the Application Services the most.
Application Architecture Layer Views.
Application Services Map View
Applications Map View
Application portfolio, in which applications can be divided into groups e.g. based on business units.
Application Co-Operation View (Data flows)
Application Integration View (Dynamic relationships)
Several alternative approaches of modeling data switching between applications are shown in the examples (1 to 10) below.
- “Application A” owns a data object “A-1”, which is requested by “Application B”.
- Data flows from “Application A” to “Application B”.
- “Application A” realizes a service “A-1” that is used by “Application B”.
- Practically, “Application B” requests the Application Interface “A-1” and gets response…
Application Structure View
This view is useful in designing or understanding the main structure of an application and its sub-components and the associated data. This diagram can be used e.g. to break down the structure of the application system under construction, to illustrate modularization / decomposition: what are the sub-systems / sub-components what are the application services (or application interfaces) they provide.
Note that application services (figure above) are the behavioral functionalities that are provided by the structural interfaces (GUIs and/or APIs in the figure below). Application Services and Application Interfaces are the “different sides of the same coin”.
Application Architecture View
This view mixes EA level and solution level approaches, as there are are both applications and application modules in the same view.
Application Component Model 0-n
Application Component Model 0-n is an application architecture approach, which consists of diagrams of different abstraction levels.
- At 0-level the diagram consists of enterprise architecture level components and their services.
- At 1-level the target application is decomposed into modules.
- At 2-level the modules are decomposed into sub-components.
Component Model diagrams below consist of application components and application services. Alternatively, application interfaces can be used instead of application services.
Application Component Model – 0
Application Component Model – 1
Application Component Model – 2
Application Functions View
Application functional decomposition: what are the functions the system contains, and which application services they provide?
Application Process View
Layered View can be used as an overview context diagram of the target area. The main advantage of this view is to illustrate the usage of applications in business processes and services they provide.
Technology Architecture Layer Views.
This view represents a platform of an application. This pattern can be used to model a configuration of run-time environment, the deployment of the business application.
Implementation and Migration Layer / Transformation Architecture Layer Views
Kanban board can be used for visualization of work and the workflow. Kanban board shows how e.g. development requirements, epics, user stories etc. are flowing from backlog to ready state (Done). Kanban board can be applied for diverse purposes depending on the scale and scope of the development case. E.g in EA level by using “Epics” or in project level by using “User Stories” or “Requirements” as work items. The granularity of work items can vary depending on the case.
This kind of simplified view can be used e.g. as contextual diagram of specific service, program or project.