Introduction

The Information Concept of the Czech Republic (also referred to as "IKČR" or "Information Concept of the Czech Republic") is a basic document which sets out, on the basis of the authorisation under Section 5a(1) of Act 365/2000 Coll., on public administration information systems, the objectives of the Czech Republic in the field of public administration information systems (also referred to as "ISVS") and general principles for the acquisition, creation, management and operation of public administration information systems in the Czech Republic for a period of 5 years.

In the follow-up document No. 1: Methods of ICT management of public administration in the Czech Republic, the ICCR defines the rules, including the bodies and roles responsible for their application, throughout the ICT service lifecycle of public administration information systems, i.e. it defines the rules of strategic IT management, planning, preparation and implementation of ICT projects, operation of ICT services, management of the economy and security of ICT services, and the rules of control and audit (governance) of ICT. In this annex, the ICCR also defines the basic requirements for the management and development of public authorities and their IT services so that they are better able to meet the objectives of the development of public administration information system services and manage their life cycle.

In order to implement these objectives effectively, the ICCR introduces the National Architecture of the Public Administration, the National Architectural Framework and the National Architectural Plan of the Public Administration as a means of describing the architecture of public administration bodies and the architecture of public administration information systems and as basic tools for formulating the objectives and principles of the Information Concept of the Czech Republic and the information concepts of individual public administration bodies and for managing the implementation of changes in accordance with these concepts.

In the follow-up document No. 2: Glossary of eGovernment terms, the ICCR introduces a uniform interpretation of terms and their possible synonyms from current legislation and practice, which are needed as one of the tools for coordinated eGovernment development according to the National Architectural Plan and for coordinated management of public administration informatics.

In the follow-up document No. 3: National Architecture Framework (NAR, this document), IKCR introduces a methodology for modelling, maintaining and using the description of the architecture of public administration bodies.

In the follow-up document No. 4: National Architectural Plan (NAP), the ICCR provides public administration authorities - administrators of information systems - with a clear and concrete idea of what the informatics of the public administration will look like in a specified horizon of 5 years, which elements of the informatisation of the public administration will be central and shared, which local elements must be uniform according to the submitted models and which may be arbitrary, their interrelations and continuity while observing the established architectural principles.

Public administration bodies shall develop their information concept and other documents according to the ICCR and its follow-up documents.

Tom Graves: "Things work better when they work together for a purpose."

Rather than managing the individual sub-activities of authorities and their information systems separately, with blinders on, so to speak, a new approach is needed to enable responsible managers, with the help of analysts, to see the authority as a holistic socio-economic-technical system that has a structure of elements, their links and behaviour (i.e. an architecture), and in which all "things" are interrelated.

For the Authority, this implies the need to know and describe its architecture using the procedures and means set out by NAR and to make decisions about its further development in line with the ICCR and the NAP. Practically, this means, for example, having and using transparent and shared models instead of excel.

This document contains a description of the methodology for the creation and management of architecture models of any public administration office of the Czech Republic (OVS, public administration body) and, appropriately to the different nature of activities, also of any state, national or self-governing enterprise or organisation.

The original term Enterprise Architecture. )) has been replaced by the term Authority Architecture for the purposes of public administration, but the original meaning has been retained. Wherever this material refers to Authority Architecture, other organisations and enterprises may imagine Enterprise Architecture accordingly.

The purpose of this document is to provide architects in offices and organizations with a broad knowledge base and guidance on how to model office architecture so that all of the individual office models that emerge complement each other and collectively form the National Architecture (NA) and the National Architecture Plan of the VSD.

The document is a starting point for further methodologies and recommendations such as "How to do it?", which in a narrower sense will provide practical guidance, for example, on how to model the architecture of the authority for the creation of the Information Concept of the authority or for the request for the opinion of the OHA (according to Government Resolution No. 86 of 27 January 2020 and Act No. 365/2000 Coll. )).

The purpose of the methodology in a broader sense is to be a starting point for modelling office architectures for any use in planning and development of office services and their information support.

In order to develop all public administration capabilities and skills, including the development of digital VS services, it is essential to manage public administration as an interconnected complex system of services provided by public authorities, with an overview and in an overall context¹⁾. As most of the transformation steps of the state, as with enterprise corporations, are currently only enabled by ICT, the overall architecture of public authorities, their agencies and public corporations, is both a means of developing and managing transformational change and a means of managing and developing ICT to support that change over the long term.

In the TOGAF standard (from The Open Group Architecture Framework, the international architectural framework on which the NA VS CR methodology is based. )), "architecture" has two complementary meanings depending on the context (The Open Group, 2018):

1. A formal description of a system or a plan for a system at the level of its elements, as a guide for its implementation
2. The structure of the elements, their interrelationships, and the principles and guidelines governing their design and evolution over time.

The following are NAR VS CR's own definitions:

Architecture of public administration as a socio-economic-technical system is a set of elements that form the structure of the system, their interrelations, their behavior (functioning) and the principles and rules for their design and development over time.

and simultaneously:

Authority Architecture (EA²⁾)) as a management method is a medium for a holistic understanding of the organization to support decision-making, especially in planning strategic changes, but also to support performance management, quality and accountability.

It provides a description of the structure and behaviour of the authority (who we are), planned changes (where we are coming from and where we are going) and their information support (what ICT as a whole and individual public administration information systems are and should be for).

The introduction of the so called National Architecture of Public Administration (NA) and the National Architecture Plan for its Development (NAP) through the subsequent documents of the IKCR is based on the need to systematically describe the current and future state of the architecture of the VS so that its description supports the management of VS reforms and changes in its ICT support.

The National Architecture of the Czech Republic (NA) is a collection of architectures and descriptions of the architecture of all individual public administration offices, including all central shared eGovernment elements.

The National Architecture Plan (NAP) will consist of a description of the current state of individual public administration offices and central eGovernment elements ("As-Is" - as is. )), a description of the proposals for their target state³⁾, the resulting difference, i.e. the scope of the expected changes and the roadmap of how these changes will be implemented⁴⁾.

The NAP is also a set of architectural data (models) and diagrams, maintained jointly by OHA and each OVS, broken down into:

• Office Architectures
• Shared Services Architectures.

A common name, National Architecture Plan (NAP), will be used for all models and other documents describing the current and target National Service Architecture and the journey towards it.

For the description of the VS architecture, the NA VS environment will contain guidelines, procedures, templates and patterns for the creation, maintenance and use of the architecture description, i.e. the National Authority Architecture Framework⁵⁾. The architecture framework contains advice for:

• Describing the architecture: how to capture the different images of the architecture according to the needs of the stakeholders.
• Architecture creation method: a cycle of architecture creation, divided into phases, organized by domains, with different outputs.
• Organization of the architecture team: what should be the structure of the team, its skills, knowledge, management and control.
• The organization of the architectural repository: in the interrelationship of the repository office and the CR level.

The National Architecture Framework (NAR), as a methodological and conceptual framework for a unified and coordinated description of the National Architecture of the CR, contains guidelines, procedures, templates, and patterns for the creation, maintenance, and use of the architecture description.

The National Architecture Framework is based on the internationally recognised standards for the creation and maintenance of authority architectures, TOGAF (The Open Goup Architecture Framework). )) and ArchiMate, managed by The Open Group⁶⁾ and used as a starting point for public administration architecture in most countries.

NAR will issue and update an OHA that will coordinate the creation and updating of NAP components in accordance with NAR, and ensure their central storage and presentation of selected NAP knowledge, i.e. for example models and action plans of each OSS, in a common knowledge base and NAP portal.

Other basic concepts are defined in many chapters of this document. Abbreviations, terms and definitions and in the subsequent document IKCR No. 2 - Glossary of eGovernment terms.

This first chapter provides basic explanations of the document.

1. Chapter 2 - Modeling Offices and their Architectures defines what units and parts of offices and public administrations as systems are subject to architecture modeling, especially in terms of responsibility for the creation, maintenance and use of the architecture. In particular, it says who models.
2. The Chapter 3 - Structure of modelled architectures defines the abstractions, categories, concepts and levels of detail used to model the different parts of an authority's architecture. In particular, it tells you what is being modelled.
3. Chapter 4 - Architecture Creation Process - defines how architecture models are created, maintained and used, with what steps and tools. In particular, it tells how the architecture is managed.
4. Chapter 5 - Frame of content and output of architectures - defines in what language, i.e. in what terms and symbols, the elements and links of the architecture are expressed, and by what outputs the outputs of the architecture description of the authority are presented. In particular, it is therefore stated how and what is modelled.
5. Chapter 6 - Reference models and classification frameworks - defines how to facilitate and unify the creation of models and diagrams using shared so-called reference models, generalising best practice from authority architectures. In particular, what reference models are and how they are used are discussed.
6. Chapter 7 - Guidelines and techniques for architecture creation - defines guidelines, serving as a guide for adapting the architectural framework to the conditions and needs of a specific authority, and techniques, representing instructions and tools for the sub-processes of architecture creation and maintenance. Thus, in particular, how to adapt and facilitate the creation of architecture is addressed.
7. The Chapter 8 - Architectural Skills, Departments and Organs defines what knowledge, personnel and organisational capabilities are necessary for an authority to be able to create, maintain and use a description of its architecture to support decision-making. In particular, it states what are the necessary pre-requisites (resources) for the management and governance of the architecture.
8. Chapter 9 - Architectural repository and tool - defines what and how structured ICT support facilities for the governance processes and the use of its architecture the authority must have. In particular, it tells what tools are needed for modelling.

The IKCR is binding on all state authorities and local authorities (also referred to as "authorities"⁷⁾))) - the latter, including public corporations, consisting, in addition to themselves, of contributory and commercial organizations established by them, according to Article 1, paragraph 1 of Act No. 365/2000 Coll, on Public Administration Information Systems, as amended, is collectively referred to as public administration bodies (also referred to as "PIS"). The NAR is a follow-up document of the ICCR, which develops the principles, principles and objectives guided therein and is binding on authorities to the extent of compliance with the principles, principles and objectives of ICCR.

Other public authorities (also referred to as "OBAs") that are not OBAs (e.g. schools or hospitals) are not bound by the ICCR (and thus its annexes, including the NAR), but their use of it can bring a number of benefits, i.e. its use is recommended.

The National Architecture Framework will be continually updated by OHA based on developments in ICT architecture management and feedback from its users.

The NAR material builds on and is in line with the legislation and strategic materials of the Czech Republic in the area of digital transformation of public administration of the Czech Republic to eGovernment and the area of long-term management of informatics and information systems in public administration of the Czech Republic.

Some of the provisions of the Digital Czech Republic - Information Concept of the Czech Republic and its follow-up documents, including this, are yet to be reflected in the corresponding amendments to the relevant implementing regulations.

The proposed methodology is based on two basic pillars used in the design of modern ICT Architecture:

• TOGAF - is an internationally recognized framework for guiding the creation of Enterprise Architecture in companies using information technology resources. The original concept originated in the USA, but has been used for more than a decade all over the world, including the Czech Republic. The official documentation of the TOGAF standard (The Open Group, 2018) can be found at http://pubs.opengroup.org/architecture/togaf9-doc/arch/index.html.
• ArchiMate - is an independent graphical modelling language. It is maintained by the Open Group consortium, which has declared ArchiMate as the standard for describing Enterprise Architecture. General standards for modeling in ArchiMate (The Open Group, 2017) are available at http://pubs.opengroup.org/architecture/archimate3-doc/toc.html.

As a methodology for architecture creation, maintenance, and use, the NAR methodology is a repeatable guide in any organization, describing the relevant processes to a given architecture lifecycle. The starting point for its design is the TOGAF framework, or the part of it describing the ADM cycle processes. These processes are expected to be tailored to the organisation in documents such as this. It tells us what we create and when we create it. In other words, it places a requirement for the creation of the different levels of architecture (e.g. business architecture, application architecture and data architecture), i.e. the deliverables relevant to each phase. The output of each phase must be recorded. A common means of communication, or modelling language, needs to be defined for easy understanding.

A suitable candidate is the ArchiMate modelling language. It is devised in such a way that it can represent the key phases of the TOGAF ADM cycle i.e.: phase B (business architecture), phase C (information systems architecture - data and application architecture) and phase D (technology architecture). Some areas of the TOGAF ADM cycle are not included in the ArchiMate language. This is understandable because TOGAF is a framework and has a much broader scope than ArchiMate, which is an architecture modeling language. The continuity is shown schematically in the figure below.

The questions for the causes of architectural change are answered by the so-called Motivational Extension of ArchiMate, which corresponds to phase A (architectural vision) and part of phase B (business architecture) of the TOGAF ADM cycle.

There is also an ArchiMate Implementation and Migration Extension area that corresponds to the TOGAF ADM phases. Namely, these are phase E (opportunities and solutions), phase F (migration planning) and phase G (governance implementation).

Currently, the Strategy and Physical Architecture layer elements have been added to the ArchiMate language in version 3.0, which do not have a direct counterpart in TOGAF, but complement its objects appropriately and NAR is actively working with selected ones.

More on the basic principles of the TOGAF architectural framework methodology and the ArchiMate architectural modeling language in the corresponding chapters and appendices.

TOGAF is a generic, technology-independent framework that is intended for use in a variety of environments. This makes it flexible and extensible, and it can be used on its own or complemented by other standard frameworks such as ITIL, COBIT and PRINCE2.

NAR, like TOGAF, is ready to be implemented in individual OVSs with a high degree of adaptation to any complementary methods already established and proven in the office, such as project management, change management or quality management.

The authors of the subsequent ICD documents anticipate that examples of NAR integration to other standard (centrally consistent) management methods, such as project management, will also be issued in their subsequent updates as they emerge.

For more information see also the document Methods of ICT management in the Czech Republic.

Authority architecture as a management method plays a key role especially in the different stages and phases of transformational change management, as presented in the following Figure below.

The overall knowledge of the authority, gained through EA, is a prerequisite for the creative processes of formulating the authority's own strategy.

Subsequently, the established strategic direction must be elaborated into a concrete idea of feasible changes, in the form of a target architecture of the office and an implementation plan of projects to achieve it.

Once transformation projects have been successfully implemented, knowledge of the Authority's architecture is also very useful for effective operational management mechanisms (e.g. service management) and continuous quality improvement.

Relationship between TOGAF and ITIL

The Information Technology Infrastructure Library (ITIL, a CSN/ISO 20000 standard) is a framework for IT service management. The basic principle of ITIL is based on the management of the IT service lifecycle and the management of the value that information technology delivers to customers - i.e. the purchasers of IT services. ITIL contains a set of practice-proven concepts and procedures.

Repositories to support ITIL-led processes, including configuration management, are related to the TOGAF architectural repository (predominantly in the area of Requirements Management) and should complement each other. The architecture created using the TOGAF framework provides inputs to ITIL processes and uses their outputs.

Binding of TOGAF and COBIT

Control Objectives for Information and related Technology (COBIT) is a framework for IT Governance. It is a set of practices that should enable the achievement of an organisation's strategic objectives through the efficient use of available resources and minimisation of IT risks. COBIT has been adapted in its fifth version to be fully compatible with TOGAF, ITIL and PRINCE2, thus creating an umbrella framework.

COBIT covers most of the activities defined by the TOGAF framework. It directly defines the Enterprise Architecture Management process within the planning and organisation framework, thus linking the two frameworks. COBIT further enriches the activities of the TOGAF framework by:

• relates them to general IT objectives and accompanying metrics,
• adds architecture-specific process objectives and accompanying metrics,
• defines responsibilities for TOGAF activities in the form of a Responsibility Assignment Matrix (RACI).

COBIT puts TOGAF in context by linking architecture processes to other organizational processes, change management projects, and ICT service delivery.

Linking TOGAF and IT4IT

The IT4IT framework has been developed by major IT companies, members of The Open Group, to support the management of IT governance processes. This framework has been developed using the resources of TOGAF and ArchiMate and focuses on the taxonomy and classification of application components and their functions needed to support all IT governance best practices, including EA itself. For more information on IT4IT's application capabilities in public administration, see Methods for managing ICT VS and the NA Knowledge Base.

Relation of TOGAF and PRINCE 2, PMBoK and other programme and project management frameworks.

Authority architecture management and project change management are two completely inseparable management disciplines, absolutely necessary for the successful implementation of defined transformational change strategies.

NAR in a number of passages envisages the use of project management both for the actual architectural tasks (engagements) and, naturally, for managing the delivery of defined packages of work on the way to the target architecture.

In those POCs where the project management profession is not sufficiently mature and underpinned by a recognized standard, NAR offers the minimum necessary project-oriented activities. Conversely, where project management is well established, NAR transparently leaves these tasks to the appropriate method in use. Targeted NAR should be complemented and linked to the National Methodology for Project Management in Public Administration.

Linking TOGAF and CAF, EFQM, TQM, 6Sigma and other quality frameworks

NAR, like TOGAF, is primarily aimed at supporting the identification and implementation of major transformational change. But along with these and following their implementation come issues of operational management, managing smaller changes, quality, performance, sustainability and continuous improvement. Therefore, NAR supports the introduction of change management and quality management methods such as the above and is prepared to adapt and build on them where they are already successfully implemented in the Authority.

Quite similar to the quality management method frameworks is the relationship between office architecture and performance management.

Simply put, it is necessary to identify, name, know and understand well everything that needs to be improved in the Authority, the quality and performance of which is to be managed. This is exactly what the office architecture, complemented by other, more detailed methods such as process modelling, rule management or service management, will do.