Modelling Authorities and their Architectures

The key to determining the scope of modeling authority architectures is to determine who is modeling, i.e., which organization, what part of the organization, and for what purpose.

The following section Structure of modelled architectures explains what types of models and their domains, with what level of binding according to the purpose of use, can be modelled. This chapter presents perspectives and approaches to properly allocate and manage the responsibility for architecture creation in OVS.

Determining the scope of the modelled authorities ====

The NAR ground rule states that individual (real) architectures are modeled principally and exclusively for an authority, the OVS, at any level of the public sector hierarchy. The exceptions are the possibilities of using the office architecture methodology for modeling:

• separate key central shared information systems of the eGovernment of the Czech Republic,
• selected key elements of the EU architecture such as common processes, services and application or platform components at EU level
• architecture on the general (type) public administration client side. This is not an individual, but a type-based, reference model.

In terms of the methodology for modelling the enterprise so-called authority architecture, an authority refers to any public sector entity that draws public funds, is authorised to provide public services (or similar and business activities) on behalf of the state with expenditure from the state budget, or in its own name and on its own account, and makes decisions on the use of public funds¹⁾). Mostly, the authority means public authorities, in particular central administrative authorities and the organisational units of the state and state contributory organisations established by them, or local self-government units and contributory and commercial organisations established by them.

Each office of the State Government of the Czech Republic will create up to three separate models of individual (real) architecture, of different scope (scope) in terms of the size of the modelled enterprise. This is in case it proves necessary that these models of different scope and purpose can exist and be shared separately. Each of the Authority models created and maintained, and each of the model-derived artifacts²⁾ will have to be classified by just one of the three classification values of the Authority model scope, namely:

• VLST - Own Office Architecture Model (OVS)
• SPOL - Shared model of the Authority and all organisations controlled (and methodically led) by it (department, regional corporation, etc.)
• ROZS - Extended model with elements from cooperating organizations, authorities, anywhere in the public administration system (or private sphere).

The larger scale models (SPOL and ROZS) will partially adopt some elements of the smaller scale model (VLST) and will also adopt elements of models from subordinate or cooperating agencies and other organizations. How the control (governance) of the multi-modelled elements will be technically ensured and how much support will be given to the reuse and sharing of already modelled elements will be specified after the pilot experience, but especially in the context of the project of building a central repository of models at the VS CR and according to its technical possibilities.

It is important that each model created for an office (OVS) is uniquely identified by the code of the VS organisation under which it is registered in the RPP, the so-called "OVS identifier", see https:%%//%%rpp-ais.egon.gov.cz/AISP/verejne/domu.

The full classification system of authority models and their views can be found in Reference models and classification frameworks.

The TOGAF methodology, on which the NA VS CR concept is consistently based, distinguishes three levels of enterprise architecture in each office (enterprise), they are:

• STR - Strategic Architecture
• SGM - Segment Architecture
• SCH - Capability Architecture

This structuring is valid and mandatory at all and at any level of authority (size, position in the hierarchy of the VS), from the level of the whole country to, for example, a sub-contributory service organization of a small town at the level of an ORP. However, it is permissible not to model a level if it does not correspond to reality (e.g. the organization does not have identifiable segments) or need (there is no manager to use the diagrams of the corresponding level). However, modeling architects must always know what level of the architecture they are at and classify models and artifacts accordingly.

The Strategic Architecture is characterized by always including the entire authority in the model (for VLST and SPOL, for example, with a limitation on the level of detail). The strategic architecture, true to its name, is used to strategically plan the development of the office and its IT (e.g. application and infrastructure roadmaps), always for the whole office or its entire responsibility for several years ahead.

The Segment Architecture is used to model the parts of the Authority (own or with controlled organisations) that share common mechanisms of operation or will be subject to common change (implementation of a strategic initiative, implementation of a new policy). For the purpose of segmenting the content of architectures within (enterprise) authorities of any size and level of government, several mutually orthogonal segmentation dimensions have been identified, the combination of which produces individual sub-segments. These segmentation dimensions are:

• Segmentation by category of public administration functions/processes
• Segmentation by group of public administration agencies
• Segmentation by public administration sector(s)
• Segmentation by size of public administration office

All of the identified architecture segmentations so far are relevant for the NA of the Czech Republic in particular in terms of defining segments of the public administration with similar characteristics in terms of (1) the creation and use of so-called Reference Models, Guidelines and Patterns containing segment best practices and (2) the creation and application of binding architecture standards, which may differ segmentally.

The various segmentation methods, except for agendas, are not mandated by law and do not have binding definitions or codes of acceptable values. Segmentation is still an internal (analytical) part of the architectural methodology and will be gradually refined according to the experience from pilot and follow-up projects. The classification for segmentation will be developed and published through a combination of NAR and NAP documents.

The Capability Architecture is a sub-architecture of the Authority, used to provide a more detailed understanding of an area of the Authority or a segment of the Authority, its group of external, or internal, agency (vertical) or cross-cutting (horizontal) capabilities. For example, the ability to assign and manage citizen identities, the ability to operate Authority properties, or the ability to manage documents, associated with any other core capability.

A capability architecture is most often developed in conjunction with some anticipated change identified in the higher-level architectures that needs to be developed into an opportunity and change plan at the authority architecture level before work can begin on finding a detailed architecture of possible solutions. This architecture is being developed at the level of the Authority and the service that is driving the change will fund, approve or project manage the implementation of the change, including its IT support. This level is created in all cases of project preparation as a basic enterprise architecture³⁾ to which the Capability corresponds and which the project develops/changes.

An example of a capability architecture is the enterprise architecture of a specific agenda, ERP or document management area, etc., very often also an EA associated with one ISVS.

A capability is not a core element of the architecture, but instead is the smallest part of the organization that has an architecture (structure and behavior) that can be explored and modeled.

Other (more detailed) architectures

In the overall pyramid of organization (office) architectures, these STR (Strategic), SGM (Segment) and SCH (Capability) levels of the office architecture are followed by the so-called Solution Architecture. )), describing the functioning of the solution sought and the so-called Solution Design )), describing the process of implementing the solution - introducing a process, programming or parameterizing an application, etc., see Structure of Modelled Architectures.

Each office must have (just) one approved model of its own strategic architecture (VLST; STR) and just one approved model of strategic architecture together with the controlled organizations (SPOL; STR). In addition, it will have an appropriate number (one or more) of segment and capability views for its own, joint and extended architectures. Depending on the allocation of responsibilities for the Authority's architectures, these non-Strategic Architecture views will be modeled as visualizations to one central Authority model or to several sub-models of the Authority, with different responsibilities and lifecycles.

Naturally, an authority may have many downstream solution architectures and solution design models. However, these are not covered by the NAR methodology.

Each of the above Authority Architecture slices can be expressed in artifacts - tables (Catalogs and Matrices) or graphs (Diagrams) at any level of detail. Previous version of the NAP 2014⁴⁾ used three levels of detail diagrams - overview, basic and detailed, see also Structure of modelled architectures, this logic will be maintained as additional as well.

In large corporate organizations such as ministries (budget chapters), regional corporations, or large cities, a number of people, often in different teams, will be responsible for different levels, domains, and segments of architectures. Naturally, there is a risk that their authorities and responsibilities will overlap or, conversely, not cover the entire need.

To provide governance and management⁵⁾ of these architectures, it is necessary to establish and keep up-to-date in the regulations of each authority the responsibilities of the departments, teams and individuals for the creation and maintenance of the individual architectural models and corresponding deliverables.

For each authority, the responsibilities for maintaining (editing, updating) the authority's architecture models and views are divided as follows, at least:

• who and what models themselves,
• for whom does the Authority's Architectural Office (AO) model?
• does everyone model their entire Authority's architecture, or is someone specifically assigned a particular segment or capability?

In order to capture these interrelationships of architectural models and deliverables in a federated structure, a governing model, the Corporation Architecture Model, must be created and is an integral part of it:

• A hierarchy of federated enterprise architectures.
• A matrix of responsibilities for each architecture, its models and artifacts.