Translations of this page:

Content and Output Architecture Framework

This chapter sets out exactly what Authority Architecture objects are of interest when constructing the model and its architectural outputs as a way of describing the Authority Architecture picture.

In particular, the chapter focuses on the elements of the metamodel and the formal (delivery objects) and informal (artifacts) architectural outputs.

A metamodel is a prescription and logic for using a language to model architecture in practice. In the creation of the National Architecture of the National Security Council, models will be created in the ArchiMate language according to a pre-approved metamodel. The use of the metamodel is fully compliant with the specifications of the ArchiMate language and the TOGAF architectural framework. The architecture metamodel clearly defines which elements from the TOGAF and ArchiMate specifications, and the relationships between them, are used.

  • Total TOGAF 9.2 and ArchiMate 3.1 language metamodel - Lists all elements, their relationships, and defines how they will be used. This metamodel is too complex and has therefore been reduced to the overall metamodel of this methodology.
  • Comprehensive metamodel of this methodology - Represents the enumeration of all elements and their bindings that have been taken into NAR from the overall ArchiMate language specification in version 3.1.
  • Domain Metamodels - Domain metamodels describe a specific domain of interest. The TOGAF framework recognizes four basic architecture domains: business architecture, data architecture, application architecture, and technology architecture. Therefore, a metamodel has been created for each of the mentioned architecture domains, and successively for the so-called vertical domains, which have their origin in the ArchiMate motivational extension and other frameworks, first for Strategic Routing, see the domain overview in Structure of modelled architectures.
  • Minimal metamodel - even the selection of elements from the standards into the overall metamodel is too broad and difficult to use for initial engagements. Therefore, even its minimalist, reduced form is recommended in this section, suitable for the first few typical architectural engagements of the Authority.

The rationale and guidelines for using metamodels in the development of specific models are as follows:

  • A metamodel is an abstract model of the modelling, important for correctly capturing and highlighting objects and relationships in the authority model (what to model and how to model it),
  • The metamodel supports a specific method or a specific modeling procedure (prescribes the modeling language, the elements used and the possible links).

The ArchiMate modeling language is composed of basic building blocks called elements (features, concepts). It has been designed with the support of a few basic principles, these are:

  • three basic architectural layers (business, application and technology) and three extension layers (strategic, physical and implementation)
  • four aspects (motivational, active, behavioural and passive)
  • internal and external active and behavioural elements of the model
  • individual and collective active and behavioural elements of the model
  • specific elements of Cluster and Location

 Layers and aspects of the ArchiMate language (The Open Group, 2017)

Aspects of the ArchiMate language

The language is composed of elements that fall into four categories:

  • active,
  • behavioral,
  • passive, and
  • motivational

In this division we can find a similarity with natural language, where active structures correspond to the subject, behavioral to the verb, and passive to the object. Active elements are defined as elements performing an action (example: business actors, application components and devices). Behavioral elements are defined as a unit of activity performed by one or more active elements (example: process). Passive elements are defined as objects with which an activity is performed.

Added to this are the motivational elements of the language, which tell why the structure of the main (core) elements is what it is and, in particular, why it should change to its target form.

Layers and diagram structure in models

In diagrams, the layers (or structure) of models should be distinguished by visual arrangement. The basic elements of the model layers (business, application and data, technology, infrastructure) will always be distinguished by color. The individual elements of the views are also vertically (top to bottom and vice versa) connected between layers by logical links.

The methodology assumes that the distinctive information contained in the views of the model is also the location of the model elements in its surface, in the so-called maps, also referred to as the topology of the elements. For a uniform logic of the placement of elements in diagrams, sequentially constructed reference models to each layer of the architecture and to each view of it are used.

Element colours

The ArchiMate 3.1 standard specification does not prescribe element colors, but allows them to be used in a uniform manner. It leaves the decision on color to the architect and his tool.

The NAR goes further in this regard and prescribes basic element colors in the tables below to facilitate uniform reading and interpretation of model diagrams. The RPG color scheme is not mandatory, but recommended.

If an architect expresses a key feature of an element in some diagrams by color, for example, that it comes into being, changes or disappears, he can use other colors, but he must always add a color legend.

Element colours by aspect

If the metamodel needs to emphasize an element's belonging to an aspect of the language, it does so by using shades of gray as follows:

  • white - abstract elements (categories) that do not have instances
  • light grey - passive structures
  • medium grey - behaviour
  • dark grey - active structures

Colour of elements of basic layers (domains).

The defined structure of the ArchiMate metamodel is divided into three layers, which are extended to four layers in order to respect the four-layer vision of the Czech Republic's eGovernment architecture. Each layer has a coloured interpretation according to the recommendations of the original ArchiMate specification, according to which it is possible to determine which layer it is. This colour standard must be respected and adhered to.

  • Business layer and all elements in this layer defined by the ArchiMate language will be yellow,
  • Application and data layer and all elements in this layer defined by ArchiMate language will be turquoise,
  • Technology layer and all elements in this layer defined by ArchiMate will be green (possibly lighter green),
  • Infrastructure layer and all elements in this layer defined by ArchiMate language will be green (possibly darker green).

Components of both technology layers of the four-layer VS architecture vision (IT technology and infrastructure) may be in the same green, as in reality these layers are only a special division of the unified technology architecture of the ArchiMate standard for the Czech needs of managing responsibility for different technology services.

In accordance with the ArchiMate specification, NAR does not recommend using color interdivision of the so-called aspects in each layer (active elements, behavioral and passive elements) - color differentiation is not necessary, and if so, only grayscale.

Coloring of Motivational Architecture Domain Elements

The latest version of the ArchiMate 3.1 standard introduced new colors for new domains (strategic and physical) and moved many elements from the business domain to the strategic domain. This created a discrepancy in the color scheme of the elements relative to the original NAR domain color scheme, see Structure of modelled architectures.

This discrepancy has yet to be resolved. The problem is that, on the one hand, NAR is accounting for domains and elements that are not yet in the ArchiMate standard, and when they (presumably) do appear in it, they may be a different color than NAR is currently planning. At the same time, there is the problem of efficient use of the modeling tools, where the easiest way is to keep the elements in their original ArchiMate color.

Table of ArchiMate 3.1 color definitions1))

Domain Color Name Color Definition (RGB)
Red (R) Green (G)Blue (B)
Motivational Violet 204 204 255
Strategic Ocre 245 222 170
Business Yellow 255 255 175
Applied Turquoise 175 255 255
Technology Green 175 255 175
Physical Green 175 255 175
Implementation and\migrationLight Red 255 224 224
Composite Light Green 224 255 224
No colour (white)- (255) - (255) - (255) - (255)
Orange 255 185 115

Shapes of elements

Elements in all layers will be displayed as the ArchiMate language defines them. For standardized and mandatory diagrams, it is not allowed to modify their shapes given by The Open Group standard.

However, in addition to (and in addition to) this, it is possible to create arbitrary and varied so-called lay diagrams based on a correctly captured office model, presenting the model to untrained readers through intuitive (often naive and naturalistic) icons and animations.

Higher versions of the ArchiMate specification

This version of the modeling methodology and metamodel in NAR is based on the current version of the ArchiMate specification, referred to as 3.1. As more extensions and new versions have already been announced for 2019, the NAR metamodel will need to be continually updated. However, it is expected that the new versions of the specification will be largely backward compatible and thus will not have a major impact on the rules and examples already expressed in this methodology.

Overview of ArchiMate 3.1 elements and their localization

Domain Original name Generic translation Adaptation for NAR
Motivational Stakeholder Interested
Driver Motivator, influence, driver Public need, driving element
Assessment Influence assessment Need assessment
Goal Objective Strategic goal, policy
Outcome Output
Principle Architectural Principle
Requirement Requirement Key Architectural Requirement
Constraint
Meaning Significance
Value Value Value of Service VS
Strategic Course of action Course of change Course of change, process, initiative
Capability Ability Authority Capability
Resource Resource
Value stream Value chain Service delivery manager
Business Business interface (Business) interface Service channel VS
Business role Role Role in public administration
Business collaboration (Business) collaboration Collaboration in VS
Business function (Business) function
Business process Process
Business event Event Life event
Business interaction Interaction Interaction in VS
Business service (Business) service Service of public administration
Business object (Business) object VS object
Contract Contract
Representation Representation
Product Product Product VS for RU
Application Application component Application
Application interface (Application) interface
Application collaboration
Application service (Application) service
Application function (Application) function
Application interaction (Application) interaction
Application process (Application) process
Application event (Application) event
Data object (Data) object Logical data
Technology Node Uzel
Communication network (Communication) network Data network?
Device
System software System software
Technology collaboration
Technology interface
Path Path
Technology service (Technology) service
Technology function (Technology) function
Technology process (Technology) process
Technology interaction (Technology) interaction
Technology event (Technology) event
Artifact Artefact Physical data
Physical Equipment Equipment/Tool
Facility Building
Distribution network Distribution path
Material Material
Implementation and migration Work package Work package
Deliverable Subject of delivery / fulfillment
Implementation event Implementation event
Plateau Architecture status
Gap Difference
Composite Grouping Grouping
Location Location

The coloring of the elements in the table2)) is 100% taken from the original ArchiMate 3.1 specification.

Overview of ArchiMate bindings

The following table3) provides an overview and explanation of each binding:)

Concept Description Symbol
Structural Bindings
Business function A collection of business behavior based on a chosen set of criteria (typically required business resources and/or competencies), closely aligned to an organization, but not necessarily explicitly governed by the organization..
Business process A sequence of business behaviors that achieves a specific outcome such as a defined set of products or business services (ArchiMate). Processes represent a sequence of activities that together achieve a specified outcome, can be decomposed into sub-processes, and can show operation of a function or service (at next level of detail).\

Processes may also be used to link or compose organizations, functions, services, and processes (TOGAF).
Event /life event A business behavior element that denotes an organizational state change. It may originate from and be resolved inside or outside the organization.
Interaction A unit of collective business behaviour performed by (a collaboration of) two or more business roles.
Business service of public administration An explicitly defined exposed business behaviour (ArchiMate).

A service delivers or supports business capabilities through an explicitly defined interface and is explicitly governed by an organization (ie. has a SLA contract) - TOGAF.
Contract A formal or informal specification of an agreement between a provider and a consumer that specifies the rights and obligations associated with a product (ArchiMate).
Representation A perceptible form of the information carried by a business object. Form of existence and perceptibility of the business object and its information, for example, electronic, voice, paper, material, etc.
Product VS for ŽS A coherent collection of services and/or passive structure elements, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers (ArchiMate). The business product of the execution of a process.
««Agenda» It does not have, see business function
«<Agenda activity » It does not have, see business function
«Organization» It does not have, see actor (ArchiMate).\

A self-contained unit of resources with goals, objectives, and measures. Organization units may include external parties and business partner organizations (TOGAF).
««BODY» None, see actor.

Interpretation of the business architecture metamodel

An office system has an architecture; this consists of elements and their relationships. The whole authority as a system (enterprise) is divided into smaller parts, down to the smallest and further indivisible capabilities of the authority to perform activities( Capability. Each sub-capability of the Authority has its architecture at all layers. Dividing the authority into capabilities and evaluating them is part of the architectural vision phase, but is crucial to understanding the business architecture of the authority.

Active elements of the office BA

The basic active elements of the authority are internal actors (officials) and some external actors (subjects of law) who enter into interactions (interactions) with each other in different roles that they take on dynamically and temporarily.

The actors in the roles use service channels to provide and receive public administration services. When the cooperation of multiple providing actors is required for the realization of a service, their mutual cooperation is preferably modeled as a special type of active element - collaboration. Another specialised actor type is the organisational unit.

Actors are recognized by the fact that they always have some unique identity, as opposed to roles.

Elements of BA office behaviour

The actor elements of the office structure are endowed with (can, have) internal behaviours, they have a business function. The business functions can be managed in their exact order as a business process, ending with a process interface for the client - a business service or product.

A special, collective type of internal behaviour is the so-called interaction of cooperating actors.

A special type of behaviour of active elements, which has no duration, is an event. Internal and external events can happen in an office system. Some external events happen to law actors in the roles of clients and are called life events.

A specialised type of behaviour of an authority is its each so-called agenda, expressed as an aggregation of all the functions needed to execute the agenda, recorded as so-called agenda activities.

An outwardly visible element of an authority's behaviour and part of its products is its public service, which is of value to the client.

Passive elements of the BA of the Authority

The input and output of the behaviour of the bureau are the physical and electronic representations of the things that are the subject of the bureau, the so-called objects of law. These have meaning for the participants in the behaviour.

A special type of business object is a contract, representing the arrangement of two or many actors or the conditions under which a behaviour is performed and a product is delivered. A specialised type of contract is a legal regulation of various legal force (law, decree, resolution, methodology, etc.), for the sake of brevity called here the term «Regulation». By its very nature, the concept of Prescription in NAR belongs to one of the motivating domains, namely the Compliance, Standardization and Long Term Sustainability domain, but this is not known in the ArchiMate language. Therefore, a specialized object from the business layer is used.

All other "things" that are part of the internal or external environment of the office and do not have a separate concept in one of the domains are also modelled as a business object in the BA layer.

Bureau BA Composite Elements

A composite element of this layer, which may include a number of others, is called a product. This element corresponds exactly to the marketing definition of a product - only when a good or service is accompanied by business terms and conditions (contract, SLA), documentation, data, service and other components, it becomes a product that can address the needs of the client, in this case his situation in relation to the public administration, arising from his life event.

The data architecture according to TOGAF in ArchiMate does not have its own layer, its objects are distributed in all three basic layers. They represent passive elements, i.e. what the systems are about, what they handle. Basically, these are three levels of abstraction.

While data modeling talks about conceptual, logical and physical data objects, TOGAF talks about data entities, logical and physical information components, ArchiMate uses the following representation, see the following figure.

 NAR Data Architecture Metamodel

A Business Object / Public Administration Entity (orig. Business Object) represents all the things that simply are in a public administration environment. And some of them are interesting to us to the extent that we keep data records about them. The object in the model represents the conceptual level of data modeling.

A data object is a logical representation of a real object, projected onto the information systems layer. It tells about the structure of the data kept in the IS and represents the logical level of data modeling.

A data artifact, i.e. a file, table, disk record, is a physical representation of the data about an object. An artifact is also used as a physical representation of SW, either application component or system SW.

A data architecture has only passive elements, it has no active or custom composite elements, and no behavioral elements. It can preferably use the composite concept of Clustering.

This section defines the Application Architecture metamodel in both its full and reduced versions.

The structure of the metamodel elements (concepts) fully corresponds to the basic aspects of the ArchiMate language, similar to the other base layers.

 Full IS layer metamodel according to ArchiMate 3.1 specification, source: (The Open Group, 2017), translation by MV

We anticipate that in practice it will be useful to reduce both the number of model element types and the number of types of constraints allowed. The currently recommended reduction of the AA metamodel, at the same time considered as the minimum possible, is shown in the following diagram:

 selection from the ArchiMate 3.1 IS layer specification, source: (The Open Group, 2017), modified by MV

Definition of application architecture metamodel elements

Table4)) with definitions of application architecture metamodel elements

Element type name Element type definition NAR definition
Application Component 1) An encapsulation of application functionality aligned to implementation structure, which is modular and replaceable. It encapsulates its behavior and data, exposes services, and makes them available through interfaces (ArchiMate). Applications use data and are supported by multiple technology components but are distinct from the technology components that support the application (TOGAF 9.1). It encapsulates its behaviour and data, offers its services and makes them available through interfaces.\\\2) An application component is an installed and operational IT system that supports business functions and services. Applications use data and are made up of technology components.
Application interface A point of access where application services are made available to a user, another application component, or a node.
Application service An explicitly defined exposed application behavior (ArchiMate).\\\The automated elements of a business service. An information system service may deliver or support part or all of one or more business Services (TOGAF).
Application functions Automated behaviour that can be performed by an application component. An application's ability to provide support for a specific business function or process. An application function is always contained in an application component and can be provided to a business function or process as an application service.
Application interaction An application interaction represents a unit of collective application behavior performed by (a collaboration of) two or more application components. An application interaction is a behavior that can be performed solely in collaboration of two or more application components. |Application process |A sequence of application behaviors that achieves a specific outcome. |Application process represents application behaviors (functions or interactions) that are managed specifically in their fixed order (automated).
Application event An application behavior element that denotes a state change.
Communications network A set of structures and behaviors that connects computer systems or other electronic devices for transmission, routing, and reception of data or data-based communications such as voice and video.
Device A physical IT resource upon which system software and artifacts may be stored or deployed for execution.
System software Software that provides or contributes to an environment for storing, executing, and using software or data deployed within it.
Technology interface A point of access where technology services offered by a node can be accessed.
Technology Process A sequence of technology behaviors that achieves a specific outcome. Technology Process A sequence of technology behaviors that achieves a specific outcome. Technology Process
Technology Interaction A unit of collective technology behaviour performed by (a collaboration of) two or more nodes.
Artefact A piece of data that is used or produced in a software development process, or by deployment and operation of a system.
Technology componentAn encapsulation of technology infrastructure that represents a class of technology product or specific technology product (TOGAF only). Modelled as a Node (ArchiMate)

Interpretation of the technology architecture metamodel

The technology architecture metamodel element types do not yet have an interpretation.

The Communications Infrastructure Metamodel is identical to the metamodel of any other ICT technology infrastructure, in the architectural deliverables it will mostly represent a standalone view or be part of a four-layer eGovernment architecture view.

When the ArchiMate standard is extended to include physical world (non-IT) elements, these elements are part of this NAR architectural domain as they closely match its original purpose within the four-layer architecture vision.

 Physical Infrastructure Metamodel.

Definition of the elements of the physical architecture metamodel

The table5) only shows the definitions of the metamodel elements from the ArchiMate physical architecture layer, as the technology architecture concepts from the previous section apply in full to the communication architecture elements, except for their possible specialization, see below.

Element type name Element type definition NAR definition
Equipment/Tool One or more physical machines, tools, or instruments that can create, use, store, move, or transform materials. One or more physical machines, tools, or instruments that can create, use, store, move, or transform materials. For NAR, especially non-IT active technology elements (furniture, shelving, etc.)
Building A physical structure or environment.
For NAR in particular buildings (e.g. data centres) and building and equipment technologies (elevators, air conditioning, etc.).
Distribution path A physical network used to transport materials or energy. Physical network used to transport materials or energy.
Material Tangible physical matter or physical elements.

Interpretation of the metamodel of communication and physical architecture

The element types of the communication and physical architecture metamodel do not yet have an interpretation.

Specialization of communication infrastructure metamodel elements

If there is a need to emphasize the distinctness of the communication infrastructure at the metamodel level, all metamodel concepts used can be so-called specialized, see figure below.

 draft specialization of ArchiMate technology layer objects for communication infrastructure, source: MV using (The Open Group, 2017)

However, for common use in the types of engagements listed here, specialization for technology infrastructure elements is not anticipated or required.

According to NAR, the Strategy Architecture is the first, most important, and currently the most comprehensive domain of the individual incentive architectures - the vertical domains.

It combines the motivational architecture according to TOGAF6) and the so-called motivational and strategic7) layer according to ArchiMate. This is the reason why elements of multiple colors are combined in the metamodel of the strategic and directional domains in NAR.

 Full metamodel of the Strategic Motivation Architecture.

 reduced selection from the ArchiMate 3.1 motivational and strategic extension specification, source: (The Open Group, 2017), modified by MV

The metamodel does not contain all possible constraints because each element in the motivational resolution may be an aggregation/specialization of an element of the same type (e.g., a goal may aggregate into subgoals).

=== Definition of the elements of the strategy and direction architecture metamodel ===.

Table8)) with definitions of strategy and direction architecture metamodel elements

Element type name Element type definition NAR definition
Interested The role of an individual, team, or organization (or classes thereof) that represents their interests in the outcome of the architecture.
Motivator, influence An external or internal condition that motivates an organization to define its goals and implement the changes necessary to achieve them. External or internal influences that motivate an organization to define its goals and implement the changes necessary to achieve them.
Influence assessment The result of an analysis of the state of affairs of the enterprise with respect to some driver.
Strategic goal A high-level statement of intent, direction, or desired end state for an organization and its stakeholders (ArchiMate). Typically used to measure success of an organization (TOGAF). A high-level strategic statement of interest, direction, or end state used to align the approach of an organization and its stakeholders. Typically used to measure the success of an organization.
Output/Result An end result that has been achieved.
Principle A qualitative statement of intent that should be met by the architecture (ArchiMate). Has at least a supporting rationale and a measure of importance (TOGAF). Qualitative statement that should be met by the implemented architecture. The principle contains a rationale and a measure of importance.
Requirement A statement of need that must be met by the architecture (ArchiMate).
\A quantitative statement of business need that must be met by a particular architecture or work package (TOGAF).
Constraints A factor that prevents or obstructs the realization of goals. Factor that prevents or obstructs the realization of goals.
Significance The knowledge or expertise present in, or the interpretation given to, a core element in a particular context.
Value The relative worth, utility, or importance of a core element or an outcome.
«Objective»A time-bounded milestone for an organization used to demonstrate progress towards a goal (TOGAF only) |Time-bounded milestone for an organization used to demonstrate progress towards a goal (TOGAF only). |Direction of change |An approach or plan for configuring some capabilities and resources of the enterprise, undertaken to achieve a goal (ArchiMate). |Direction and focus provided by strategic goals and objectives, often to deliver the value proposition characterized in the business model (TOGAF).
Value chain A representation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end-user (TOGAF only).

=== Interpretation of the strategy and direction architecture metamodel ===.

The Strategy and Direction domain metamodel does not currently contain concepts for all components of strategic management. Such objects not currently captured in NAR are:

  • Organization mission
  • The organization's vision

Both of these elements are the pure intrinsic motivation of the organization, so we are more inclined to recommend modeling them with the "Value" element, in this case a common, shared value for all categories of stakeholders in the organization, than anything else. Both elements, however, represent a concept with a unique occurrence in each organization (the organization has or does not have a mission and vision statement), so we suggest not to model these objects at all and to derive more substantive elements, such as goals and principles, from them in the model.

Note: Any change, in any of the horizontal domains of the architecture, should have a motivation, based on strategy and direction, expected performance, new risk or new regulation by regulation. Therefore, elements of the vertical, motivational domains can be expected in the Authority's model, divided by the horizontal domains as well. Thus, for example, we find application drivers, application goals, application activity directions, application outcomes, application principles, and application architectural requirements.

The concept of "Resource" in the strategy and direction architecture means "resource for providing capability change", not resource for routine capability execution.

A "capability", as specified in Modeling Offices and their Architectures, is not the typical domain type of the elements that make up an architecture, but the capability is the smallest part of the organization for which the architecture is sought and designed. The capability map is used to get an overall view of the organization. Capability Based Planning is a management technique for planning improvement and meeting strategic objectives without detailed knowledge of the architecture of each capability.

The element type "Value" has two most important meanings for NAR, both meanings are not yet a reason to specialize the stereotypes, they are likely to be used infrequently in the early periods of NAR use:

  • Value of change to stakeholders.
  • Value of the product/service to clients

The "Value Chain" element type is so far only part of the TOGAF standard, but is expected for the ArchiMate 3.1 standard.

The Performance Architecture NA VS CR does not have any specific metamodel elements defined yet. We expect that in future versions of ArchiMate a looser use of the Metrics object (KGI9), KPI10) (especially TCO11)), PPI12)), PI) than is currently the case as an outcome measure of need assessment, in motivator architecture.

So far, each model object can have metrics assigned in the attribute profile. Performance indicator types are not yet modeled.

The performance, quality and accountability architecture should be used to support performance management, quality and accountability in public administrations. Performance, quality and accountability management in public administration is mainly linked to the organisation's efforts to do the right things in the right way, i.e. in a quality, efficient, cost-effective and timely manner.

The basic three sets of indicators are usually hidden under the acronym 3E:

  • Economy - refers to the cost of resources for the inputs consumed. Economy metrics are used to assess whether an appropriate price is being paid for the acquisition of necessary resources.
  • Efficiency (Effectiveness) - efficiency represents the relationship between inputs and outputs, it is the ratio of outputs achieved to inputs consumed. Efficiency is an expression of the "doing things right" dimension and indicates performance in terms of how an activity is carried out.
  • Efficiency - is an expression of the degree to which the outputs produced lead to the expected results. Effectiveness metrics focus on the strength of the relationship between the intervention undertaken and the outcome achieved. Effectiveness is an expression of the "doing the right thing" dimension and indicates performance in terms of the choice of action that is taken.

Related to this is the so-called Logic Model of Performance Management, developed on the basis of input from the ECA and the MoF:

 Logical framework of performance, quality and accountability, source: adapted 2016 by (Hrabě, 2013).

For performance management, quality and accountability, a similar paradigm applies as below for safety:

It is not possible to manage the performance, quality and accountability of the elements of an authority's system without knowing and understanding them well, for example through the authority's architecture.

The performance domain adds several specific elements (objectives, indicators, evaluations, measures) to the basic objects of the authority architecture. These are largely modelled by the concepts of business and incentive architecture, their specialisations or, in the future, by separate specific concepts, similar to the security architecture.

Defining the elements of the performance architecture metamodel

Table13) with definitions of performance architecture metamodel elements

Element type name Element type definition NAR definition
«Metric» (Measure)
«<Service Quality»\\
(Service Quality)
A preset configuration of non-functional attributes that may be assigned to a service or service contract (TOGAF only).
Performance Indicator PI, KPI, PPI Not included in ArchiMate
Quality Mark Not included in ArchiMate
Nonconformity Not included in ArchiMate
Appreciation

Interpretation of performance architecture metamodel elements

Many of the elements will be repeated from the previous strategy and direction domain, but will have a different purpose when used in the model. For example, in the Performance, Quality, and Accountability Architecture, the concept "Resource" means "resource for delivering the activity".

The SA Security Architecture does not yet have any specific metamodel elements defined. We anticipate that these will later be risks and measures associated with the main objects of the model.

It can be assumed, according to The Open Group's Whitepaper and the development of some modeling tools, that the ArchiMate language and the TOGAF standard will add the following concepts in the future

 ISSRM domain model, source: The Open Group (Band, et al., 2015)

Specific security and risk management concepts can be modeled in the current ArchiMate standard using the concepts of business and motivational architecture or their specialized stereotypes, see diagram:

 ArchiMate security architecture metamodel, source: The Open Group (Band, et al., 2015)

The diagram highlights, among other things, the basic principle of security architecture:

Everything that is part of an organization's system and that we model in other domains can be compromised and needs to be protected, but at the same time almost all of it is a means of such protection for other things.

This also implies that a good model of the Core14) elements of an authority's architecture is a prerequisite and input to its security architecture.

Overview of the necessary security architecture elements and their location

Table15) with definitions of security architecture metamodel elements

Original name Generic translation
Threat Threat/threat
Threat agent / actorThreat agent / actor
Threat event Threat event
Loss event Loss event
Risk/security driverSecurity motivator/influence
Risk Risk
Vulnerability Vulnerability
Control objective Control objective
Security principle Security principle
Control measure Security measure
Security domain Security domain

Definition of security architecture metamodel elements

Table16)) with security architecture metamodel element definitions

Element type name Element type definition NAR definition
Threat/Threat A Threat is a negative scenario you want to avoid.
Threat Agent The term Threat Agent is used to indicate an individual or group that can manifest a threat. It is fundamental to identify who would want to exploit the assets of a company, and how they might use them against the company.\\\The the person, actor, entity, or organization that is initiating the given threat scenario.\
Threat agent is modeled with the business actor construct, but other active structure element can be used (e.g. business role, application component, etc.)
The term "Threat Agent" is used to indicate an individual or group that can manifest a threat. It is critical to determine who might want to use the organization's assets, and how they might use them against it.\\\The person, actor, entity, or organization that triggers a given threat scenario.\\\\The "threat/threat agent" is modeled using the "business actor" element type, but other active structure elements (e.g., business role, application component, etc.) can be used
Threat Event A Threat (event) is a negative event that can lead to an undesired outcome, such as damage to, or loss of, an asset. Threats can use-or become more dangerous because of-a vulnerability in a system.\
Threat event (event with the potential to adversely impact an asset) as well as loss event (any circumstance that causes a loss or damage to an asset) are modeled with the business event construct and are considered as a specialization of it.
Threat (event) is a negative event that can lead to an undesired outcome, such as damage to, or loss of, an asset. An attacker can exploit a vulnerability in the system and this vulnerability can make the threat/endangerment more dangerous.\\A threat/endangerment event (i.e., an event with the potential to adversely impact an asset) and a loss event (any circumstance that causes loss or damage to an asset) are modeled using the business event element type or a specialization of it.
Loss Event A Loss Event is a circumstance that produces the loss and harm impacts from actual events and reflect the organisation's own experience.
Security driver/impact Risk / security driver are the criteria by which risks are analysed and are represented with the driver construct. It is represented by an element of type motivator.
Risk
Features Security requirement and control measure are two specializations of the requirement construct, a control measure being more specific (i.e. close to the implementation) than a security requirement. Security requirement and control measure are two specializations of the requirement element type, a control measure being more specific (i.e. closer to the implementation) than a security requirement

Interpretation of the security architecture metamodel

The security architecture metamodel element types do not yet have an interpretation.

The standardization and sustainability area of the NA VS CR does not yet have any specific metamodel elements defined in international standards. We anticipate that specialized elements of the business and incentive architecture will be used as needed, in terms of objectives, requirements or constraints.

In addition, the content of the standardisation will be expressed by declaring each individual architecture element or combination of elements as an architectural building block (ABB), a solution building block (SBB) or an architectural pattern (pattern).

In accordance with its name, this domain focuses on the management domains that regulate the activities of authorities (OVS), namely:

  • Compliance with regulations. According to the Constitution and the LPSA, public authorities may only do in the exercise of public authority what is expressly prescribed by law or by subordinate legislation.
  • Standardisation. Public administration limits the scope for independent decision-making and thus the complexity of its environment by "voluntarily" issuing standards (of processes, IT, services, security, etc.) or adopting independent external standards (ISO, CSN, etc.).
  • Sustainability. Public administrations set sustainability criteria (limits) for their regulatory areas (agendas) as well as for their own organisation and internal activities, in the economic, social and environmental fields. A typical initiative in this area is CSR17).

Compliance metamodel

The basic object of compliance is the "regulation" object. This object is not a standard part of the ArchiMate specification, so NAR suggests using a specialization of the "Contract" object to the form: «Regulation». Everything else that makes up the structure of the Authority's system must conform to the legislation. If it is not, this is an undesirable condition. The degree of compliance does not need to be expressed by additional concepts, within NAR it is sufficient to link model objects, typically agendas or services, by association with «Regulation» objects, see the following figure:

 Compliance Metamodel

The regulation objects can be freely specialized/aggregated, through sub-levels of the regulation: article, paragraph, paragraph, letter. Another specialization is the structure of regulations of lower legal force (implementing legislation, sub-legislation or secondary legislation), i.e. typically decrees and methodological guidelines. For these types of specialization of the content of the concept «regulations» it is undesirable to create further stereotypes in this version of the NAR.

Standardization architecture metamodel

There are two types of standards in the field of standardization:

  • Standard as document, which expresses the will of the signatories (the authors of the standard) to define and use certain "things" uniformly in the same way.
  • Standard as declared, which is created by declaring some existing thing (typically a product type, data format, etc.) from my own architecture model to be a standard.

In the metamodel of the standardization architecture, a single new element needs to be captured, namely an object representing an image of a standardization document, such as ISO 27000. For such objects, NAR also suggests specializing the ArchiMate language concept "contract" into the form «standard», see the following figure:

 Standardization Architecture Metamodel

Long-term sustainability architecture metamodel

The long-term sustainability architecture for the NA VS CR has no specific metamodel elements defined yet. We anticipate that future versions of the ArchiMate language will see a looser use of the Metrics (KPI) object than is currently the case as a measure of the outcome of a need assessment, a motivator, in the motivation architecture. We anticipate that Metrics will be a suitable concept for long-term sustainability architecture as well.

Other suitable attributes may be, for example, Architectural Principle, Architectural Requirement or Limiting Condition, or their specialized stereotypes.

=== Interpretation of the architecture metamodel of compliance, standardization and long-term sustainability ===.

No further interpretation is yet prepared in this domain.

The figure below shows the implementation and migration extension metamodel.

 Implementation extension metamodel according to ArchiMate 2.1 specification, source: (The Open Group, 2017), modified by MV

Definition of implementation architecture metamodel elements and migration

Table18)) with implementation and migration architecture metamodel definitions

Element type name Element type meaning definition NAR definition NAR definition
Work package A series of actions identified and designed to achieve specific results within specified time and resource constraints (ArchiMate).\ A set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program (TOGAF).
Implementation event A behavior element that denotes a state change related to implementation or migration.

The reason we mention these methods and notations here in NAR is not to try to formulate a national specification for them, but to point out that objects in ArchiMate must be modeled so that the capture of the existence of a thing (process, service, data element, etc.) in ArchiMate can be followed by its detailed model in another notation.

For example, when modeling the behavior of an office in the business layer, it is appropriate to declare as a process only those behaviors that meet the attributes of a process and can subsequently be modeled as a pool of the BPMN model. Conversely, anything for which a process, subprocess, or called activity will be modeled in BPMN should also have its corresponding image in the ArchiMate model.

Therefore, modelling for the digital transformation of public administration should be supported by an integrated common authority model at both NAP and PMA3 level.

For authorities that preferably use multiple modelling notations, NAR recommends that this is highlighted in the RFP documentation for the modelling tool to ensure not only a single modelling environment for these different notations, but also the ability to seamlessly transition (navigate and trace) between models in different notations, see example in the figure below.

 Relationship between the ArchiMate language and notations for detailed models, example. Source: Marc Lankhorst, [[https://bizzdesign.com/blog/combining-archimate-3-0-with-other-standards-introduction/|Blog]].

The relationship between these two notations makes the difference between EA-level bureau architecture fully apparent, asking in particular the question "What is and why?" and Solution Architecture (SA), asking the question "How does it work?", here at the business layer level.

The EA model in ArchiMate for the pizza ordering example captures only the basic roles of customer and supplier and the existence of all the key process necks and the rough links between them, as shown in the following diagram:

 Diagram of the pizza ordering process in ArchiMate, source: Marc Lankhorst, [[https://bizzdesign.com/blog/combining-archimate-3-0-with-other-standards-bpmn/|Blog]].

In contrast, the digram in BPMN notation in this example maintains the 1:1 process steps, but adds partial responsibilities (roles) and implementation details (interfaces, waiting, etc.):

 BPMN pizza ordering process, source Marc Lankhorst, [[https://bizzdesign.com/blog/combining-archimate-3-0-with-other-standards-bpmn/|Blog]].

In common practice, the BPMN model is even more detailed, i.e., for every single process in ArchiMate, one "pool" with many process roles and many steps is typically modeled in BPMN.


1)
Table - ArchiMate 3.1 element color definitions, source: MV by (The Open Group, 2017
2)
Table - Overview of ArchiMate 3.1 elements and their localization, source: MV according to (The Open Group, 2017
3)
Table - Overview of ArchiMate 3.0.1 binding types, source: MV by (The Open Group, 2017
4)
Table - Overview of application architecture metamodel element definitions, source: MV adapted from (The Open Group, 2017
5)
Table - Summary of definitions of physical architecture metamodel elements, source: MV by (The Open Group, 2017).
6)
Part of the business layer and the architecture development phase according to TOGAF ADM.
7)
According to the ArchiMate 3.0 specification, the strategic architecture was added to the earlier motivational extension as a new separate layer, presumably for backward compatibility of the language.
8)
Table - Summary of definitions of strategy and direction architecture metamodel elements, source: MV by (The Open Group, 2017
9)
Key Goal Indicator.
10)
Key Performance Indicator.
11)
Total Cost of Ownership
12)
From English Process Performance Indicator.
13)
Table - Summary of definitions of performance architecture metamodel elements.
14)
From Core.
15)
Table - Summary of translations of security architecture metamodel elements.
16)
Table - Summary of security architecture metamodel element definitions, MV according to (Band, et al., 2015
17)
From Corporate Social Responsibility: Wikipedia.
18)
Table - Implementation and migration architecture metamodel element definitions, source: MV adapted from (The Open Group, 2017
Enter your comment: