====== 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. ===== Modeling Objects - Architectural Metamodel ===== 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 [[nar_document:structure_modelled_architectures|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). ==== ArchiMate Language Basics ==== 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 {{ :nar-document:image16.png?600 | 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. ==== Rules for using the ArchiMate language for modelling NA VS CR ==== === 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 [[nar_document:structure_modelled_architectures|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 definitions((Table - ArchiMate 3.1 element color definitions, source: MV by (The Open Group, 2017)))** ^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 |255 |Technology |Green |175 |255 |175 | |Physical |Green |175 |255 |175 | |Implementation and\migration|Light 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 standard element localization and bindings ==== === 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 table((Table - Overview of ArchiMate 3.1 elements and their localization, source: MV according to (The Open Group, 2017))) is 100% taken from the original ArchiMate 3.1 specification. === Overview of ArchiMate bindings ==== The following table((Table - Overview of ArchiMate 3.0.1 binding types, source: MV by (The Open Group, 2017)) provides an overview and explanation of each binding:) ^**Concept** ^**Description** ^**Symbol** ^ |**Structural Bindings** ||| |Composition** (Composition) |Composition means that an element is composed of one or more other elements (without which it cannot exist and they cannot exist alone). Unlike aggregation, a composed element can only be part of one composition.\\\ Composition is always allowed between two elements of the same type and is the strongest binding.|{{{:nar-document:image17.png?97x15}}| |Aggregation\\ (Aggregation) |Aggregation relationship indicates that an element combines one or more other elements. Unlike a composition, an aggregated element can be part of multiple aggregations.\\\Aggregation is always allowed between two elements of the same type and is the second strongest binding. |{{{:nar-document:image18.png?97x16}}| |Assignment\\| An assignment expresses a situation of allocating responsibilities, performing behaviors, or executing actions. An assignment relationship links behavior elements to the active elements (e.g., roles, components) that perform them or roles to the participants that perform them. It is the third strongest link. |{{{:nar-document:image19.png?96x9}} | |Realization |Realization refers to a situation where an element creates another element. Typically, it is a binding between an element with a higher level of abstraction to a lower level of abstraction. |{{{:nar-document:image20.png?98x15}}| |**Dependency Bindings** ||| |Serving |Serving expresses a situation where an element provides its functionality to another element. It is the fifth strongest constraint. |{{{:nar-document:image21.png?97x14}}}| |Access |Access expresses a situation where a behavioral or active element acts over a passive element. It is the sixth strongest constraint. |{{{:nar-document:image22.png?98x15}}| |Influence |Influence refers to a situation where any element influences the implementation or achievement of a motivational element. |{{{:nar-document:image23.png?99x32}}| |**Dynamic bonds**||| |Flow |Flow describes the transfer of information from one element to another, the exchange or transfer of e.g. information or value between processes, functions, interactions and events. It is a special dynamic binding without further definition. |{{{:nar-document:image24.png?96x14}}| |Triggering |Triggering describes temporal or causal relationships between processes, functions, interactions, and events. Triggering describes temporary or intermittent relationships between elements. It is typically used in the representation of processes and their sequences. It is a special dynamic binding without further specification. |{{{:nar-document:image25.png?96x14}}| |**Other constraints** ||| |Specialization| |Specialization bindings indicate that an object is a specialization of another object. Specialization describes the inheritance between elements. Specialization is always allowed between elements of the same type. It is a special binding without further specification. |{{{:nar-document:image26.png?97x25}}| |Association/context |Association (context) is an unspecified element binding used where no other ArchiMate binding is appropriate. |{{{:nar-document:image27.png?97}} | |**Binding connectors** ||| |Junction ( (And) Junction) |Junction is used to join relationships of the same type. Logical AND. |{{{:nar-document:image28.png?12x12}}|| |branching (Or Junction) |A conjunction is used to branch relations of the same type. Logical OR. |{{{:nar-document:image29.png?12x12}}| When used in models and their diagrams, individual instances of these link types are (can be) given their own concise names, similar to the way concept instances (metamodel element types) are named. ===== The overall metamodel of the NA VS CR ===== Since metamodels and view definitions are the basis for model creation and interoperability, all definitions listed here are also available on OHA and its website as files in the open source Archi tool and The Open Group ArchiMate File Exchange Format. Updated metamodels will only be released as a result of the validation of the proposals below in Authority practice. ==== Maximum metamodel NA VS CR ==== The maximum metamodel of the Authority Architecture as part of the National Architecture is set as the full and unchanged scope of the ArchiMate 3.1 standard specification, or higher, for the first period of implementation. Since the ArchiMate and TOGAF metamodel are not yet 100% identical to each other((Although the two standards are still converging under the joint stewardship of The Open Group.)), NAR is taking some metamodel objects from TOGAF as well, namely the Organizational Unit, Logical and Physical Application Component, and Logical and Physical Technology Component objects. In addition, NAR introduces new concepts for objects typical for Czech public administration, namely Legal Code, Agenda and Information System (logical, ISVS). Thus, beyond the standard ArchiMate 3.1 specification, the following specialized concepts (metamodel objects), so-called <>, are introduced for the NA VS CR metamodel, affecting: - public administration needs, i.e. "legal regulation" as <>, <> and <>, - generally missing concepts of "organizational unit" as <> (according to TOGAF) and <>, for standardization <>, - the need to separately sanction and evaluate the elements of the communication infrastructure are optionally <>, <>, etc. (from the four-layer vision), - the need to distinguish between <> and <> (from TOGAF). It is not mandatory to specialize elements from the added Communication and Physical Infrastructure layer, but it is permissible. Only practical experience will show whether it is not advantageous to disable some objects of the metamodel completely for simplicity and add others as specializations of the original ones. ==== Basic metamodel ==== The recommended first reduced (basic) metamodel is presented in summary in the diagram below (selected elements) and at the same time in parts for each domain metamodel (completely). {{ :nar-document:image30.png?600 | Basic reduced metamodel of NA VC CR in ArchiMate notation.}} In individual typified (and regulated by legislation or methodological regulation) architectural engagements, such as just the familiarization of OHA with the planned IT project (the so-called application), a further reduced metamodel will be recommended for simplification by a separate methodological procedure. The recommended reduced (simplified) metamodels for each architecture layer are presented in the following sections. {{ :nar-document:image31.png?600 | Basic (reduced) selection of NA metamodel elements from the ArchiMate 3.1 standard (without specialized stereotypes).}} ==== Simplified metamodel of basic recommended elements ==== The overall, already reduced base (let alone maximum) metamodel defining the NA architecture still contains a significant number of constraints and extension areas. For clarity and better understanding, the **simplified metamodel of the basic recommended elements is shown schematically in the Figure below.** Only the most essential objects and constraints from the non-expanded ArchiMate standard have been selected from the full metamodel. {{ :nar-document:image32.png?600 | Simplified metamodel of basic recommended elements}} ==== Principles and examples of local metamodel extensions ==== Each of the future so-called Obligated Organizations (OOs) will likely be able to model the architecture of the office beyond the mandatory scope defined by this methodology and maintained in a central architecture repository. However, only models of a precisely defined scope will be taken into the repository after checking. For its internal purposes, the OVS may extend the architecture metamodel, both in ArchiMate notation by specialising objects, creating new so-called stereotypes, and by linking objects to detailed models in other notations, such as UML, BPMN, DMN or Citizen Journey Map((Analytical technique in the field of marketing and customer care, literally the Client Journey (through the office). )). For an example of the extension of specializations, see [[nar_document:ramec_content_and_output_architectures|Content and Output Architectures Framework]] for a set of specialized concepts derived by one of the authorities from the concept of an application component. ==== Mandatory Scope Models ==== The mandatory scope of models at the level of the NSA National Architecture **is not set in aggregate by this methodology**, but is determined by the types of architectural engagements. These will be matched by sub-methodological guidelines and extension methodologies such as "How to do it?". For example, the tables and explanations in the OHA ICT Project Opinion Request Form and Methodology Guidance clearly state which model objects must be included. ===== Subdomain Metamodels ===== ==== Business Architecture (BA) Metamodel ==== This section defines the organizational architecture metamodel in both full and reduced versions and in a minimal version. {{ :nar-document:image33.png?600 | Full business layer metamodel according to ArchiMate 3.1 specification (in the context of other layers), source: (The Open Group, 2017), translation by MV.}} The BA metamodel as shown includes metamodel concepts belonging to other domains according to NAR or ArchiMate, as they are an important part of the overall view of government service performance (i.e., Business). The concepts meant are: * from the Strategic Domain: Authority Capability, Public Service Delivery Scenario, and Location. * from the Motivational Domain: VS Product/Service Value and VS Object Relevance * from the Compliance Domain: Regulation. In addition to the localized designations for VS CR, for example "Participant of interaction with VS", the original designation, here "actor", can always be used for simplicity in the professional community. Some of the mentioned business-relevant concepts have been moved to other domains in ArchiMate version 3.1, so they have different colors, but they are still listed here. {{ :nar-document:image34.png?600 | selection from the ArchiMate 3.1 business layer specification, source: (The Open Group, 2017), modified by MV.}} {{ :nar-document:image35.png?600 | Minimal selection from the business architecture metamodel according to ArchiMate 3.1, source: (The Open Group, 2017), translation by MV.}} === Definition of business architecture metamodel elements === Table((Table - Summary of business architecture metamodel element definitions, source: MV based on (The Open Group, 2017))) with definitions of business architecture metamodel elements ^**Element Type Name** ^**Element Type Meaning Definition** ^**NAR Definition** ^ |**Business interface** |A point of access where a business service is made available to the environment. |A point of access to public administration services, also a contact point or service channel (counters, CzechPOINT, Citizen Portal, etc.) | |**Participant/actor** |A business actor is a business entity that is capable of performing behaviour (ArchiMate).\\\ A person, organization, or system that has one or more roles that initiates or interacts with activities; for example, a sales representative who travels to visit customers. Actors may be internal or external to an organization (TOGAF). |A person, organization, or system that acts in one or more roles as a participant in activities (business functions, processes, or services). |**Role** |The responsibility for performing specific behaviour, to which an actor can be assigned, or the part an actor plays in a particular action or event. (ArchiMate).\\\The usual or expected function of an actor, or the part somebody or something plays in a particular action or event. An actor may have a number of roles (TOGAF). |Role represents the attitude, or behaviour, of a particular person or group of persons in relation to the performance of public services. Each real person (actor) acts in, is active in, one or more roles, takes on a role for a given event. | |**Collaboration (business)** |An aggregate of two or more business internal active structure elements that work together to perform collective behavior. |**A group of at least two actors or roles that must work together to perform a particular collective behavior. |**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.. |The function delivers business capabilities. A function is closely aligned to an organisation (its structure), but not necessarily governed/managed by that part of the organisation. |**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). |A process represents a specific way of managing functions in their precise order.\\\ A process is therefore made up of functions, and at the same time a function (at another level of detail) is made up of processes.\\ \\ A typical output of a process, called a process interface, is a service. |**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. |A state change that is significant from a process perspective may originate from outside or inside the organization and may be processed outside or inside 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. |**A service is a specific way of managing the performance of functions and processes.\\ \\ It supports business capabilities through an explicitly defined interface and is explicitly formally governed by an organization (ie. has a SLA contract). |**Business Object /**\\\\ **Law Object**|A concept used within a particular business domain. |**Business Object is anything that exists objectively (tangibly or intangibly) in the business domain, is subject to modelling and does not fit any specific BA concept. |**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). |A contract is any formal or informal agreement between a service provider and a recipient of a service, or the entire product.\\\ Public administration products are mainly regulated by laws, so a specialized type of element of legislation, <>, derived from a contract, has been introduced.\\ Service Level Agreements (SLAs) will be used to manage internal and external services.\\\ |**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. |The product is a composition of business outputs, typically services and goods, supplemented by other components - rules, contracts and conditions, data, media, etc.\\ \\ The trend in VS will be to transform the duties of public servants into services or even products of public administration, completely addressing the client's life situation. |**<<<>** |It does not have, see business function |Comprehensive area of competence of a public authority or a comprehensive area of activity of a private data user.\\\ \\ It is uniquely registered in the RPP.\\ \\ It corresponds to the broadly conceived business function, but for its unique position in the VS of the Czech Republic it will be modeled as a specialized stereotype. |**<<>** |It does not have, see business function |A partial part of the agenda, again corresponds to the business function, alternatively also for it is designed a specialized stereotype.\\\\ It is registered in the RPP. |**<>** |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). |TOGAF, unlike ArchiMate, also contains a separate element type for actor in the form of a person. |**<<<>** |None, see actor. |Separately non-existent sub-organisational unit of the office (section, department, division, group, team, etc.). === 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 <>. 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. ==== IS Architecture Metamodel - Information (Data) Architecture (DA) ==== 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-document:image36.png?200 | 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. ==== IS-Application Architecture (AA) Metamodel ==== 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. {{ :nar-document:image37.png?600 | 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: {{ :nar-document:image38.png?600 | selection from the ArchiMate 3.1 IS layer specification, source: (The Open Group, 2017), modified by MV}} === Definition of application architecture metamodel elements === Table((Table - Overview of application architecture metamodel element definitions, source: MV adapted from (The Open Group, 2017))) 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 interface is where application services are made available to a user, other applications, or technology nodes. |**Application collaboration** |An aggregate of two or more application components that work together to perform collective application behavior. |**An aggregate of two or more application components that work together to provide collective application behavior. |**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). |An application service is an application behaviour (function or interaction) that is made available to users and is explicitly managed as a service.\\ Application services are part of digital government services, they implement them. |**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. |**An application behavior element that denotes a state change. |**Data object** |Data structured for automated processing. | | | |**<>**| | | === Interpreting the application architecture metamodel === **Active elements of AA Authority** The basic active element of the application architecture of information systems is the application component. At least one actual installable application component is part of the Information System. An application component contains application functions (functional specifications, FS, n-FS) and application interfaces (GUI and API). If an application component has functions and delivers a service only in conjunction with another component, then these components form a so-called application collaboration. The application interface is assigned to the application service, or the service is available on the interface. An application interface serves a) another application component (service, function) or b) serves an actor in its role, whose business interface is implemented. **Behavioral Elements of AA Authority** The (internal) application functions are the basis for the behaviour of application components, their interfaces and interactions. An application component has an arbitrary granularity (hierarchy) of functions. The collective internal application collaboration functions are called application interactions. The nature of an application interaction is that of a service that incorporates functions from multiple application components under a single common control - it cannot be provided if any of the components are down or unavailable. Application functions, interactions and sub-processes can be implemented and managed as automated application processes and workflows. Application event and application process element types can be used to model them. The external behavioural manifestation and result of application functions, interactions or processes are application services for other applications, but especially for business layer behavioural elements. **Passive elements of AA Authority** The passive element of the application architecture and at the same time the logical element of the information systems data architecture is the data object, which represents in the model the realization of the information (data) image of the business object or any other element of the architecture. **Composite elements of BA Office** The application architecture does not have a specific composite element, but uses the Grouping element to categorize and group occurrences of other elements. === Specialization of application architecture concepts === The NAR methodology further assumes that some offices will want/need to refine the meaning of some concepts, elements of the metamodel, so called specialization, and thus in turn expand the scope of the metamodel for their own use. Such an example is the practice of one ministry that has specialized the application component element into four categories, two of which represent virtual aggregation levels above the original meaning of the application component (Information System and IS component) and one, on the contrary, a smaller logical unit of the application component (the so-called application module). From this experience, it is proposed to include the Information System (logical) stereotype in the NAR standard, while the other component types are not yet adopted in the standard. Another example from the same source is the division of the application interface into multiple specialized interfaces. In future staging of authority models into a central repository using The Open Group ArchiMate File Exchange Format, which naturally does not recognize these specializations, these will be replaced back by the Application Component element. It is an open methodological question, which will only be resolved in practice when the central repository is implemented, whether this will be permissible in a binding methodology or whether the export model will have to be filtered so that only elements of uniform meaning and granularity are transferred, in this case the so-called "Application", meaning the existing application component. For this reason, we recommend considerable restraint when specializing elements and extending the Authority's metamodel. {{ :nar-document:image39.png?600 | Example of application architecture metamodel extension, source MV according to the Ministry of Agriculture of the Czech Republic}} In doing so, we need to emphasize the difference between using composite and aggregation links between specialized components. If the specialized components are images of physical instances (solution building blocks - SBB), then the composite binding is applied between them, because, for example, one physical module can be part of only one application and component, only one IS. In the case where they represent logical elements of the architecture (architectural building blocks - ABBs), then both composite and aggregation binding may apply between them, because one exemplar element may be used in multiple occurrences, in multiple parent elements. It is also noteworthy that, according to the ArchiMate standard, <> is de facto/practically more of an Application Collaboration (colaboration), because if the applications of the system do not collaborate, it is unlikely to fulfill its/its purpose. It should also be emphasized that neither TOGAF nor ArchiMate recognize the term Application as a noun in the sense of an active element (subject), but only as an adjective, e.g. Application Service or as a verb noun (applying - something somewhere). If this "Application" is independently installable and manageable (from deployable )), then according to ArchiMate it is an application component. If it is not standalone, then it is an application function, of any level of detail. If an authority wishes to express an <>, but it is not capable of a separate operational existence, then it should use an application function, not an application component, as the starting point for its specialization. While application functions may have an arbitrarily deep (detailed) hierarchy within a single component, application components may not be chained in this way, at least not in the physical component model. In fact, there is one and only one level of installable and operable components, everything above this level is either Collaboration (if the components must work together) or Clustering (if they belong together, for example, together they form one ISVS. Everything below the installable level is an application function. A hierarchy of application components can only be modeled where each thing labeled as a component actually satisfies all the properties of the component. According to NAR, it is not permissible to model SW license objects together with real components. This issue will only be definitively resolved as the next phase of ISoISVS development in the RPP decides to record and uniquely label the existence of ISVS subcomponents (application components and functions). ==== ICT Technology Architecture (TA) Metamodel ==== This section defines the full and simplified technology architecture metamodel. {{ :nar-document:image40.png?600 | Full Technology Architecture Metamodel}} {{ :nar-document:image41.png?600 | reduced selection from ArchiMate 2.1 technology layer specification, source: (The Open Group, 2017), modified by MV}} === Definition of technology architecture metamodel elements === Table((Table - Summary of definitions of technology architecture metamodel elements, source: MV adapted from (The Open Group, 2017))) with definitions of technology architecture metamodel elements ^**Element type name** ^**Element type meaning definition** ^**NAR definition** ^ |**Node** |A computational or physical resource that hosts, manipulates, or interacts with other computational or physical resources. |**A computational technology node is a computational or physical resource that hosts, manipulates, or interacts with other computational or physical resources. |**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. |**Software that provides or contributes to an environment for storing, executing, and using software or data deployed within it. | |**Technology Collaboration**|An aggregate of two or more nodes that work together to perform collective technology behavior. |**An aggregate of two or more nodes that work together to perform collective technology behavior. |**Technology interface** |A point of access where technology services offered by a node can be accessed. |**A point of access where technology services offered by a node can be accessed. | |**Path** |A link between two or more nodes, through which these nodes can exchange data or material. | |**Technology Service** |An explicitly defined exposed technology behavior (ArchiMate).\\ \\ A technical capability required to provide enabling infrastructure that supports the delivery of applications (TOGAF). |Explicitly defined exposed technology behavior (ArchiMate).\\ \\ A technical capability required to provide enabling infrastructure that supports the delivery of applications (TOGAF).| |**Technology Function** |A collection of technology behavior that can be performed by a node. |**A collection of technology behavior that can be performed by a node. |**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** |A sequence of technology behaviors that achieves a specific outcome. |**Technology Interaction** |A unit of collective technology behaviour performed by (a collaboration of) two or more nodes. |**A unit of collective technology behaviour performed by a collaboration of two or more nodes. |**Technology event** |A technology behavior element that denotes a state change. |**Technology behavior element that denotes a state change. |**Artefact** |A piece of data that is used or produced in a software development process, or by deployment and operation of a system. | |**Technology component**|An 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. ==== Communications and Physical Infrastructure (CI) Metamodel ==== 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. {{ :nar-document:image42.png?600 | Physical Infrastructure Metamodel.}} === Definition of the elements of the physical architecture metamodel === The table((Table - Summary of definitions of physical architecture metamodel elements, source: MV by (The Open Group, 2017).)) 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. {{ :nar-document:image43.png?600 | 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. ==== Strategy and Direction Architecture Metamodel (MA) ==== 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 TOGAF((Part of the business layer and the architecture development phase according to TOGAF ADM. )) and the so-called motivational and strategic((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. )) 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. {{ :nar-document:image44.png?600 | Full metamodel of the Strategic Motivation Architecture.}} {{ :nar-document:image45.png?600 | 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 ===. Table((Table - Summary of definitions of strategy and direction architecture metamodel elements, source: MV by (The Open Group, 2017))) 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. |An end result to be achieved to meet a strategic objective. |**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). |A statement of need that must be fulfilled by the target architecture. |**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. | |**<>****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). |**An approach or plan (initiative) for improving selected capabilities and resources of the organization to achieve a strategic goal. |**Ability ** |An ability that an active structure element, such as an organization, person, or system, possesses (ArchiMate). A business-focused outcome that is delivered by the completion of one or more work packages. (TOGAF).|The ability of an organization or its parts to produce valuable outputs. |**An asset owned or controlled by an individual or organization. |**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). |Representation of a complex 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 [[nar_document:modeling_offices_and_their_architectures|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. ==== Performance Architecture (PA) Metamodel ==== 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 (KGI((Key Goal Indicator. )), KPI((Key Performance Indicator. )) (especially TCO((Total Cost of Ownership ))), PPI((From English Process Performance Indicator. ))), 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: {{ :nar-document:image46.png?600 | 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 === Table((Table - Summary of definitions of performance architecture metamodel elements.)) with definitions of performance architecture metamodel elements ^**Element type name** ^**Element type definition** ^**NAR definition** ^ |**<>** (Measure) |An indicator or factor that can be tracked, usually on an ongoing basis, to determine success or alignment with objectives and goals (TOGAF only). |**<<>**\\\\ (Service Quality)|A preset configuration of non-functional attributes that may be assigned to a service or service contract (TOGAF only). |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 ** | |Not included in ArchiMate === 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". ==== Security Architecture (SA) Metamodel ==== 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 {{ :nar-document:image47.png?600 | 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: {{ :nar-document:image48.png?600 | 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 Core((From Core. )) 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 === Table((Table - Summary of translations of security architecture metamodel elements.)) with definitions of security architecture metamodel elements ^**Original name** ^**Generic translation** ^ |Threat |**Threat/threat** | |Threat agent / actor|**Threat agent / actor**| |Threat event |**Threat event** | |Loss event |**Loss event** | |Risk/security driver|**Security 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 === Table((Table - Summary of security architecture metamodel element definitions, MV according to (Band, et al., 2015))) 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** |A chance of something bad happening combined with how bad it would be if it happened. A Risk is a negative scenario you want to avoid, essentially the combination of its Probability and Impact.\** Risk is also modelled with the assessment construct and considered as a specialization of it. |The probability of something undesirable happening. Risk is a negative scenario that an organization wants to avoid. It is a combination of its likelihood and its impact.\\\ Risk is modelled by the type of assessment construct and considered as a specialisation of it. | |**Vulnerability** |Vulnerabilities are simply weaknesses in the system, vulnerabilities are what make Threats possible and/or more significant.\\\ Vulnerability is modeled as a specialization of an assessment in the ArchiMate language, because considered as the result of analyzing the weaknesses of elements in the architecture. |Vulnerabilities represent weaknesses in the system, they are what make threats possible or more significant.\\ Vulnerability is modeled using a specialization of the Impact Assessment element type, because it is also considered as the result of analyzing the weaknesses of the elements in the architecture. |**Control objective** |Risk control objective and security control objective are specialization of the objective construct and aim at mitigating risks. They are designed from risks and risk/security drivers and further refined through security requirement and principle. |Risk and security control objectives are a specialization of the objective element type and aim at mitigating risks. They are refined through specialized element types security principle and security requirement. | |**Security principle** |Security principle is considered here as a synonym of security policy and is modeled with the principle construct. |**Security principle is considered here as a synonym of security policy and is modeled with the principle element type. |**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. ==== Standardization, Compliance and Sustainability Architecture Metamodel ==== 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 CSR((From Corporate Social Responsibility: [[https://cs.wikipedia.org/wiki/Společenská_odpovědnost_firem|Wikipedia]].)). === 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: <>. 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 <> objects, see the following figure: {{ :nar-document:image49.png?150 | 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 <> 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 <>, see the following figure: {{ :nar-document:image50.png?150 | 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. ==== Implementation and Migration Architecture Metamodel ==== The figure below shows the implementation and migration extension metamodel. {{ :nar-document:image51.png?600 | 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 === Table((Table - Implementation and migration architecture metamodel element definitions, source: MV adapted from (The Open Group, 2017))) 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).|A series of actions identified and designed to achieve specific results to meet one or more objectives for the business, within specified time and resource constraints A work package can be a part of a project, a complete project, or a program. |**A precisely-defined outcome of a work package. |**A precisely (formally, contractually) defined outcome of a work package. |**Implementation event ** |A behavior element that denotes a state change related to implementation or migration. |**A behavior element that denotes a state change related to implementation or migration. |**State of the architecture** |A relatively stable state of the architecture that exists during a limited period of time. A relatively stable state of the architecture that exists for a limited period of time.\\ Transition (Plateau) state of the architecture is a state in which planned architectural changes have been completed and the architecture is once again delivering business value.| |**Difference/deficiency** |A statement of difference between two plateaus (ArchiMate).\\\ \\ A statement of difference between two states. Used in the context of gap analysis, where the difference between the Baseline and Target Architecture is identified (TOGAF). |A statement of difference between the current and target (or transition) architecture. === Interpreting the Implementation and Migration Architecture metamodel === As in the base (core) layers of the Authority architecture, objects in the Implementation and Migration (IM) architecture can be distinguished according to the different aspects of the ArchiMate language, with the exception of the active elements. **Active elements of IM Authority** The IM architecture does not have its own specific active elements, these are the business architecture elements. **Behavioral Elements of IM Authority** The core element of the Implementation and Migration architecture metamodel is the Work Package. It is classified as an active element and represents an arbitrarily large portion of the activities that implement the change from the current to the target architecture. A work package is most often a project, but downstream it can be a phase of a project, a sub-project, a sub-stream of a project, or just a single activity. In the upstream direction, projects are typically grouped for coordinated delivery of benefit value to sub-programmes and programmes An implementation event represents a milestone in a project-oriented implementation effort. It may be tied to another event in the Authority's system model. **Office IM Passive Elements** The basic passive element is the output of the project effort, i.e., the so-called deliverable. Each deliverable is the partial or total fulfillment of one or more identified and planned gaps between the current and target state of some underlying element (gap), which represents the second passive element of the metamodel. **Composite elements of the IM Office** The composite element of this layer that encapsulates a number of others is the so-called architecture state (plateau). In the TOGAF methodology, this is the so-called target or transitional architecture, i.e. the combination of elements and links of the system architecture that is functional and in its state delivers some intended business value to the authority. If a project ends up unfinished, it is in no way a transitional architecture. A transitional architecture is a managed state, fully functional and satisfactory even if no further change is made. ==== Metamodel Composite Objects ==== === Definition of composite metamodel architecture elements === Table((Table - Definitions of composite metamodel architecture elements, source: MV by (The Open Group, 2017).)) with definitions of composite metamodel architecture elements ^**Element type name**^**Element type definition** ^**NAR definition** ^ |**Grouping** |The grouping element aggregates or composes concepts that belong together based on some common characteristic.| |**Location/Location** |A location is a place or position where structure elements can be located or behavior can be performed. | === Interpretation of composite metamodel elements === The basic use of "Grouping" is to express levels of generalization of some elements, their types, classification classes, for which the assumptions of the element type definition are no longer met. For example, the Front-Office, Middle-Office and Back-Office categories are extremely important for the process and application decomposition (Map) of an office, but they are neither a process nor an application component, hence they are a Grouping - more e.g. in [[nar_document:reference_models_and_classification_frameworks|Reference Models and Classification Frameworks]]. "Location/Location" primarily represents the location of the element in space, i.e. with reference to a geographic navigation (address point) or possibly to navigation within a future. Location is naturally (and unrestrictedly) hierarchical, from planet level to the smallest detail (continent, country, region/county, municipality, street, house, etc.) as appropriate. For the placement of elements (such as data centres or contact points), a location in line with the address point (verifiable in RUIAN) will be required in single specific, centrally coordinated engagements. ==== General metamodel objects outside of ArchiMate layers ==== This section lists elements that are not covered by the ArchiMate modeling language standard, yet are important from the perspective of the TOGAF standard or future NAR development. === Definition of generic architecture metamodel elements === Table with definitions of generic architecture metamodel elements. ^**Element type name** ^**Element type definition** ^**NAR definitions** ^**NAR definitions** ^ |**Service****(Service)** |An element of behavior that provides specific functionality in response to requests from actors or other services. A service delivers or supports business capabilities, has an explicitly defined interface, and is explicitly governed. Services are defined for business, information systems, and platforms (TOGAF).\\\An element of behavior that provides specific functionality in response to requests from actors or other services.\\\A service delivers or supports business capabilities, has an explicitly defined interface, and is explicitly governed. Services are defined for business, information systems and platforms.| |**Data entity**\\\\ **(Data entity)**|An encapsulation of data that is recognized by a business domain expert as a thing. Logical data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations (TOGAF only). ||An encapsulation of data about something that is recognized as a thing by a business domain expert.\\\ Logical data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations. |**Assumption** **(Assumption)** |A statement of probable fact that has not been fully validated at this stage, due to external constraints. For example, it may be assumed that an existing application will support a certain set of functional requirements, although those requirements may not yet have been individually validated (TOGAF only). |A statement of probable fact that has not been fully validated at this stage, due to external constraints. For example, an existing application may be expected to support a certain set of functional requirements, even though these requirements have not yet been individually validated. | Similar to a service, the concepts of function, process, event, component - all occurring in multiple layers of either TOGAF, ArchiMate or both - could be defined together. It is important to perceive their general nature and meaning regardless of layers and architectures, as well as their specific use within an architecture layer. It is necessary to add to the definition of a service that any service of any layer is always formally provided by a responsible natural or legal person, or part thereof, who is authorized to provide the service, empowered by law or contract or internal regulation. This also applies to IS and technology services. For a good understanding of what a service actually is, a definition of a general service, adapted to the concepts of public administration, is added, more so in the NAP: A service is a function of an authority if it is provided by a specific provider to a specific recipient of the service according to a predefined formal agreement (law, decree, service level agreement - SLA) in such a way that it delivers a perceived value to the recipient for which the recipient would be willing to pay a reasonable price (or pay taxes). A service is always intended for a specific client, it is the result of a function or process. A public administration service is always linked to a specific right or obligation of the client towards the public administration and consists in the exercise of the functions of an authority and an official leading to the enabling and facilitating of the achievement of that right or the fulfilment of that obligation by the client. ==== Types of links between objects of the metamodel ==== The types of links in the NA VS CR fully conform to the current ArchiMate language standard, see [[nar_document:ramec_content_and_output_architectures|Architecture Content and Output Framework]]. === Recommended examples of bindings === The National Architecture Framework allows the use of all the bindings described in this section, but recommends the following bindings for simplicity: * Composition * Aggregation * Assignment * Realization * Serves * Access * Influence * Association {{ :nar-document:image52.png?600 | Recommended examples of relationships between model objects in ArchiMate.}} == Composition == Composition can be expressed both outside the composed element and by nesting((Nested diagram )). It is always possible to compose elements of the same type, as well as other elements, typically an interface with active elements, or a device and a node, because they are subclasses. A composite element can only be part of one composition. {{ :nar-document:image53.png?600 | Examples of composite links.}} == Aggregation == Aggregation, like composition, can be expressed outside of the aggregated element by embedding. Elements of the same type can always be aggregated, and so can others. The principle is similar to composition, except that the aggregated element can be part of multiple aggregations. {{ :nar-document:image54.png?600 | Examples of aggregation links.}} Although the ArchiMate language theoretically allows aggregation for any type of element, from a TOGAF point of view this doesn't make sense for some, especially for applications (so here it's wrong). The point is that an application component according to TOGAF is independently implementable((literally "deployable" )) unit of application software, we say that it can be turned on/off. If the component would contain a component again, then it is not fulfilled, physically it cannot. This is why component aggregation is not recommended by NAR. == Assignment == Assignment, like aggregation and composition, can be expressed outside of the assigned element by embedding. An assignment is always a binding between behavioral elements and active elements, with the exception of actors and roles. {{ :nar-document:image55.png?600 | Assignment binding examples.}} == Implementation == An implementation can also be nested, but due to the expression of providing or creating another element, it is preferable to always have it as separate. Binding is most often used when creating services (external behavior) from functions (internal behavior). {{ :nar-document:image56.png?600 | Examples of binding implementation.}} == Serves/Services == The serves / handles binding is not nestable and is primarily used for transitions between layers, but also for example between components or services on the same layer. {{ :nar-document:image57.png?600 | Examples of serve/serve binding.}} == Access == Access is not nestable and is used to relate behavioral elements to passive elements (access, read, write, etc.). {{ :nar-document:image58.png?600 | Access binding example.}} == Influence == Influence is always between a motivation element and another element. As a single binding, it contains a measure of its own strength (positive or negative) and cannot be nested. {{ :nar-document:image59.png?600 | Example of an influence binding.}} == Association == An association/context is an indeterminate binding that can be used between all elements if no other binding fits. {{ :nar-document:image60.png?600 | Example of association/context binding.}} === Unrecommended examples of bindings === == Aggregation and composition binding == Beware of composition and aggregation binding for things that are not virtual, abstract concepts, but actually exist, have their registration and serial numbers. {{ :nar-document:image61.png?600 | Example of problematic binding of application components.}} An example is the inappropriate use of aggregate or composite binding for application components. For these, the definition, especially according to TOGAF, assumes that the component exists, can be installed, enabled/disabled. However, such components cannot be nested as cubes, only one of them can exist in this way, otherwise the definition condition would not be satisfied. The abstract logical, parent component should already be a Category (Grouping) or Collaboration. The lower element, the content of the component is its function, it represents what the component can do. In the figure, both the expression using two "boxes" and a binding is problematic, as is the left expression via a nest diagram (with unknown binding type, or regardless of binding type). ==== Attributes of metamodel elements ==== For each occurrence of a metamodel element captured in the authority architecture model, sets or also profiles of properties, called attributes, will be recorded. Some of the attributes will be so-called **management attributes**, i.e. they will be used to control and govern the creation, management and use of the models. Examples of governing attributes are the classification of models, views and elements, see Annex 1 - List of attributes of metamodel elements and Annex 2 - Classification of sets, models and views. All other attributes will be so called **real attributes**, i.e. they will be used to support the use of real authority architecture models in practice, in particular for decision making and improvement. For example, to manage the entire application portfolio of an authority. Thanks to the attributes of the elements, the model then becomes a carrier of inventory catalogues of these elements, more in the Methods of ICT Management of the Czech Republic. Many of the attributes listed in the NAR come from the annexes of the TOGAF standard, others from the practice of VS architecture pilot projects preceding the NAR release. Unfortunately, there were not enough pilot projects working with attributes before the first version of the NAR was published, there is nothing to generalize to best practice - therefore, attributes for each type of metamodel element will be published in successive editions of the NAR. Some of the model object attributes defined in the NAR will be **mandatory** for authority architecture models, others defined here are **optionally recommended**, and other attributes will be available for authorities to add as needed in their local adaptation of the authority architecture framework. All identified instances of Authority Architecture objects and their attributes shall be captured primarily in the form of an element catalogue. Therefore, attribute sets will be presented sequentially for each catalogue and collectively in a separate Annex 1 - List of Metamodel Element Attributes. All metamodel element types have an identical, common basic set of attributes: ^**Attribute type name** ^**Attribute type meaning definition** ^ |**Set: Stereotype** | | |Stereotype | | | |**Set: Element Identification** | | | |Local ID of the element in the model | | |Global element ID in the model | | |Local element ID in the OVS primary record |Example inventory number in EkIS | |Global element ID in the primary record of the state|If it exists at the central level of the Czech Republic (EU), for example a number from the basic registers from ISoISVS, etc.| |**Set: General description** | | |Abbreviation (code) of the element | | |Element name | | | |Description of element | | | | |Element Owner | |State of the element in the model | |**Set: Element classification** | | | | |See other sections and separate Annex 2. | | | |**Set: Standardization of the element** | | |Standard |Yes/No | |Standard declaration date | | | |Date of last review of the standard | | |Date of planned review of the standard | | |Date of abandonment of the standard | | |Standard Owner | | | |**Set: element life cycle** | | | In development/preparation | | | | |Transitional Architecture | | |Date from | | |Status |Yes/No | |In use | | |After use (off-road) | | |Outdated | | | | | Working with attributes in individual architectural modeling tools, transferring them in the standard TOGAMEFF format ((From The Open Group ArchiMate Model Exchange File Format. )) and their use in the central repository must be verified in practice. The results will be reflected in the modification of the prescribed element sets and rules for working with them in future NAR releases. ===== Architectural Creations and Deliverables ===== ==== Models, documents and artefacts (creations) ==== "Deliverables" or deliverables are created during the architecture creation process (TOGAF ADM). These deliverables are characterised by being explicitly (contractually) specified and then formally revised, agreed and signed off by the responsible approver. Deliverables represent the output products of a given architectural project and are expected to be archived and/or transferred to an architectural repository upon completion of the project as reference models or as records of a given architectural state over a period of time. Each deliverable contains at least one artefact, but realistically several. By **Artefact, i.e. architect's creation** we generally mean the product of architectural work focused on one aspect of architecture. The TOGAF framework recognises three main **classes** of **artefacts**, which are: * **Catalogues** - are one-dimensional lists of identified architectural elements and possible future building blocks. * **Matrices** - represent two-dimensional tables of dependencies between at least two types of architecture elements. * **Diagrams** - display the elements of the architecture and their relationships in a graphical manner that facilitates effective communication to stakeholders. The above artifact classes describe the so-called building blocks. Building blocks represent (potentially reusable) business elements, IT elements and certain capabilities. They can be combined with other building blocks to deliver the desired architectural solution. Building blocks can be defined at different levels of detail. This modelling methodology describes how the diagrams will be created, see the following Figure. {{ :nar-document:image62.png?600 |Explanation of the terms Deliverable Architecture, Artifacts and Building Blocks, source: TOGAF (The Open Group, 2018), translation by MV.}} ==== Overview of Typical Deliverables ==== During the ADM architecture creation cycle, in its different iterations according to the type of engagement, see for example [[nar_document:architecture_creation process|Architecture creation process]], a number of formalized deliverables are created and further used. The following deliverables have been selected from the TOGAF standard for NAR. === Overview of architecture deliverables and their localization === The first table((Table - Overview of architecture deliverables and their localization, source: (The Open Group, 2018) and MV.)) presents their original name, generic translation and NAR-specific name: ^ ^**Original name** ^**Generic translation** ^**Adaptation for NAR** ^ |TOGAF |Architecture Building Blocks |Architecture Building Blocks | | |:::: |Architecture Contract |::: |Architecture Contract |:::: |Architecture Contract |:::::. |:::: |Architecture Definition Document |Architecture Definition Document |Authority Architecture Model| |::: |Architecture Repositories |Architecture Repositories |::: |Architecture Repositories |::: |Architecture Repositories |::: |Architecture Repositories | |:::: |Architecture Requirements Specification |Architecture Requirements Specification| | |:::: |Architecture Vision |Architecture Vision |::::. |::: |Business Principles, Business Goals and Business Drivers|Business Motivators, Goals and Principles |::. |::: |Capability Assessment |Capability Assessment | |::: |Change Request |Change Request | | |:::: |Communications Plan |Communications Plan | | |:::: |Compliance Assessment |Compliance Assessment | |:::: |Implementation and Migration Plan | |::: |Implementation and Migration Plan |::. | |::: |Implementation Governance Model |Implementation Oversight Model | |::. | |:::: |Organizational Model for Enterprise Architecture |Organizational Model for EA | | | |:::: |Request for Architecture Work |Request for Architecture Work | |:::. |::: |Requirements Impact Assessment |::: |Requirements Impact Assessment |::: |Requirements Impact Assessment |::: |Requirements Impact Assessment |::: |Requirements Impact Assessment |::: |Requirements Impact Assessment |:::: |Statement of Architecture Work |Statement of Architecture Work | | | | |:::: |Tailored Architecture Framework | | | | | | | OVS Information Concept | | | | | Request for OHA Opinion | | | | | | The NAR is gradually adding to the selected outputs according to TOGAF the outputs used in the practice of the Czech public administration and delivered in relation to architecture. === Definition of architecture deliverables ==== The second table((Table - definition of architecture deliverables according to TOGAF 9.2, source: (The Open Group, 2018)) provides an explanation of the meaning and role of documents: ^**Output Type Name** ^**Output Type Definition** ^**Importance to NAR** ^. |A constituent of the architecture model that describes a single aspect of the overall model. |A constituent of the architecture model that describes a single aspect of the overall model. |Architecture Contracts |Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. \\ Successful implementation of these agreements will be delivered through effective Architecture Governance. |Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. |The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, transition, and target). |The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information. The architecture definition document includes all domains of the architecture (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, transition, and target). | |\\\\Architecture Principles |Set of generic Architecture Principles, including:\\\ ■ Business principles\\\\ ■ Data principles\\\\ ■ Application principles\\\\ ■ Technology principles |Set of generic Architecture Principles, including:\\\ ■ Business principles,\\\\\ ■ Data principles,\\\\\ ■ Application principles,\\\\ ■ Technology principles. |Architecture Repository |The Architecture Repository acts as a holding area for all architecture-related projects within the enterprise. The repository allows projects to manage their deliverables, locate re-usable assets, and publish outputs to stakeholders and other interested parties. |The Architecture Repository acts as a holding area for all architecture-related projects within the enterprise. The repository allows projects to manage their deliverables, locate reusable assets, and publish outputs to stakeholders and other interested parties. | |The Architecture Requirements Specification| The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed Architecture Definition.\\As mentioned above, the Architecture Requirements Specification is a companion to the Architecture Definition Document, with a complementary objective.|The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do to comply with the architecture. The Architecture Requirements Specification will usually form a major part of the implementation contract or agreement for a more detailed definition of the architecture.|As stated above, the Architecture Requirements Specification is a companion document to the Architecture Definition Document. |The Architecture Roadmap lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture. The Architecture Roadmap highlights individual work packages' business value at each stage. Transition Architectures necessary to effectively realize the Target Architecture are identified as intermediate steps. |The Architecture Roadmap lists the individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture. The architecture roadmap highlights the value of each work package to the Authority at each stage. The transition architectures necessary to effectively implement the target architecture are identified as transition steps. |Architecture Vision |The Architecture Vision provides a summary of the changes to the enterprise that will accrue from successful deployment of the Target Architecture.\\ \\ The purpose of the Architecture Vision is to provide key stakeholders with a formally agreed outcome. |Architecture Vision provides a summary of the changes to the enterprise that will accrue from successful deployment of the Target Architecture.\\ \\ The purpose of the Architecture Vision is to provide key stakeholders with a formally agreed outcome. |Business motivators, goals, and principles |Business principles, business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise. |Business principles, goals, and motivators provide context for architecture work, by describing the needs and ways of working employed by the enterprise. |Capability Assessment |Before embarking upon a detailed Architecture Definition, it is valuable to understand the baseline and target capability level of the enterprise. |It is useful to understand the baseline and target capability levels of the enterprise before beginning a detailed architecture definition.\\\\ Typical contents of a Capability Assessment are:\\\\ ■ Business Capability Assessment\\\\ ■ IT Capability Assessment\\\\ ■ Architecture Maturity Assessment. |Change Request |During implementation of an architecture, as more facts become known, it is possible that the original Architecture Definition and requirements are not suitable or are not sufficient to complete the implementation of a solution.\\\ Change Request may be submitted in order to kick-start a further cycle of architecture work. |During implementation of an architecture, more facts may come to light that cause the original Architecture Definition and requirements to be unsuitable or insufficient to complete the implementation of a solution. |Communication Plan |Enterprise Architectures contain large volumes of complex and inter-dependent information.\\\ \\ Effective communication of targeted information to the right stakeholders at the right time is a Critical Success Factor (CSF) for Enterprise Architecture. The development of a Communications Plan for architecture allows for this communication to be carried out within a planned and managed process. \\\\Enterprise architectures contain large volumes of complex and interdependent information.\\\\The effective communication of targeted information to the right stakeholders at the right time is a Critical Success Factor (CSF) for enterprise architecture. |Conformance assessment |Once an architecture has been defined, it is necessary to govern that architecture through implementation to ensure that the original Architecture Vision is appropriately realized and that any implementation learnings are fed back into the architecture process. Periodic Compliance reviews of implementation projects provide a mechanism to review project progress and ensure that the design and implementation is proceeding in line with the strategic and architectural objectives. |Once an architecture has been defined, it is necessary to govern that architecture and oversee its progress through implementation to ensure that the original Architecture Vision is appropriately realised and that any implementation learnings are fed back into the architecture process. Periodic reviews of implementation projects provide a mechanism for reviewing project progress and ensuring that design and implementation continue to align with the strategic and architectural goals.| |The Implementation and Migration Plan provides a schedule of the projects that will realize the Target Architecture. The Implementation and Migration Plan includes executable projects grouped into managed portfolios and programs. |The Implementation and Migration Plan provides a schedule of projects that will realize the Target Architecture. The Implementation and Migration Plan includes executable projects grouped into managed portfolios and programs. | |Implementation Governance Model |Once an architecture has been defined, it is necessary to plan how the Transition Architecture that implements the architecture will be governed through implementation. |Once the architecture is defined, it is necessary to plan how the governance of the architecture's implementation will be managed.\\The Implementation Governance Model also ensures that as a project transitions into implementation, it transitions into appropriate Architecture Governance. |Organization Model for EA |In order for an architecture framework to be used successfully, it must be supported by the correct organization, roles, and responsibilities within the enterprise. Of particular importance is the definition of boundaries between different Enterprise Architecture practitioners and the governance relationships that span across these boundaries. |In order for an architecture framework to be used successfully, it must be supported by the right organization, roles, and responsibilities within the enterprise. |Requirement for architecture work |This is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle. |This is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle. |A Requirements Impact Assessment assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes. |A Requirements Impact Assessment assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes. |Detailed description of candidate solution which conforms to the specification of an Architecture Building Block (ABB). |Detailed description of candidate solution which conforms to the specification of an Architecture Building Block (ABB). | |The Statement of Architecture Work defines the scope and approach that will be used to complete an architecture development cycle. The Statement of Architecture Work is typically the document against which successful execution of the architecture project will be measured and may form the basis for a contractual agreement between the supplier and consumer of architecture services. |The Statement defines the scope and approach that will be used to complete an architecture development cycle. |Customized Architecture Framework |Before the TOGAF framework can be effectively used within an architecture project, tailoring at two levels is necessary.\\\\ 1) to tailor the TOGAF model for integration into the enterprise.\\\\ 2) to tailor the framework for the specific architecture project. |Before the TOGAF framework can be effectively used in an architecture project, tailoring at two levels is necessary:\\\\\ 1) to tailor the TOGAF model for integration into the enterprise,\\\\\\\ 2) to tailor the framework for the specific architecture project. === Interpretation of architecture deliverables ==== In this section, NAR initially introduces new types of deliverables/fulfillments, in the form of documents or models in the architecture repository. These will be progressively refined based on the experience of the first projects. Furthermore, they will be linked with other documents and responsibilities in the material Methods of ICT management of the Czech Republic, so that they form a coherent and balanced system without unnecessary overlaps, duplications or, on the contrary, gaps. An example of this is the need to link a number of the general deliverables of the architecture listed here with the specific deliverables of the individual engagements specified above, such as the Architectural Vision, the Information Concept of the OVS or the Request for OHA Opinion. There will be further explanation of the content, meaning, and interrelationships of the deliverables. ==== Interest Groups, Viewpoints and Perspectives ==== Viewpoints are based on the idea that there are several different groups of interested people who need only a certain type of information and varying degrees of detail to do their work. If they were presented with more, the model would become opaque to illegible to them, or they do not have the necessary knowledge to understand too much detail. According to the definition given in the TOGAF framework, aspect means: "A viewpoint defines the perspective (point of view) from which a view ((View)) of the model can be seen. It is a specification of the conventions for creating and using a view. While a View is a specific diagram, the Viewpoint tells how the diagram should look and what it should present to the user." This definition is nicely complemented by the image shown below, taken from the ArchiMate 2.1 specification for a change: {{ :nar-document:image63.png?600 | Classification of viewpoints according to the ArchiMate 2.1 language, source: (The Open Group, 2017), MsK translation}} Thus, each aspect corresponds to the needs and capabilities of a different group of stakeholders and may serve different purposes. The definition implies that a viewpoint is actually a kind of **partial metamodel** (it has a defined set of relevant feature types and their interrelationships), or a **viewpoint definition**, i.e. a guide to graphically expressing the topology and color of the model. The following sections will therefore define the viewpoints used and define the roles of those involved, corresponding to these viewpoints. A nice illustration of the categories of stakeholders, their needs and their corresponding types of views of the whole model, but which in practice does not itself have an overall graphical expression, is shown in the following illustration in Figure below: {{ :nar-document:image64.png?600 | Overview of the relationship of stakeholders, their interests and their views on the model, source: P. Klučka, MIT project}} Each of the stakeholders in the image above receives their own view (catalogue, matrix, diagram), corresponding to their needs and their point of view. The overall diagram, if at all realizable, is used only by the chief architect and the model maintainer for model checking. The terms "Viewpoint" and "View Definition" are considered almost synonymous and more or less interchangeable. While a "Viewpoint" may speak more to where the stakeholder is looking at the model from, with what needs, and with what perceptual capabilities, a "Viewpoint Definition" specifies what the "Viewpoint" should have the requisites (dimensions, metamodel elements, form, language, etc.) to bring the stakeholder looking at the model from a particular "Viewpoint" the expected utility. The two definitions of architectural outcomes, as Views and as categories of artifacts, are closely related. All three categories of artifacts (catalogs, matrices, and diagrams) represent views and must correspond to the respective viewpoints of the stakeholders. Since catalogs and matrices are also the starting point for proper graphical representation, NAR associates the term view predominantly with the artifact type of graphical diagram view of the model. ===== National Architecture of the National Academy of Sciences viewpoints and definitions. ==== Overview of NAR Viewpoints ==== In the following sections, the National Architecture Framework provides an overview of all known viewpoints and their corresponding viewpoint definitions that can be helpful to public architects in communicating their understanding to stakeholders. The viewpoints and viewpoint definitions are taken from the key standards for NAR, i.e., TOGAF and ArchiMate, as well as from other de facto standards such as Zachman((The Zachman Framework for Enterprise Architecture, [[https://www.zachman.com/about-the-zachman-framework|Zachman framework]]. )) or from best practice frameworks from other countries, such as New Zealand's GEA-NZ((GEA-NZ 3.2 - Output summaries: [[https://www.ict.govt.nz/assets/Architecture/GEA-NZ-Framework/GEA-NZ-Context.pdf|GEA-NZ-Framework]] (unfortunately the material has been moved, it is available from OHA on request). )). An important source of perspectives for NAR is the architectural practice of the offices of the HHS. Only experience shows who the typical stakeholders in OVS are, what their needs are, and what perspectives on EA of the office have worked well for them. NAR will gradually adopt and generalize into a best practice format the proven perspectives from all local architectural methodologies that OHA becomes aware of. Each of the standards and patterns categorizes outcomes and artifacts, fulfilling the viewpoints, from different perspectives, dimensions. While ArchiMate and GEA-NZ classify primarily by architectural domains, for TOGAF it is by ADM cycle phases and for Zachman it is by the intersections between worldview questions (Who, What, Why, Where, etc.) and levels of abstraction. NAR takes both key classifications of viewpoints, by domain and by phase, and adds a third pragmatic approach. Within it, NAR provides mandatory or recommended viewpoints and viewpoint definitions for each explicitly regulated type of architectural engagement, see [[nar_document:process_of_architecture_creation|Process of Architecture Creation]]. The other viewpoints listed in the following sections are merely inspiration, facilitating the beginnings of modeling in offices. Some of the viewpoints and viewpoint definitions from each source overlap with each other. In this case, NAR combines these definitions and selects what is relevant from both, from all sources, into its own specification of the viewpoint. There are plans to publish a table in the NA VS Knowledge Base mapping the NAR recommended viewpoints to the sources (mainly ArchiMate, TOGAF and Zachman, but also others) from which they come. For each aspect and view definition, or associated deliverables, NAR distinguishes the associated level of the government hierarchy, i.e. whether the deliverables are All-of-Government((It would be useful to use some acronym such as this one from All-of-Government. )))), or they can also be corporate, or they are exclusively the creations and outputs of individual authorities. The overview of creations and outputs also highlights which catalogues and their corresponding graphic outputs are new and absolutely crucial to the development of NA from NAR's perspective: * Authority Business Capability Map - what my authority can do and to what extent it is supported by IT * A map of government agendas, services, or processes and functions - a more accurate representation of an authority's capabilities through its business conduct elements. * Map of the Authority's application components - what applications my Authority uses and what state they are in * Map of the Authority's technology infrastructure - where and on what platforms my Authority operates its IS * Map of the Authority's communications infrastructure - what are all the ways in which my Authority connects its computing capabilities to the outside world * A roadmap of change (at least in application architecture) - when and why we will change, evolve or discontinue our information systems * Motivation Map - a summary of the impacts, goals and expected outcomes of the Authority For the internal need to establish the creation, management and use of EA, it is necessary to develop and use a view of the Authority's sub-capability: * A model for managing the Authority using EA NAR assumes that a modeling accelerator in the form of a Reference Model (RM) will be available for each portfolio classification viewpoint of the Map type. RM business architectures and application architectures are currently available. === Aspects taken from TOGAF === An overview of the type aspects defined in the section of TOGAF called Architecture Content Framework (ACF((From the Architecture Content Framework )))), marking and interpretation of the aspects taken into the NAR can be found in the Knowledge Base of the NA VS CR. === Aspects taken from ArchiMate === The ArchiMate language version 2.1 defined a total of 18 basic aspects and 9 aspects belonging to the motivational and implementation extensions as examples of possible aspects. For the purposes of the NAP, the 12 most commonly used specific aspects in the Czech Republic were selected with a view to their further practical use. An overview of them can be found in the Knowledge Base of the NA VS CR. In addition, the ArchiMate 2.1 specification included a general viewpoint representing a graphical representation of matrices and architectural classifications, called the Landscape Map Viewpoint. In NAR, this general recommendation is elaborated for each of the business, application and technology architecture layers and for the capability architecture in the strategic domain. These so-called Portfolio Maps are the vehicles for the graphical representation of the classification and topology (placement) of architecture elements in the so-called Reference Models. For the NA VS CR, a pair of perspectives, the internal structure perspective and the external service perspective, are always considered as fundamental aspects in addition to the portfolio maps. While the first aspect focuses on modelling the internal functioning of the authority, its functions, applications and technologies, the second aspect focuses on the use of these functions through services for specific beneficiaries. For practical reasons, NAR adds an organizational perspective in the business layer, an information structure perspective in the IS architecture layer, and an application collaboration (communication, integration) perspective. If necessary, NAR allows to use the recommended ArchiMate aspects in the motivation and implementation area. In order to support the strategy of the so-called four-layer architecture vision, NAR adds communication infrastructure aspects, i.e. views focused on those infrastructure elements that stand outside the technology (data) centres and enable their interconnection and connection to the KIVS/CMS shared eGovernment services. In terms of metamodel and definitions, the same resources of the infrastructure (green) layer of the ArchiMate language are appropriately used for these views. Therefore or despite the fact that they are subsequently used twice in the diagrams of the individual architectures, for IT technologies and for communication infrastructure, it is not necessary to duplicate and specialise their definitions as well, but it is permissible. === Aspects taken from the Zachman framework === No viewpoints have been taken from the Zachman architectural framework, version 3.0, which is the so-called ontology of architectural models, so far, no viewpoint definitions corresponding to them have been taken. If any viewpoints will be newly included, their overview and definition will be in the NA VS CR Knowledge Base. === Currently recommended NAR viewpoints ==== The following diagram represents a subset of the aspects and their corresponding graphical view definitions for the Authority Architecture Model (diagrams), selected from the TOGAF, ArchiMate, and practice viewpoints and currently included in the customized NAR framework as they are intended to serve the purpose of consistency of processing and navigation in the shared architecture repository. Furthermore, the list of recommended aspects is extended in advance to include aspects of the so-called European Interoperability Reference Architecture (EIRA). ))), version 2.1.0. All the aspects listed in the diagrams below correspond to the graphical diagrams, the aspects for the catalogues and matrices are not listed, but are their assumptions. {{ :nar-document:image65.png?600 | Overview of the basic aspects (view definitions) of the National Architecture of the Czech Republic, source.} {{ :nar-document:image66.png?600 | Overview of EIRA reference architecture aspects, source: ISA2, translation by MV}} In general, in these early stages of NA implementation in the VS CR, it is allowed to use any type of catalogue, matrix or diagram for the architectural aspects of the architecture of the authorities, with the recommendation of the ArchiMate and TOGAF ACF((From the Architecture Content Framework )), provided that the guidance for the selected architectural engagement, see [[nar_document:architecture_creation process|Architecture_creation_process]] Practical Examples for Architecture Engagements, does not explicitly state otherwise. For all catalogues and matrices, below, currently included in the National Architecture Framework, the registered attributes of objects will be gradually defined and working patterns will be published in the NA VS CR Knowledge Base, both in a spreadsheet editor for the initial inventory and in the ArchiMate exchange format. ==== Overview aspects ==== Among the overview aspects, the so-called Service Overview aspect of the four-layer eGovernment architecture is currently defined. This aspect maintains continuity with previous eGovernment strategy documents of the Czech Republic and provides stakeholders with an overview of the mutual transfer of services between the different layers of the architecture. The viewpoint corresponds to the structure of the ArchiMate metamodel and the standard viewpoint of architecture layers, but due to the division of responsibilities, it separates the architecture layer of technological communication (and building) infrastructure separately and emphasises the role of services. In addition, the standard ArchiMate aspects, the so-called introductory aspect and the architecture layer aspect, are applied as appropriate. The Enterprise Capability Map can also be considered as an overview aspect. )), which shows the division of offices into smaller parts (segments and capabilities) according to what business outputs (internal and external) they can provide, but without considering what they contain internally, in their architecture. In the standard ArchiMate specification, this aspect is part of the strategy, and for NAR will mainly act as a necessary overview. === Service Overview aspect of a four-layer architecture === The service aspect of a four-layer architecture is really focused on expressing the relationship between the internal behavior (i.e., in particular, the capability) of the active element of a given layer and the external manifestation of that behavior (capability) to the higher-layer element, i.e., the service. {{ :nar-document:image67.png?600 | Metamodel viewpoint of the Four Layer Architecture Overview, source MV using (The Open Group, 2017)}} Other elements of the ArchiMate metamodel are intentionally omitted to emphasize the main idea of layer collaboration. === Introductory considerations === Contains all elements of the language in the form of a simplified graphical notation. It is primarily used for rough design, when the information needed for a detailed description of the enterprise architecture is not yet available. It can therefore be used for a very detailed to very general rough design that is intended for all stakeholders. It is typically used to express an architectural vision. A feature of this viewpoint is that it often departs from the strict ArchiMate visual notation in the interest of better understanding by stakeholders. This is also the case in this NAR methodology. For example, a **definition** of this viewpoint might look like the following: {{ :nar-document:image68.png?600 | Example of a possible representation of an initial viewpoint, source: (The Open Group, 2017) http:%%%%pubs.opengroup.org/architecture/archimate2-doc/ts_archimate_2.1_files/image131.png }} === Aspect of layers architecture === As the name implies, this viewpoint is used to represent multiple layers of architecture within a single diagram. There are 2 categories of layers, namely **dedicated** and **service** layers. In the first category of layers we include actors, business processes, applications and infrastructure elements. The second category of layers includes services. The **layer categories alternate**. What is important is their relationship. The dedicated object layer implements the service layer (the "**implementation**" relationship). This service layer is subsequently used by another dedicated layer (the "**serve**" relationship). This view allows us to distinguish the internal structure of the organization that is expressed by the dedicated layer from the externally recognizable behavior expressed in the service layer. The number of layers is not fixed. The metamodel of this view is based on the overall ArchiMate 3.1 metamodel. Thus, the figure below is only an example of a possible use case, not a complete metamodel of this layer. (The key is the alternation of dedicated and service layers and the use of appropriate bindings). Within the NA VS CR, a specialized viewpoint is derived from this ArchiMate viewpoint to express the fulfillment of the so-called four-layer eGovernment architecture vision by a specific architecture of an office, segment or capability. === Simplified viewpoint of layers of architecture === In practice, we often encounter the need to express objects in multiple layers of the architecture, but without the possibility to emphasize service layers, for example because the services of a given layer (business, application or technology) are not known and maintained in the organization, the functions of the active elements are not like management services, and therefore cannot be modeled as such. Then the so-called Simplified Layer Perspective (without dividing the layers into dedicated and service layers) is applied. Example from practice: {{ :nar-document:image69.png?600 | Example of layer view, source: MsK pilot project}} === Capability overview aspect of the authority === The Authority Capability Map viewpoint is used when an interested overview of everything an authority can do needs to be presented on one screen, one PowerPoint slide. This is without analysing at this stage which department does it, by which process, under which law or with which information system. It is a structural model in which the overview of the authority's capabilities is expressed by the hierarchical structure of the "Capability" object, either in the form of a hierarchical **Authority Capability Catalogue** or a **Authority Capability Overview (Map)** diagram. The capabilities captured in the model are stable over the long term, only improving. They may be composed of sub-capabilities, assigned by a composite link. {{ :nar-document:image70.png?600 | Metamodel view of an overview of the authority's capabilities (basic).}} Although capabilities can be hierarchical, see above, there are two other ways to approach capability modeling (a) following the TOGAF Enterprise structure and the example of classification maps in other domains. The two approaches together and in relation to each other are summarized in Figure below. According to the TOGAF division, the whole Enterprise is considered strategic, further divided into (vertical, sectoral) segments and these are only further divided into capabilities (vertical and cross-cutting, horizontal). For the eventual modelling of the segments of the office it is proposed to use a specialised capability stereotype, called <>, or just <> for short. The top-level areas that are not a segment of Authority performance are modeled directly as a non-specialized Capability. {{ :nar-document:image71.png?600 | Complete metamodel of the Authority Capability Aspect.}} It is possible to consider only low-level (higher detail) Capabilities and to use not Capabilities but Groupings to group (classify, sort) them, see Figure above (left). Only practice will tell which of the ways of modelling capabilities will actually take hold. {{ :nar-document:image72.png?600 | (Representative) example of the Capability Overview view, source: Marc Lankhorst, Blog}} Image - An office capability overview, or a basic map of an office, is an excellent means of expression into which to project an assessment of some aspect of capability in particular areas, for example the degree or quality of IT support for capability performance. We call such an expression a Heat Map((It does not yet have an adequate expression in English, it is called "Semaphores" because of the typical colours of green, yellow and red. )) and it occurs repeatedly in NAR in several places. The colors in the example mean: blue - average, green - above average, red - below average, potential for improvement. {{ :nar-document:image73.png?600 | (Representative) example of the Capability Overview view used as an IT Support Heat Map, source: Marc Lankhorst, Blog.}} ==== Motivation Architecture Perspectives ==== Of the four vertical domains of the Motivational Architecture (Strategic Direction, Performance, Security and Compliance), the content of the diagrams for the so-called Motivational Aspect - Strategic Direction - is currently defined for the NA VS CR in accordance with the ArchiMate standard. In the ArchiMate specification it corresponds to the so-called Motivational Extension and in TOGAF it corresponds to the motivational part of the business architecture. For the other motivation domains only catalogues are defined, without matrices and graphical representation. === Motivational aspect of strategic direction === The perspective is used to represent stakeholders, internal and external motivators for change, and an assessment (in terms of strengths, weaknesses, opportunities and threats) of these motivators. It can also be used to describe high-level objectives. The insights generated from this perspective capture the motivation of the authority for strategic change and the associated change architecture. The perspective **does not take into account** other ongoing motivational aspects, such as **motivation for performance and quality of service**. {{ :nar-document:image74.png?600 | Metamodel of the motivation perspective, source: (The Open Group, 2017), translation by MV}} To model diagrams according to this viewpoint, the following catalogues of motivational architecture are prerequisites: * **Stakeholder Catalogue**((From Stakeholders)) * **The catalogue of motivators**((From Drivers)) **and needs**. * **Catalogue of strategic goals**((Goals)), actionable objectives**((Objectives))** **and their performance measures** * **Catalogue of architectural principles** * **Catalogue of key architectural requirements**((This means truly principled requirements at the level of enterprise architecture changes, not functional changes resulting from partial so-called business or IT requirements. These are recorded using ITSM (ITIL) techniques, not here.)) **and constraints** The overall incentive aspect can preferably be divided into: * Stakeholder perspective * Architectural principles perspective === Performance architecture perspectives === The Performance Architecture currently has no defined aspects for graphical diagrams, nor does it have a specific metamodel, although a specialized "Metrics" type of element object could be at least partially used. The following catalogues are proposed for the performance architecture: * **Performance and Quality Indicators Catalog**, where the 3E indicators are counted, divided into: *Increase Economy((Economy) - refers to the resource cost for the inputs consumed. Economy metrics are used to assess whether an appropriate price is being paid for the acquisition of necessary resources.)) the use of resources for a public service * Improving efficiency((Efficiency - 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 the way an activity is carried out.)) the work of resources in producing outputs * Increasing Effectiveness((Effectiveness 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.)) of service outputs to achieve outcomes * Increase in the level and quality of the service in question, i.e. the value of the service as perceived by its consumers, the clients of the public administration. * **Catalogue of results, impacts and policy multiplier effects** (strategic initiatives) No matrices or diagrams **are currently proposed for the performance architecture**. === Security architecture considerations=== The Safety Architecture does not currently have any defined aspects for graphical diagrams, nor does it have a specific metamodel, as objects of type "Risk" and "Mitigation Measures" are not yet part of the standard ArchiMate 3.1 language specification. The use of a security architecture in the spirit of and in support of the Cyber Security Act (ZoKB) and ISO 27001, respectively, is in preparation. I.e. in the spirit of The Open Group recommendations, metamodel elements (necessary stereotypes) will be created for this area by specialising other existing elements and dedicating them to an asset, threat, risk, measure, ... i.e. concepts according to ZoKB. Due to the reticence in extending the metamodel, this will not happen in the near future and must be preceded by pilot projects. For the security architecture, the following catalogues are proposed so far: * **Passive Security Architecture Catalogue,** i.e. a catalogue of elements of the Authority's architecture that require specific protection. It is used in particular in the Project Start Architecture (PSA) to highlight newly implemented elements worthy of special protection that the Authority does not yet have. * **Catalogue of active security architecture,** i.e. catalogues of elements of the Authority that by their presence provide extraordinary (additional) protection to other elements. It is mainly used in the PSA (see above) to highlight newly implemented security elements. There are currently **no matrices or diagrams** proposed for the security architecture. === Aspects of architecture compliance, standardization and sustainability === The Compliance, Standardization and Sustainability Architecture currently has no defined aspects for graphical diagrams, nor does it have a specific metamodel. The following catalogues are proposed for this architecture: * **Regulations and Standards Catalog**. * **Standards Catalogue** * **Catalogue of architecture building blocks and solutions** * **Catalogue of principles and measures for the long-term sustainability of the Authority** There are currently **no matrices or diagrams** proposed for the compliance, standards and sustainability architecture. ==== Business Aspects of Service Delivery Architecture VS ==== The business architecture aspects of VS primarily define several fundamental **catalogues** in which several nearby objects are always inventoried. These are: * **Catalogue of organizational units**, departments and positions, * **Catalogue of actors** (their types) **and** their **roles** - specific actors are usually not inventoried (e.g. natural person, citizen, employee), replaced by the type of actors and an estimate of the number. * **Catalogue of functions and processes** * **Catalogue of public administration services** * **Catalogue of public administration communication (service) interfaces** There are currently **no matrices** proposed for the business architecture of public administration services performance. The following aspects are currently defined in NAR for the business architecture. === Public administration functions aspects === The public administration functions perspective depicts the major business functions of an organization and the relationships between them. Business functions are used to depict the core activities that an enterprise performs, regardless of organizational changes or technological developments. Therefore, business architectures of companies operating in the same market often show similarities. This perspective provides a detailed view of the company's operations and can be used to identify the necessary competencies or to structure the organisation according to core activities. {{ :nar-document:image75.png?600 | Definition of the public administration functions perspective, source: MV using ArchiMate 2.1 and 3.1 (The Open Group, 2017)}} === Actor collaboration perspective === In its simplest form, this perspective shows the relationship between a dynamic actor (role) and the entity or organization that takes on the role (actor). {{ :nar-document:image76.png?600 | Definition of the actor collaboration viewpoint, source: MV using ArchiMate 2.1 (The Open Group, 2017)}} The bottom line is that the existence of an actor is permanent, whereas it only takes on a role when it enters into an interaction (provides or consumes a function as a service). The possible specialisation of actors into organisations and departments will first need to be verified in practice. === The collaborative aspect of business processes === The business process collaboration perspective is used to illustrate the relationship of one or more business processes to other processes or their environment. Firstly, it can be used to create a high-level representation of business processes together with the necessary context for the purpose of creating these processes, it can also serve as a presentation aid for operational managers, providing them with the necessary overview of the dependencies of the processes they manage. The business process perspective is used to show in detail the structure and composition of business processes. In addition to the processes themselves, the viewpoint also includes other directly related concepts such as: * Services provided by business processes externally; showing how the process contributes to the realization of the company's products * Assignment of business processes to roles, which tell about the responsibilities of the assigned actors * Additional information used by business processes through application services {{ :nar-document:image77.png?600 | Definition of business process collaboration aspects according to ArchiMate 2.1 specification, source: (The Open Group, 2017), translation by MV}} === Organizational structure perspective === The organizational aspect is used to represent the (internal) organizational structure of an organization, or one of its sub-organizational units. It can also be used to represent the network of organisations (e.g. founder and organisational units, contributory organisations, etc.). The model can be presented as a digram in the form of nested blocks or as a traditional organisation chart. The organizational structure aspect is useful in identifying competencies, authorities and responsibilities in an organization. Especially for this aspect, it is recommended to nest the elements. This provides the reader with a clear and very intuitive organisational structure. In terms of the level of detail, this is a linking aspect for all interest groups. {{ :nar-document:image78.png?600 | Metamodel of the organizational viewpoint according to the ArchiMate 2.1 specification, source: (The Open Group, 2017), translation by MV}} Example: {{ :nar-document:image79.png?600 | Example of organizational viewpoint, source: MsK pilot project}} === Product perspective === {{ :nar-document:image80.png?600 | Metamodel of process viewpoint according to ArchiMate 2.1 specification, source: (The Open Group, 2017), translation by MV}} === Portfolio perspective of business functions and services (Map) === The content of this viewpoint is based on a three-level classification of all business architecture elements. With a little imprecision, it can be said that both business roles, their functions, their processes and their services, and the associated VS objects can be uniquely classified, i.e., each can be assigned to just one of the business areas, categories and groups. At the same time, the reference models present graphical representations of the distribution of the classified domains, their areas, categories and groups, i.e. their so-called topology. The consistent use of topology from the reference models will significantly speed up the creation of Map-type diagrams and greatly facilitate their reading and interpretation. NAR recommends here the use of the "Grouping" object to express a classification and its topology in models. {{ :nar-document:image81.png?600 | Metamodel viewpoint of a portfolio of business functions and services (Map)}} On the contrary - this methodology considers it inappropriate to use objects dedicated to actually existing architecture elements (business functions, processes or services) for classification levels. However, this makes the actual architecture model inconsistent, as it lists components that actually exist and others that only virtually represent them in the classification. It is then impossible to report on the architecture in a reasonably automated way over such a model. Exceptions are specialized concepts such as <>, for example <> and <>, but these are not part of the Portfolio Map diagram unless they are classified together and consistently with other non-specialized business functions. ==== Information Systems Architecture Considerations ==== The foundation of information systems architecture and its artifacts are catalogs of key objects. These are in particular: * **Business and Data Entity Authority Catalog.** Both business and data objects can be captured in a single catalog. Alternatively (in the case of a more developed data architecture), it is useful to split the data architecture into several catalogues and record different attributes (properties) for each type of entity. Thus separately: * **Catalogue of objects / subjects of public administration (office)** * **Catalogue of data objects of the authority** * or **Catalogue of data artefacts,** physical files, tables and other data stores. * **Catalogue of application components and functions.** This catalogue can be extended, if necessary, with elements of application collaboration and application interaction. * **Application Interfaces Catalogue** * **Application services catalogue,** is derived from the internal application functions, it may have different details and different registered properties of services than the application functions. There are currently **no matrices** proposed for the application architecture of public administration service performance. === Information structure considerations === {{{:nar-document:image82.png?100 | Information structure viewpoint metamodel.}} This viewpoint, like the entire so-called TOGAF data architecture metamodel above, covers objects across all three layers of the ArchiMate architecture. Within this viewpoint, the ArchiMate notation can use "VS Objects/Subjects", the so-called Business Object, to capture the so-called conceptual data model of the key objects of record. Alternatively, "Data Objects" can be used to capture the logical data model diagram. A combination of both types is also very common and recommended, showing how real objects have their images in data objects. The information structure aspect is comparable to traditional information models created in the development of any information system. It shows the structure of information used in an enterprise or in specific business processes or applications in the form of data types or object-oriented classes. The viewpoint can also be used to show how business information is represented at the application level in the form of data structures, and how it is mapped to the underlying infrastructure, for example, through a database schema. The representation of information structures in ArchiMate is usually followed by detailed diagrams in other notations - ERD, UML, see also [[nar_document:ramec_content_and_output_architectures|Content and Output Architectures Framework]]. === Application structure considerations === This viewpoint focuses only on the active and passive elements of the application architecture, deliberately ignoring their behavior. The application structure viewpoint shows the structure of one or more applications and components. The viewpoint is used to design or understand the underlying structure of applications or components and associated data; for example, one can dissect the structure of a system under construction or identify legacy application components that are suitable for migration or integration. {{ :nar-document:image83.png?600 | Metamodel application structure view definition}} === Application Behavior Perspective === The main object and focus of this viewpoint is application functionality. The aim of the viewpoint is to capture, in the best possible way, what application components or their collaborations can do, i.e. what functionality they have. The application aspect is used to represent the internal behaviour of the described application, which may provide one or more services. The primary use is in designing the core functionality of applications or identifying overlapping functionality provided by different applications. The viewpoint is detailed and intended for practitioners. {{ :nar-document:image84.png?600 | Application Behavior Aspect Metamodel}} Example: {{ :nar-document:image85.png?600 | Example of application behavior view, source: MsK pilot project}} === Application Collaboration Perspective === The focus of this viewpoint is to capture how application components are integrated with each other through the application interface. The application collaboration aspect describes the relationships between application components in terms of the information flows between them and the services offered, including their usage. The perspective is typically used to provide an overview of an organisation's application facilities. It is also used to express the (internal) collaboration or arrangement of services that support the execution of business processes. This viewpoint is primarily used to illustrate to detail application-level linkages. {{ :nar-document:image86.png?600 | Application Collaboration Aspect Metamodel}} Example (without using an interface object): {{ :nar-document:image87.png?600 | Example of application collaboration view (without interface object), source: MsK pilot project}} {{ :nar-document:image88.png?600 | Example of a completely simplified application collaboration view, source: Bernd Ihnen, [[https://bizzdesign.com/blog/practical-archimate-viewpoints-for-the-application-layer/|Blog]].}} === Application usage perspective === The application usage perspective describes how applications are used to support business processes, and also how they are used by other applications. It can be used when designing applications by identifying the application services needed for business processes or when designing business processes by describing the available services. Since business process dependencies on applications are identified, the viewpoint can also be used by operations managers responsible for these processes. This viewpoint represents a logical continuity between the business and application layers. {{ :nar-document:image89.png?600 | Application Usage Aspect Metamodel}} Example: {{ :nar-document:image90.png?600 | Example of application usage perspective, source: MsK pilot project}} === Application Portfolio Perspective (Map) === The content of this viewpoint is based on a three-level classification of all elements of the application architecture. With a little imprecision, it can be said that both application components, their functions, their services and their associated data objects can be uniquely classified, i.e., each can be placed in just one of the application categories. {{ :nar-document:image91.png?600 | Metamodel view of the portfolio of application functions and components (Map)}} At the same time, the reference models present graphical representations of the distribution of classified domains, areas, categories and groups, i.e. their so-called topology. Consistent use of topology from reference models will significantly speed up the creation of Map-type diagrams and greatly facilitate their reading and interpretation. NAR's recommendation is to use the "Grouping" object to express a classification and its topology in models. Conversely - this methodology considers it inappropriate to use objects reserved for the actual architecture elements (application components, functions or services) for classification levels. However, this makes the actual architecture model inconsistent, as it lists components that actually exist and others that only represent them virtually in the classification. It is then impossible to report on the architecture in a reasonably automated way over such a model. Exceptions are specialized concepts such as <>, for example <>. === Aspects of requirements implementation by applications === This aspect is an example and specialization of the general motivational (strategic) aspect of Requirements Realization. {{ :nar-document:image92.png?600 | Metamodel of the Requirements Realization Aspect by Applications.}} ==== IT Technology and Communication Infrastructure Aspects ==== The technology architecture aspects of VS primarily define several fundamental **catalogues** in which several nearby objects are always inventoried. These are: * **Node, Device and System Software Catalog**. There are currently **no matrices** proposed for the technological architecture of the performance of public administration services. The following aspects are currently defined for the technology architecture in the National Architecture Framework. All technology aspects can be used for both the evaluation and management of technologies in terms of their placement in DCs (topology of infrastructure in sites) and in terms of consolidation of the technology platforms used. === Technology infrastructure perspective - general ==== The IT technology perspective includes the SW and HW infrastructure elements that support the application layer; these are physical devices or system software (e.g. operating systems, databases and middleware). {{ :nar-document:image93.png?600 | Technology infrastructure viewpoint (structure) metamodel}} Example: {{ :nar-document:image94.png?600 | Example of a technology infrastructure viewpoint, source: MsK pilot project}} === Infrastructure utilization perspective === The technology infrastructure usage aspect shows how applications are supported by the SW and HW infrastructure. Infrastructure services are delivered by devices; system software and networks are provided by applications. This aspect plays an important role in performance and scalability analysis as it relates to the physical infrastructure supporting the logical application domain. The perspective is useful in determining the performance and quality requirements of the infrastructure based on the requirements of the individual applications using the infrastructure. {{ :nar-document:image95.png?600 | Infrastructure Utilization Aspect Metamodel}} === Simplified information systems deployment perspective ==== {{ :nar-document:image96.png?600 | Metamodel of the information systems deployment perspective}} From the practical use of office architecture at the MoH, a simplified viewpoint linking technology nodes, the data artifacts (files, databases) stored in them, and the application components running on them was adopted into the NAR methodology. === Technology portfolio perspective (map) === The content of this viewpoint is based on a three-level classification of all elements of the technology architecture. With a little imprecision, it can be said that both application components, their functions, their services and the associated data objects can be uniquely classified, i.e., each can be placed in just one of the application categories. {{ :nar-document:image97.png?600 | Technology Portfolio Viewpoint Metamodel}} Further comments identical to the other portfolios above. === Communication infrastructure usage perspective (specific to the Czech Republic) ==== A specific diagram to support the expression of the split responsibility of providers of computing power services (data centres) and communication infrastructure services. For communication infrastructure concepts, common technology infrastructure elements or duplicated (dedicated) objects for communication infrastructure can be used. In the architecture of a specific office, it is possible to model both IT technology and communication infrastructure with one set of metamodel elements of the technology layer and only in this aspect and in terms of a four-layer architecture express the division of the ArchiMate technology (green) layer into two, IT technology and communication. {{ :nar-document:image98.png?600 | Metamodel of the communication infrastructure usage aspect}} It is natural to combine both technology and communication infrastructure with elements of the physical architecture layer, representing mainly other non-IT data center objects - buildings, air conditioning, security, etc. === Communication architecture portfolio perspective (Map, specific to the Czech Republic) === The portfolio aspect of the communication architecture area will be similar to that of the technology map, but is not yet specified. ==== Implementation and migration perspective ==== This aspect is used to relate all programs and projects to the parts of the architecture they implement. The viewpoint allows the scope of programs, projects, and project activities to be modeled and related to the plane of the architecture or the individual elements that are affected. The way in which the elements are affected can be represented by appropriately annotating their relationships. {{ :nar-document:image99.png?600 | Recommended metamodel of the implementation and migration perspective}} Example: {{ :nar-document:image100.png?600 | Example implementation view, source: MsK pilot project}} ==== Aspects of the EIRA European Interoperability Reference Architecture ==== A description of the aspects and their practical use will be added to the next version of the NAR methodology. ===== Follow-up detailed modelling methods ===== The modelling of the Authority's Enterprise Architecture, using the TOGAF methodology and the ArchiMate language, is usually preceded on the one hand by strategy and business model modelling and followed on the other hand by more detailed solution architecture and solution design modelling. For both, specific methods and modelling notations are used, for example: * **Strategy:** SWOT, PESTEL, Porter's Five Forces, Balanced Scorecard, Business Model Canvas, Ecosystem model, Business Motivation Model, etc. * **Detail or specialty:** UML, SysML, BPMN, DMN, ERD, Customer Journey Map, Business Outcome Journey Map, etc. 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. {{ :nar-document:image101.png?600 | 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]].}} ==== Linking ArchiMate and BPMN ==== 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: {{ :nar-document:image102.png?600 | 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.): {{ :nar-document:image103.png?600 | 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.