Classification of models and views of the Czech Republic

Overview of dimensions of classification and segmentation of models and views

All architectural outputs - models, views and variants of these views must be classified according to a uniform set of attributes in the local repositories of the authorities and in the central architectural repository of the NA VS CR.

Whether access to the model in any repository is mediated in the menu or navigation by any combination (order) of the dimensions listed below, the model must always be mandatorily classified by all the attributes listed below, unless otherwise specified in the rules for any attribute. The linearized classification string of a model (view) may become a technical, coded part of its label.

VS organisations and their models are classified for the purpose of management and governance of the NA VS CR in the following groups of dimensions:

A) Classification of modelled (modelling) public sector entities
B) Classification of architectural models
C) Classification of model views

A special form of classification of authorities and their models is their:

D) Segmentation of authorities and models by similarity

The following is a list of the defined classification and segmentation dimensions in each group. A more detailed explanation of the dimensions, their origin and meaning and the values allowed for them can be found in the corresponding chapters of the overall concept of the NA VS CR methodology.

A) The classification of modelled (modelling) public sector entities is based on the following dimensions:

Classification of the modelling organisations according to their position in the public administration system (EU, central CR, central, regional, ORP, etc.).
Unique identification of the modelled (modelling) authority - OVM or enterprise or other public sector organisation according to the so-called organisation code from the OVM codebook in ISDS.
Dividing architectures according to the scope/relationships of the modelled organisations (own architecture, shared with controlled organisations and extended office architectures.

Authority attribute name	Attribute meaning	Attribute values
OFFICE	Offices in the structure of the Czech SS	EUN, CNT, KRJ, (PRG), (STM), ORP, OST, PRV, KLI, OVM
ORGANIZATION CODE	Unique organization code from OVM codebook	Organization code according to ISDS
RESOURCE	Office's own, common or extended architecture	VLST, SPOL, ROZS
ROZS_NAME	Extension Name	text

Each office may have only one single model of its own architecture (VLST) and one single model of a common architecture with subordinate organisations (SPOL). However, an office can have an unlimited number of "extended office" architectures depending on the purpose, so the attribute (ROZS) must always be accompanied by a name (NAME_ROSZ).

An example of a modeling organization classification, with values common to all combinations of model attributes and views, is given below.

Example 1: "KRJ KMORSLEZ ROZS_DOPRU" - Moravian-Silesian Region in the role of the modelling extended authority (in this case for the transport authority together with the Ministry of Transport).

Example 2: "ORP BENESOVMU SPOL" - Municipality of Benešov in the role of modelling the architecture of its office together with all subordinate organisations.

B) The classification of architectural models has the following dimensions:

Division of models (and their views) according to their role in the methodology of creation and use of NA VS CR (meta-model, reference models, model (mandatory) models, anonymized examples and especially individual models of offices).
Dividing models according to the level of detail and purpose of architectures (authority architecture - enterprise, solution architecture - solution and design solution).

The metamodel is a single, uniform and common for all authority architecture models (Enterprise Architecture) created within the NA VS CR. Therefore, it does not require any further classification according to the attributes in this chapter.

The implicit values "IM" and "EA" must be included in the model attributes, but are not expected to become part of their technical, code designation. Conversely, for specific types of models (other than IM) or models of more detailed architectures than EA, inclusion in the model code name is required.

Model attribute name	Attribute meaning	Attribute values
DRUH	Type (purpose, type) of model (metamodel, reference, model, example, individual, …) - individual is implicit and is not specified. Other generic codes are given instead of the organisation code.	MM, RM, VM, PM and IM
Level	Level of model in the hierarchy of enterprise architectures according to details (from English) - implicitly unlabelled is EA. The attribute will not be used, it will be replaced by the view attribute "purpose".	EA, SA, SD

Example of a model classification, always composed of a modeling authority classification and the model's own classification:

Example 1: "KRJ RM VLST" - denotes a reference model of a custom (small) architecture for organizations at the regional level of local government. However, it is not possible to deduce whether it is RM for regional authorities or some types of organisations established by them, this can only be known from the name of the model and the view.

C) The classification of models is followed by the classification (division) of views of the model:

Breakdown of views within the authority's model (enterprise) architecture by scope and purpose (strategic, segmented and capability).
Dividing the views according to the phases of the architectures they depict (past, current, target and transition-transition architectures)
Dividing by the domains of the model to which the view predominantly refers (motivational, business-process, IS - data and application, technology - IT technology and communications infrastructure, security or performance, implementation and migration architecture).
Applied point of view, or definition of the point of view according to the methodology of the NA VS ČR
Name of the viewpoint, refining and developing the information from the viewpoint.
Differentiation of the level of detail of view variants of the same viewpoint on the model (Overview - L0, Basic - L1 and Detailed - L2).

Name of view attributes	Attribute meaning	Attribute values

PURPOSE |Purpose |Partitioning of views within the office (enterprise) architecture model. The same attribute can also be used to express lower level architectures - Solution Architecture (SOL) and Solution Design (DES). |STR, SGM, SCH, SOL, DES |

Phase(Type, Year)	The relation of the view with respect to the timeline (past, present, future transition and target architectures). Period of intent of the architecture phase (expressing past, present or future AS2013, TB2020). Without specification, represents unknown past or target future at infinity.	ASrrr, TBrrr
Domain	Designation of the predominant domain (layer) of the model view (abbreviations from English)	BA, AA, DA, TA, IA, SA, PA, IM
VIEW ANGLE	Name (code) of the viewpoint type (viewpoint definition) - e.g. application catalogue, capability map, CRUD matrix, etc.	A viewpoint codebook will be created
viewpointname	model view name (specific instance), if needed	text
DETAIL	Detail measures of viewpoint variants of the same viewpoint	L0, L1 and L2

The relationship of the view to the predominant model domain is uniquely determined by the selected view type angle, so the view needs to be classified by the domain, but does not need to enter the view code designation.

Example: 'STR TB2020 AA APLMAP L0' represents a strategic, i.e. holistic application map type view of the application architecture in reduced detail (only selected principle instances of application components).

Overall, however, the above application map will be classified as follows:

- Full classification: "ORP BENESOVMU SPOL IM EA STR TB2020 AA APLMAP L0"

- reduced code classification: "_ BENESOVMU SPOL _ _ STR TB2020 _ APLMAPA L0", where the underscores indicate the locations of omitted (implicit and inferable) codes. In a real code label, these underscores would not appear and would have the following form: "BENESOVMU SPOL STR TB2020 APLMAPA L0".

D) Segmentation of offices by similarity and transferability of best practices, by dimension:

categories of public functions of the authority/company
groups of agencies and agendas
public administration/sector
size of public sector offices/enterprises

Segmentation is based on knowledge of the typical characteristics of the authority as a whole, but is most often evident when modelling its parts, from where it is fed back into the evaluation of the whole.

Each model must be classified according to all these attributes, indicating all identified values.

The segmentation of the models of the NA VS CR will start to be fully and compulsorily used only after the OHA MV releases the corresponding codebooks for use after pilot projects.

FUNCTIONS	According to the public sector functions used.	STAT, UZEM_SAMO, ZAEM_SAMO, ZAKON, JUDGMENT, V_SLUZ, V_PODNIK, etc.
AGENDA	Groups of agendas and agendas	According to the codebook created in connection with the RPP
SECTOR	Sectors of public administration	According to a specific codebook, such as (DOT, POJIST, INVEST, PROF_SLUZ, SCIENCE, etc.)
SIZE	Categories according to the number of employees of the authority, always up to …:	10, 50, 200, 1000, 5000, VICE

The search for authority segment affiliations is an aid to modeling, analysis and decision support, especially to identify potential areas of architecture to leverage known best practices, to unify and share.

The segmentation of the model content (multiple classification into segments) is not included in the coding; in the example of the SPOL architecture given, it would represent a very large chain.

In real architecture models (IM), segmentation expresses the characteristics of the model content, i.e. what segments have been identified in the organisation. On the other hand, for specific models, i.e. segmented RM-reference models, segmented VM-examples and segmented PM-examples, the title and the code designation of the model view should indicate which segments of the VS offices they are intended for, what Know-How or binding rules they contain.