Reference models and classification frameworks

It is not possible to compare and evaluate parts of architectures with each other unless we are sure that they always show the same thing, the same part of the office, the same type of component, the same category of processes, etc.

Without this, it is impossible to try to unify, consolidate, reduce, replace, etc. Classification of architectural elements is a prerequisite for all architectural decision making. Therefore, this chapter presents the concept of the National Classification Systems and the reference models based on them, which, in addition to the architectures of the central administrative authorities, are also valid for the architectures of the region or the ORP and their organisations.

In the current consulting practice aimed at improving the management of state and local government authorities in the Czech Republic, we encounter a double meaning and scope of the term "reference model":

• Reference Model of Integrated Authority Management System (RM ISM)- focuses on introducing and maintaining knowledge and practices from all interrelated methods of authority management.
• Reference Model for Authority Architecture (RM A)-also referred to as RM, is a model, accelerator and classification system according to best practices for authority architecture.

This architectural framework further addresses only the Authority Architecture Reference Models, which are, however, in practice a valuable starting point for building Integrated Management Systems Reference Models.

The Authority Architecture Reference Model should cover all the so-called Authority Domains and their corresponding layers and verticals of the architecture.

Classification systems and reference models cannot be created "off the shelf" but by generalising from experience gained through practice. And since no shared architectural experience exists in the Czech public administration yet, unlike abroad, the first versions of classification systems and reference models in the Czech Republic are created as a combination of foreign models, local completed or ongoing academic research, especially at the University of Economics, and pilot EA projects in public authorities of the Czech Republic.

Some of the earlier outputs of the e2020 Delivery Consortium (2014) are also one of the inspirational sources for future reference models.

Of the international sources, the most important are the New Zealand taxonomies, which further elaborate the current US public administration taxonomies. In addition to these are elements from the UK's VS reference architecture.

Due to the proximity of the Slovak Republic and the similar state of development of the two national VS architectures, the taxonomies and reference model of the Czech Republic will be developed in cooperation and with consideration of the Slovak experience.

Finally, due to the Czech Republic's EU membership and the need to become part of the European Interoperability Reference Architecture, EIRA will be ))) will be an important inspiration for those parts of the National Architecture that are specifically addressing interoperability issues. Other local reference models are not covered by EIRA.

More information, actual content and links to international reference models and taxonomies can be found in the Knowledge Base of the NSRN.

The e2020 project has produced many sets of diagrams, created 1:1 to the models, which is methodologically not quite correct. They should be different views (sections) of the consolidated models - one modeling unit is one model.

However, the models are currently the only available coherent set of architectural artefacts expressing the first idea of a significant group of architects of the e2020 delivery consortium about the target form of the Czech eGovernment architecture at the end of 2019. At the same time, they are the only available centrally conceived Czech architectural experience in the field of enterprise architecture of public administration.

The following groups of models can be considered as reference in the architectural sense, i.e. they can be used as a template for modelling local authority architecture, from the e2020 project outputs:

• Models of Central Administrative Authorities (CAA) - 8 models, two for each architecture layer (business, application, IT technology and infrastructure), of which 4 are indicative only (level 0) and 4 more precise (level 1). The combination of the two levels of detail represents to some extent the then proposed taxonomy of the UIS architecture.
• Models of regional governments, or just regional authorities (KRJs) - in the same structure as the UGS.
• Models of Statutory Towns and Municipalities with Extended Jurisdiction (STM and ORP) - in the same structure as the UGS, but twice essentially the same, with only minor variations.

These models contain a number of minor inconsistencies with each other and do not rely on any common component classification system. It is these groups of so-called reference models that have already been published on the OHA website and will continue to be part of the Knowledge Base of the NAR of the Czech Republic. A retrospective evaluation of the models against practice and the past eGovernment developments will lead to possible consideration of the experience and to their incorporation into further updates of the NAR reference models listed below and their adjustments for the individual levels of the hierarchy of the Czech public administration.

The National Architecture Framework seeks to create and update RMs for all vertical and horizontal domains of architecture. However, in the near term, only reference models for key Basic Architecture Layer Objects (BADTs) will be available, of which reference models BA and AA are already presented below. This should be followed by the RM of the technology layers, the RM of the data architecture and the RM of the strategic direction architecture.

This section focuses on RM business architectures, i.e., the architecture of government performance and office operations, which is hereafter abbreviated as RM-BA. The only domestic source of information for creating the RM sought is a set of presentations and models created as working versions in OHA. Partial experience from the pilot projects of the Ministry of Industry and Trade (2015), Moravian-Silesian Region (2017) and the City of Benešov (2018 - 2019) contributed to its creation.

The model is being developed gradually so that it will subsequently, after verification in the projects, become part of the National Architectural Plan and the basic process decomposition for the PMA3 project (Process Modeling of Agendas).

RM-BA of the Czech Republic was created in cooperation with other organizations, based on discussions with the University of Economics (Prof. V. Řepa, M. Zimmermannová), the non-profit organization CIEM (CIMAF¹⁾, R. Fišer) and with the National Network of Healthy Cities (P. Švec, J. Boušková).

This also implies that if there are not enough local resources, it is necessary to build a quality baseline reference model using foreign inspirations. For this RM, the process and functional decomposition models (reference classification) of local governments from the Netherlands and the USA and the reference model of state administration from New Zealand were used, which seem to be the most relevant.

• Divides the architecture by layers and domains in accordance with NAR (a combination of TOGAF, ArchiMate standards and the New Zealand Architectural Framework).
• In the BA layer, the focus is on classifying activities (behaviours), regardless of whether they are managed as functions only (from job descriptions), as processes (managed sequences of functions) or as services (managed process outputs).
• RM represents a reference (model) classification or taxonomy of the above elements. It also provides a visual reference (topology of diagrams - what is at the bottom/top, left/right).
• RM recognises that multiple reference classification systems can be developed, this one focuses on the classification of activities along the dimension from the provision of individual functions (services) for specific named clients on the one hand to basic operational activities on the other hand.
• Each of the reference models uses the same terminology of names for the classification levels:
  • Level 1 - Business (application, technical) Area
  • Level 2 - Business (application, technical) Category
  • Level 3 - business (application, technical) group

For a principle diagram of the top level of the VS CR business architecture reference model, see the following figure:

An example of another detailed breakdown of the classification can be operational processes. These have the characteristic that, apart from minor variations (different accounting schedule, the General Accounting Act, the Official Act, etc.), these functions, processes and internal services are no different from the same in any commercial or non-profit organisation. Therefore, it makes sense to adopt best practices from these organizations as well.

In the same process area, the next level of classification - business groups (functions, processes, services) - is also presented, due to the view already divided into two diagrams:

The BA reference model can gradually be refined in even greater detail with the support of pilot projects and offer a reference classification also for the processes (functions or services) of individual business groups, as presented here for the Municipal Property Management group using the example from the Benesov Study project.

In the model and graphical representation of the identified decomposition levels 3 to 5, the following objects were chosen:

• Level 3 - Process (Function) Group - ArchiMate Group object
• Level 4 - Process or function (in this case function) - ArchiMate Function object
• Level 5 - Subprocess, activity (in this case a subfunction) - Function object.

The Group classification object is expressed in the following two diagrams, unlike all of the above diagrams, in traditional graphical notation as a "file card". This is to emphasize the difference between the last level of (abstract) classification and the first level of executive functions.

The following figure presents a summary reference model of the business architecture of public administration in the variant for the city (municipality). With only a small effort of the pilot authorities, RB-BA can also be adapted to the reality of a region, a central administrative authority or a budget chapter.

So far, the only localized reference model available for the application architecture of the NA VS CR is available for the classification and visualization of the application portfolio map, broken down by application purpose. It is a reference model developed at the VŠE, which, with the exception of the UK-RA model mentioned above, does not have a UK-RA²⁾, has no comparable equivalent in the world.

All other models categorise applications according to the way they are acquired (purchase, development) or the type of technical solution rather than according to their purpose, for example the CORA model. The two views of the application portfolio can be combined, depending on the content of the questions currently being asked and the decisions to be made over the architectural models.

The following requirements have been placed on the application architecture reference model being sought:

• It must group applications by business purpose and user usage to support decision making for application components in the same classification to consolidate or replace them or establish them where they are missing for business purpose.
• It must make sense at any level of detail (hierarchy) of the application classification, this apparent sense must be understandable to the business users of the reference model and the individual models derived from it.
• It must be applicable, after modifications, in all segments and at all levels of the public administration hierarchy.

The reference model has been developed as a set of principles, example images, classification hierarchy and ArchiMate language template. The current version of the model, see below, is designed as a generic model for public administrations, rather focused on segments of offices with large client tribes and bulk client service processes. NAR and NAP anticipate creating clones of the model for other segments of government, such as those focused on project-oriented line infrastructure management and others.

The first level of decomposition according to RM-AA provides a division of the application portfolio according to two basic dimensions, vertical and horizontal. The vertical dimension of the model divides the application architecture according to the degree of proximity of the applications to the user, his needs and the management of the organization into so-called layers, which correspond to a breakdown from technical integration to user interaction. The model consists of six layers:

The horizontal dimension is a breakdown of applications according to their role in supporting the organization's value chain. In simple terms, it says that on the far left are applications supporting the execution of activities, recording and communication of information related to external entities, on the far right are applications supporting the recording of internal resources and activities with them, in the middle are applications that connect these two worlds, for example, accounting and logistics in ERP in the transactional (IV) layer, or reporting and decision support in the analytical (III) layer.

The horizontal breakdown is particularly applicable to applications with significant business content, i.e., the transactional and information layers, where it is emphasized, as shown in the following figure.

In the model, the application areas and categories are framed by concepts corresponding to the main concepts (Business Objects) that are the subject of record in enterprise information systems and at the same time are part of the enterprise environment with which the systems interact. In the generic model, these are the three key categories of external stakeholders: owners, customers and suppliers, and the three basic enterprise resources: knowledge, employees and assets (technology). In the model for public administration, suppliers are shifted from left to right because public administration organisations do not (yet) consider suppliers as partners in value creation and public service delivery, but rather consider them as an external resource.

At the core of the model are the middle two key layers of transactions and knowledge that directly support the delivery of the authority's functions, processes and services. They are further broken down by horizontal dimension into core activity areas ranging from the execution of external activities (public service delivery) to the management of the Authority's resources. The aim of these two layers is to cover a comprehensive (E2E³⁾) value creation scenarios, i.e. to cover all five key areas of the RM business architecture decomposition, see the following Figure, just arranged differently.

Transactional operations generate a wealth of data that is used to support decision making (middle), further complement the knowledge of the authority along with documents (right) or present information to owners, politicians and the public (left). Together they form a layer of knowledge and decision support.

Below the transactional layer is a layer of generic, cross-cutting IT and security services that are usually not associated with a single, exclusive business and application function, but serve many of them (identities and permissions, monitoring, office suite, archiving, mapping applications, etc.).

The bottommost layer consists of the application software of the different platforms, integration, mobile, communication and others, used to run and connect applications.

Conversely, above the layers for transaction processing and information handling is a layer for orchestrating services from the individual information silos into individual user interfaces, also called the composite layer or platform.

The top layer, closest to the users, consists of every imaginable form of user interface, from the traditional heavy client, to the browser, to mobile applications, to the so-called Internet of Things or smart clothing. That is, anything that is capable of making lower-layer application services available to the user.

The division of applications into domains, categories and groups is of great importance for determining the management rules of each application. More information about the architectural rules for each application architecture area and category can be found in the NAP document.

When considering the application of reference models, for example in this section for RM-AA, the overall application architecture model consists of repeating patterns, called "fractals", only smaller or larger depending on where in the organizational hierarchy the reference model is applied.

Some public administration organizations are corporate in nature (typically ministries, counties or municipalities) and provide some of their functions and applications to other organizations within the corporation. Each of the separate units in this hierarchy should apply and adapt the application architecture reference model presented above for its own IT management and according to its own situation.

Then each of the units higher in the hierarchy will have two models. One elementary (individual, IND), covering the IT support of its own processes, and the other aggregate (joint, SPOL), including in itself at the appropriate places in the model, in addition to its own applications, also applications occurring in subordinate or managed units. Symbolically, this is shown in the following diagram, see the following figure, in which the aggregate models at different levels of the public administration architecture are presented. In the left green part of the transaction area it is indicated that each higher (common) model also contains all applications registered in the lower model.

Higher-level models can then be used, for example, to make decisions about application architecture consolidation (unification) and the use of shared services, either mandatorily for units where the decision-making authority of the higher unit reaches, or voluntarily if the higher unit offers the lower one application domain coverage under more favorable conditions that consolidation and centralization should enable.

From each organisation's perspective, whether it owns the application is not critical to its inclusion in the application map. What is important is that the application need from a particular domain is covered by a solution of certain qualities, whether it is owned by it (modelled as an application component), shared horizontally with a partner organisation, or taken over from a superior unit (modelled as an application service).

/Not yet defined at the level of the NA VS CR. ==== IT Technology Architecture Reference Model ==== /Not yet defined at the level of the NA VS CR.

/Not yet defined at the level of the NA VS ČR. ==== Reference model of strategic direction architecture ==== Not yet defined at the level of the NA VS ČR.