Content and Output Architecture Framework

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

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

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

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

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

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

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

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

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.

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.

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

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

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

Element colours by aspect

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

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

Colour of elements of basic layers (domains).

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

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

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

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

Coloring of Motivational Architecture Domain Elements

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

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

Table of ArchiMate 3.1 color definitions¹⁾)

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.

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.

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

The following table³⁾ provides an overview and explanation of each binding:)

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

Active elements of the office BA

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

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

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

Elements of BA office behaviour

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

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

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

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

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

Passive elements of the BA of the Authority

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

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

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

Bureau BA Composite Elements

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

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

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

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

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

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

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

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

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

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:

Table⁴⁾) with definitions of application architecture metamodel elements

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

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

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

The table⁵⁾ 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.

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

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.

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

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

It combines the motivational architecture according to TOGAF⁶⁾ and the so-called motivational and strategic⁷⁾ 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.

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⁸⁾) with definitions of strategy and direction architecture metamodel elements

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

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

• Organization mission
• The organization's vision

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

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

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

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

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

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

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

The Performance Architecture NA VS CR does not have any specific metamodel elements defined yet. We expect that in future versions of ArchiMate a looser use of the Metrics object (KGI⁹⁾, KPI¹⁰⁾ (especially TCO¹¹⁾), PPI¹²⁾), 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:

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.

Table¹³⁾ with definitions of performance architecture metamodel elements

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

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

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

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:

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¹⁴⁾ elements of an authority's architecture is a prerequisite and input to its security architecture.

Table¹⁵⁾ with definitions of security architecture metamodel elements

Table¹⁶⁾) with security architecture metamodel element definitions

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

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

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

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

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

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

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

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

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

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

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

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

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

No further interpretation is yet prepared in this domain.

The figure below shows the implementation and migration extension metamodel.

Table¹⁸⁾) with implementation and migration architecture metamodel definitions

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.

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:

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.):

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.