Structure of modelled architectures

If the chapter Modeling Offices and their Architectures explains "Whose architecture is being modeled ", what is an office (enterprise), segment and capability in terms of architecture, then later in this chapter it explains "What is being modeled for these entities and why ".

We start from the fact that authorities and enterprises in public administration have an architecture, i.e. a structure of elements, their relationships and behaviours, it is just a matter of knowing it, describing it, understanding it and communicating it. This is done in different parts of the authority, for different purposes, in different detail and in different ways.

If in this methodology we work mainly with architecture description for the purpose of managing the design and implementation of changes in the office, then the different levels of architecture description form a pyramid according to their level of knowledge as follows, see also Figure 4:

• Layers (enterprise) of the office architecture
  • Architectural vision
  • Holistic models of office/enterprise architectures - capability map, ontology and glossary
  • Segment, capability and domain models of office/enterprise architectures
• Office solution architecture layer
  • Domain and project cross-cutting solution architectures
• Specific solution design layer
  • Solution design and implementation of solution components

The Architectural Vision is a layer of aggregated information used to convey basic messages about the understanding of the organization, its current and, more often than not, its target state. The layer does not have to be directly related to the individual cognized sub-elements of the organization. Vision models represent a visualization of selected answers to the strategic questions Where and Why the organization is going.

The second and third layers, along with the vision, represent the enterprise architecture, the Architecture of Authority (EA). These layers capture the inventory, visualization and understanding of what all is in the organization and in what relationships. Models of these layers represent answers to the questions What? and What elements make up the organization. In describing the future state, these layers represent information about What? and Why? the structure of the organization's future system.

The Office Architecture is the vehicle for a holistic view of the office/enterprise. It represents an enumeration of all types of objects (concepts) that occur in the organization, whether or not they are further modeled in the strategic, segment and capability architectures. This list of object types is the basis for a glossary of concepts associated with architecture, i.e. the structure and behaviour of an organisation.

At the same time, this structure of the organisation is expressed by its complete meta-model, or otherwise known as the ontology model. This layer of the enterprise ontology ( )) and conceptual vocabulary could also be referred to as the meta-architecture of the office. From this ontological model of the organization, objects (e.g., process, application service, organizational unit, etc.) are successively selected to inventory the current state and plan for the future state.

Part of the holistic layer is the division of the organization into smaller units whose outputs together constitute the behavior, the life of the organization. We talk about the so-called Business Capability Map )), providing a complete overview of the organisation in one diagram. At the same time, the grouping of capabilities in the map shows the logic and meaning of the so-called segments of the organisation's activity, e.g. segments of public service types. Here, each individual capability represents the smallest unit of the organisation, whose internal architecture is of no interest to us at this level of planning, but which can be further explored and explored in lower, more detailed layers.

In the holistic layer, the objects found are captured together; the models are not divided into segments or domains.

The Sectional or Domain Authority Architecture (strategic, segmented or capability) is the third layer of the Authority Architecture, representing the focus of the content of the architecture description in each of the traditional (red framed) and less common domains, see the following Figure.

The cognition in this layer is focused exclusively on the existential aspects of all the elements of the authority architecture and their relationships (that they exist, how old they are, where they come from, who is responsible for their existence, how long they will be available, etc.).

This image is a combination of the grey pyramidal model and the colored domain model, presented together with a more detailed description of the domains of the office architecture in the following section.

Solution Architecture( ))) is no longer considered part of the so-called (enterprise) architecture of the Authority, but is largely related to it. Solution Architecture is the layer of architecture that explains how the elements that make up an organisation work, what their internal structure is, how they work together to respond to (solve) a specific need. Its models thus represent a visualization of the answers to the question in particular: How does it work? or rather: How is it supposed to work? The solution architectures must conform to the architectural principles of the office/enterprise architectures from the higher layers of the pyramid model.

Solution architectures are usually incremental, covering a portion of the problems to be solved and changes to the organization (program, project) that fit each incremental need and opportunity for change. Solution architectures often go across multiple architectural domains, but can also be within a single one. They are typically valid for a sub-segment or for a government capability and no longer need to be, or are, agency-wide. Or they cover a group of architecture elements that have something in common, perhaps they are addressed by applications on a single platform. The solution architecture layer also includes domain architectures, which are refined to an appropriate level of detail in their level of description. They are often created in this way gradually, by composing the contributions of individual solution projects.

Solution architecture domains can correspond exactly to the Authority architecture domains, see the following figure, where the blue framed domains represent detailed elaborations of traditional TOGAF domains. Solution architecture domains will in many cases correspond to sub-management disciplines such as BPM¹⁾, EPM²⁾ or QM³⁾ and will use the appropriate tools and notations.

Solution Design⁴⁾) is an architecture layer that provides a detailed understanding of how a sub-element of the architecture can be designed, manufactured, and how to put into operation a particular element of the Authority's architecture. This may be a workflow (process) change proposal, a programming specification for a software component, a formula for calculating a performance indicator, etc. Solution design models represent a visualisation of the answers to the question How is it done?, or How should it be done?. Although these design documents are no longer artifacts of the architecture, they form a unified body of knowledge about the office/enterprise, and they too should be created in accordance with the knowledge and mandatory requirements of the higher layers of the office architecture.

The focus and content of national architectures vary from country to country and change over time. The following architectural domains are proposed from the outset to be included in the NAR framework for the National Security Architecture, see also the following Figure.

Horizontal ("Core") ))) architecture domains express all the basic elements of an organization's existence, i.e. its functioning and its resources (here still focused mainly on IT resources). Thus, the concepts providing an answer to the question What makes up our organization:

• Business Architecture - i.e. the architecture of all components of government performance and supporting operational functions, particularly focused on processes, services, organization, roles and responsibilities.
• Information systems architecture, divided into:
  • Information (data) and
  • Application architecture.
• Technology architecture, divided according to the four-layer architecture vision into:
  • IT technology architecture, also called platform architecture and
  • Communication infrastructure architecture, also known as platform architecture

The vertical domains of the motivational architecture, complement and intersect the horizontal architectures and provide answers to the question Why is our organization the way it is, or Why should it be different than it is?

• Strategy and Direction Architecture, originally called just Motivation Architecture
• Performance architecture, measuring achievement of both strategy and operational effectiveness
• Risk and Security Architecture - affecting specific security aspects across domains
• Architecture of compliance, standardization and long-term sustainability

This division proposes, among other things, that the concepts of motivation are moved from the business architecture according to TOGAF to the separate domain of strategy and direction architecture. Of the domains that TOGAF considers, for example, to be part of the content of the content metamodel (ACF ))), but does not model them as architecture, have been moved to the domain of Compliance & Sustainability Architecture in accordance with ArchiMate ))") some negatively motivating (limiting) concepts such as constraints and assumptions have been taken over. In the case of the architecture for SSR, these are mainly laws formulating the content of the so-called agendas. Subsequently, the formulated (declared) binding standards of architecture are placed in the same domain. The third part is, for organisations dealing with sustainability (CSR⁵⁾, TUR⁶⁾, MA21⁷⁾)) rules of sustainability criteria.

This proposed domain structure of the architecture framework is particularly beneficial for the NA VS CR because, as a combination of the two standards most used in public administrations, TOGAF and FEAF (in the latest modification for GEA-NZ 3.2), it facilitates the initial introduction of enterprise architecture into the practice of public administration in the Czech Republic and will support its first objective, which is effective management of ICT VS. Subsequently, this domain layout is open for future development according to the needs of the use of NA VS CR increasingly for the actual VS reform.

The coloring of the domain layout of the NA VS CR, see previous Figure, is not random. The colours of the traditional horizontal domains (layers) according to TOGAF/ArchiMate adopt the colours of the ArchiMate language layers (Lankhorst, et al., 2009), the colours of the vertical domains are taken from the GEA-NZ 3.2 reference model scheme (Deleu, 2014).

Table⁸⁾) definitions of element colours in NAR domains

Conflict arises in relation to the colours of the motivational and strategic domains of ArchiMate. It will be temporarily resolved by having the elements of the vertical (motivational) domains retain the colors of the ArchiMate concepts with which or whose specializations they are expressed. So, as the importance and scope of concepts grows, especially in the security and standards domains, it can be assumed that their coloring will be resolved at the world standards level, otherwise it will be resolved in future versions of NAR.

A special position in the structure of the architectural domains is occupied by the so-called Data Architecture. For TOGAF it is one of the two equivalent components of the IS architecture, but the ArchiMate language does not know it at all (it does not specifically formulate it). Similarly, the vision of a four-layer eGovernment architecture does not work with the Data Architecture. Consistent with all these assumptions, the NAR methodology mostly considers data architecture as an implicit part of the IS architecture, and in selected cases emphasizes it separately, see for example Content and Output Architectures Framework and the preceding Figure.

The light red area in the preceding Figure represents the so-called Implementation and Migration Domain, corresponding to the ArchiMate Implementation and Migration Extension, and allowing to visualize also work packages, projects, programs and the architecture state changes (intermediate and target) achieved by them. Here too, we can speak of the domain of the organization model, focused on dynamic, project-oriented objects of office management or its changes.

The work of central and local architects of public administration will produce a number of models of different relevance in the management of authorities. Some of the models serve as defining or supportive in the development of authority architectures, others are the result of the authorities' own work and represent their unique body of knowledge. We currently distinguish the following categories of models:

• Metamodel

• Reference models
• Common (shared) models, including mandatory models
• Generalized (anonymized) examples
• Individual models

Some outputs of the architecture, such as standards for IS communication protocols or standards for benchmarking the performance of VS processes, will be binding across the whole public administration, while others will be binding, for example, only for state administration but not for local governments. Some parts of the content of the architecture will not be binding anywhere and will only be descriptive and recommendatory. Such a concept is called 'federative architecture' abroad and the obligations imposed by law are clearly visible in it.

In terms of generality, unity and purpose of the individual models, the content of the architecture will be divided into:

• Referential Models (RM) - expressing the generalization of best practices applied to the reality of Czech VS and the classification hierarchy of individual domains at the level of the whole national framework. At this level there are no specific architectural contents (neither As-Is nor To-Be). This layer is compulsorily referenced at the meta-level, i.e. it brings mandatory classifications and mandatory forms of model expression. In short, it is a reference classification and form of modeling.
• Shared (shared) content - models comprising those components of architectural models that organizations at different levels of government must or may share, or must implement identically. This layer is a mandatory and voluntary reference for the content of To-Be architectures and is a means of ensuring consistency of the overall To-Be architecture of a public administration. In short, it is the reference content of the architecture.
• Individual Models (IM) - the most important models in the authority's repository, i.e. custom models expressing the development concepts of individual VS organizations, created with methodological support from NAR, according to mandatory reference information in terms of form and content and in accordance with the National Architecture Plan (NAP) and its schedule.

All three forms and degrees of referability of the architectures are valid across all layers of the structure pyramid and all domains of the NA VS CR, as highlighted by the two icons on the right in each row of the diagram, see the following Figure.

The above structure of models is complemented by the so called modelling models - metamodels and for accelerating the implementation of EA, the highly desirable practical examples:

• Metamodel and Glossary of Terms - Definition Models (Model Models) are provided by this methodology and we anticipate that they will be maintained in each agency's model repository to inform the NAR methodology. However, this assumes that in addition to a binding metamodel, for the national exchange of models, it will be possible to extend the metamodels in each office by so-called specializations, see for example Architecture Content and Output Framework.
• Generalized examples - as successful pilot projects progress, more models and diagrams of sufficient quality will be added to serve as examples. These are individual models in nature, but will often be generalised, anonymised, so that the specific authority being modelled is no longer visible. These models are not binding on anyone, but serve to inspire as vehicles of practical experience. Such will be disseminated both centrally from OHA and communally between authorities.

Expressing changes in architectures over time and tracking the evolution of architectures from the intended state to its achievement is a difficult architectural task, conceived in TOGAF by two different schools of thought and not directly supported by any part of the ArchiMate specification.

TOGAF distinguishes in the metamodel between so-called Logical and Physical components for application and technology architecture, not so much for business architecture or data architecture. Logical components are generic, assumed, existing only intangibly as part of the concept. Physical components are concrete instances of logical components, they have names, vendors, versions, measurable attributes, etc.

In addition, TOGAF recommends dividing architectural knowledge into so-called building blocks, intended for reuse in designs and in reality. While Architecture Building Blocks (ABB) ))) prescribe what type of component (or function, service, etc.) is to be used for a type purpose, the Solution Building Block (SBB⁹⁾) shows how it is already specifically done and what can be reused.

The Architectural Building Block (ABB) can be primarily referred to as the so-called logical component, and the Solution Building Block (SBB) can be referred to as the physical component. This is more complicated for concepts (objects) where the TOGAF metamodel does not distinguish physical/logical.

The practice of the Czech public administration has shown the need to use architectural building blocks and solution building blocks together in models and diagrams of the authority architecture, even though the ArchiMate notation does not support this, only since version 3.0 it recommends to adapt its concepts to this approach by so-called specialization into stereotypes. The intent is to get both into the same diagrams so that their intended and actually achieved attributes can be compared with each other.

The NAR draft methodology thus turns in this part to the recommendations of the "Enterprise Continuum" according to TOGAF, initially for its vertical breakdown into ABB and the resulting SBB, without the ambition to classify from left to right according to the degree of generality¹⁰⁾.

It is recommended to look at ABB and SBB in three ways and to implement them in the model in three ways:

(1) using the stereotypes of ArchiMate core objects, especially for the application concepts that are subject to such classification,

(2) by using a set of attributes of these objects that are different for ABB (more general) and for SBB (more specific), whereby the same object (concept instance) may end up carrying both such sets (profiles),

(3) through a catalog, a list into which elements flagged as ABB or SBB can be filtered and their attributes shown clearly - i.e., an Enterprise Continuum listing.

ABBs correspond very closely to the "logical application components" listed in TOGAF, whereas SBBs are very much the same as "physical application components". According to TOGAF, they could be both in one model, but in ArchiMate this is not possible without "duplication", i.e. specialization of metamodel objects.

According to NAR, in one ArchiMate model (not just diagram), each "thing" existing in the reality of the office, e.g. an application component, must be listed only once, i.e. it is not permissible to capture a "box" for both ABB and SBB in one model. Therefore, we divide ABBs into two categories: candidate ABBs and generic ABBs.

• A candidate ABB is a precursor, a temporary representative of the target SBB in an individual model at a time when the supplier and its solution are not yet known. It represents a logical component until a physical one is available. Therefore, it can be part of the individual (sharp) office architecture model. It will change statuses during implementation and eventually this ArchiMate component will become an SBB, but will carry the previous ABB profile (there will be an opportunity for comparison).

The * Generic ABB is a template for multiple implementations (SBB) and/or to be visualized after implementation. Such a model element in ArchiMate can be modeled by a separate Box, but only in a reference architecture model, i.e. a separate model (package). Thus, in any application component inventory of an office from EAM repositories, both ABB and SBB will not "ride out". This will not (must not) give the false impression of a different number and structure of applications than the actual number and structure.

If necessary, it is possible to create a diagram, drawing objects from both models simultaneously, i.e. from the individual and the reference model, and thus to express graphically the necessary comparison.

In addition to using the building block concept from TOGAF for general architecture management, the NAP uses this concept in a narrower and more precise definition as eGovernment Building Block:

An eGovernment building block is a functional unit (or part thereof, as appropriate) that:

(a) provides central shared functions (as services) to all (multiple, many) eGovernment actors (participants), or to many other functional units; or

(b) represents a repeatable pattern of multiple unified local functional units

c) is always managed with central accountability (governance).

Each of the above slices or overviews of the Authority's architecture can be expressed in views, i.e. tables (Catalogues and Matrices) or graphs (Diagrams) at any level of detail.

In order to maintain backward compatibility to the initial modelling concept of the 2014 e2020 Consortium project and to avoid conceptual conflicts when using the reference models of this project, this chapter presents a modified explanation of the original so-called "Levels of Aggregation" L0, L1 and L2", adapted with respect to the TOGAF definitions, deliberately in a reversed order:

• L1 - Basic Authority Architecture View Level - a common view level of the relevant strategic, segment or capability architecture of the authority being modelled. The essence of the L1 level view is that it fulfils the basic purpose of the office architecture, i.e. it visualises all inventoried or projected future occurrences of certain concepts (elements) of the model and the links between them. Usually, however, in its entirety, it focuses on only a few selected concepts (metamodel elements) of the Authority Architecture. For example, application components, their services and interfaces.
• L0 - Overview level view of the authority architecture - the highest level view of the modelled authority as a whole. This level of view of the organization model is an expression of the principle or overview of the model. Its typical feature is that it highlights only the essential occurrences of certain concepts of the model and omits the less essential ones to emphasize the strategic principle. Alternatively, instead of visualizing specific occurrences (instances), it visualizes the principle (overview) using the superordinate classification categories of the reference models and using groups of objects.
• L2 - Detailed level Office Architecture Model View - The L2 level develops to even greater (full) detail by adding additional metamodel concepts and their attributes to the strategic, segment view but especially the capability view of the single holistic office architecture model. For example, in the application architecture, it adds application collaboration and multiple levels of internal application functionality.

The current methodology does not prescribe a mandatory level of detail for the diagrams; the above levels are only recommended pending practical validation by pilot projects. The practice of the pilot authorities shows that using different levels of detail for otherwise the same aspect (view definition) is still useful.

All and partial authority models must be developed and all architectural decisions made with an awareness of information about the architecture of the environment of which the authority is a part, i.e. in their context.

Very often, sub-segment and capability architectures or four-layer ISMS functional unit architectures (full-stack) will be modeled in the Authority. The levels, envelopes or shells of their contexts can be defined at the following levels:

• The context of the overall architecture of the actual VS office or organisation
• Context of the architecture of the public corporation (department, region, ORP), if the office is part of it, especially corporate shared services (and potential ones)
• Context of the architecture of the elements of the central shared services of the eGovernment of the Czech Republic
• Context of the architecture of the EU central shared services eGovernment elements
• Architecture context on the side of typical clients and partners in the delivery of public services.

Selected basic contexts for a common authority are graphically illustrated in the following Figure.

For an OSP in its role as a reporter of a delegated agenda, the architectural contexts of all the individual or type offices to which it delegates its competence are relevant. This is reflected in its so-called extended models (ROZS).

For each OVS that is the administrator of a self-service digital service, the context of the architectures of the type clients of that service is important.