Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
en:nap_dokument:pravidla_tvorby_a_udrzby_vlastni_ctyrvrstve_architektury_jednotlivych_uradu [2021/07/01 10:30] – Tomáš Šedivecen:nap_dokument:pravidla_tvorby_a_udrzby_vlastni_ctyrvrstve_architektury_jednotlivych_uradu [2021/08/17 15:04] (current) – Tomáš Šedivec
Line 1: Line 1:
 ====== Authority architecture in the context of public administration and its layers of architecture ====== ====== Authority architecture in the context of public administration and its layers of architecture ======
  
-This chapter describes the architecture of the office and the public administration of the Czech Republic by each layer of architecture and the incorporation of requirements into the information concept and architecture of the office. This is a different approach to describing the requirements for the use of eGovernment systems and services than in [[nap_document:rules_for_functional_units_architecture_of_individual_offices|Methods for the use of shared services, functional units and thematic areas of individual offices]], where requirements are described in the full breadth (throughout the architecture) of a shared service, functional unit or thematic area.+This chapter describes the architecture of the office and the public administration of the Czech Republic by each layer of architecture and the incorporation of requirements into the information concept and architecture of the office. This is a different approach to describing the requirements for the use of eGovernment systems and services than in [[en:nap_dokument:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Methods for the use of shared services, functional units and thematic areas of individual offices]], where requirements are described in the full breadth (throughout the architecture) of a shared service, functional unit or thematic area.
  
-The composition of this chapter corresponds to [[nap_document:introduction#National Public Administration Architecture domains|National Architecture domains]]+The composition of this chapter corresponds to [[en:nap_dokument:uvod#National Public Administration Architecture domains|National Architecture domains]]
  
-{{ nap-document:nap.png |}}+{{ nap-dokument:nap.png |}}
  
  
Line 35: Line 35:
  
  
-<WRAP centre round tip 60%>+<WRAP center round tip 60%>
 The incorporation of the rules of this architecture layer will be described by the Authority in its information concept. The incorporation of the rules of this architecture layer will be described by the Authority in its information concept.
 </WRAP> </WRAP>
Line 48: Line 48:
  
 <WRAP center round tip 60%> <WRAP center round tip 60%>
-The description of centrally provided systems and their services, functional units and thematic areas is described in [[nap_document:architecture_a_sdilene_sluzby_verejne_spravy_cr|Description of shared services, functional units and thematic areas of public administration in the Czech Republic]].+The description of centrally provided systems and their services, functional units and thematic areas is described in [[en:nap_dokument:architektura_a_sdilene_sluzby_verejne_spravy_cr|Description of shared services, functional units and thematic areas of public administration in the Czech Republic]].
  
-Rules for individual shared services, functional units and thematic areas are described in [[nap_document:rules_for_functional_units_architecture|Methods of use of shared services, functional units and thematic areas by individual authorities]].+Rules for individual shared services, functional units and thematic areas are described in [[en:nap_dokument:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Methods for the use of shared services, functional units and thematic areas of individual offices]].
  
 The incorporation of the rules of this architecture layer shall be described by the authority in its information concept. The incorporation of the rules of this architecture layer shall be described by the authority in its information concept.
Line 92: Line 92:
     * Operational functions - performed by the Authority as a management of essential resources to ensure its sustainable existence (operations), regardless of its core, support and shared resource functions.     * Operational functions - performed by the Authority as a management of essential resources to ensure its sustainable existence (operations), regardless of its core, support and shared resource functions.
  
-{{ nap-document:osnovni_deleni_funkci_process_service.png | Basic division of functions, processes and services of the Authority}}+{{ nap-dokument:zakladni_deleni_funkci_procesu_sluzeb.png | Basic division of functions, processes and services of the Authority}}
  
 The Authority Business Architecture Reference Model further divides the core functions for performing services mainly to external clients (citizens and representatives of organizations), but also to internal clients (authorities and officials) into: The Authority Business Architecture Reference Model further divides the core functions for performing services mainly to external clients (citizens and representatives of organizations), but also to internal clients (authorities and officials) into:
Line 105: Line 105:
  
  
-{{ nap-document:dalsi_deleni_process_function_service.png |Further division (classification) of functions, processes and services of the main area in the context of other functional areas}}+{{ nap-dokument:dalsi_deleni_procesu_funkci_sluzeb.png |Further division (classification) of functions, processes and services of the main area in the context of other functional areas}}
  
  
-=== Aspects of the degree (and potential) of displacement of functions and the use of shared services in place of individual functions ===.+=== Aspects of the degree (and potential) of displacement of functions and the use of shared services in place of individual functions ===
  
 Identified functions in the authority's business architecture model should be considered in terms of the availability of already shared business services or the potential for displacement (outsourcing) to the provider of such shared services - within the authority or local government unit by choice, elsewhere by law or regulation. Identified functions in the authority's business architecture model should be considered in terms of the availability of already shared business services or the potential for displacement (outsourcing) to the provider of such shared services - within the authority or local government unit by choice, elsewhere by law or regulation.
Line 151: Line 151:
 998-1-1-1 **Name** of the owner of the road vehicle. 998-1-1-1 **Name** of the owner of the road vehicle.
  
-The purpose of this notation, the notification of the agendas in the [[nap:rpp|Register of Rights and Obligations]] and the subsequent technological specification is to **uniquely separate legal and informational responsibilities.** Thus, when designing a publication via [[:nap:egsb|eGSB / ISSS]], the administrator of the agenda defines the legal division of contexts and data and the administrator of the respective agenda information system the subsequent informational division of these data. This partitioning then uniquely defines the item in the transmitted data record within the linked data pool and the management of access permissions to that item.+The purpose of this notation, the notification of the agendas in the [[en:nap:rpp|Register of Rights and Obligations]] and the subsequent technological specification is to **uniquely separate legal and informational responsibilities.** Thus, when designing a publication via [[en:nap:egsb|eGSB / ISSS]], the administrator of the agenda defines the legal division of contexts and data and the administrator of the respective agenda information system the subsequent informational division of these data. This partitioning then uniquely defines the item in the transmitted data record within the linked data pool and the management of access permissions to that item.
  
 Thus, the Agenda Information System Administrator must work with the Agenda Administrator to report the agenda so that an unambiguous decomposition of the data in context can be performed on a single information item. The definition of these information items is subsequently part of the data interface definition. Thus, the Agenda Information System Administrator must work with the Agenda Administrator to report the agenda so that an unambiguous decomposition of the data in context can be performed on a single information item. The definition of these information items is subsequently part of the data interface definition.
Line 157: Line 157:
 **The chosen principle avoids confusion of data by name (the name of the vehicle owner is certainly different from the name of the property owner, although both items are named name) and it is necessary to use the above numerical hierarchical notation in the design of all data interfaces.** **The chosen principle avoids confusion of data by name (the name of the vehicle owner is certainly different from the name of the property owner, although both items are named name) and it is necessary to use the above numerical hierarchical notation in the design of all data interfaces.**
  
-The agency administrator also determines, when notifying, which data from the basic registers or other agencies it is entitled to use in its activities, and the agency information system administrator then draws on the definition of data items of the individual ISVS that publish data/data to the [[nap:linked_datovy_fund|linked public administration data pool]] when designing the data interface.+The agency administrator also determines, when notifying, which data from the basic registers or other agencies it is entitled to use in its activities, and the agency information system administrator then draws on the definition of data items of the individual ISVS that publish data/data to the [[en:nap:propojeny_datovy_fond|linked public administration data pool]] when designing the data interface.
  
 **If an agenda is executed through multiple Agenda Information Systems, then the agenda manager must designate the Agenda Information System manager that will bind the decomposition of data into data items, and the other Agenda Information System managers must respect this decomposition.** **If an agenda is executed through multiple Agenda Information Systems, then the agenda manager must designate the Agenda Information System manager that will bind the decomposition of data into data items, and the other Agenda Information System managers must respect this decomposition.**
Line 175: Line 175:
   * According to the medium of communication and means of filing/delivery, in person - by writing a report, in paper form - by post, courier or at the registry office, and in electronic form - by data box, by electronically signed document in the electronic registry or in a specific application of the office (according to specific laws), or by the procedure described on the official board of the office.   * According to the medium of communication and means of filing/delivery, in person - by writing a report, in paper form - by post, courier or at the registry office, and in electronic form - by data box, by electronically signed document in the electronic registry or in a specific application of the office (according to specific laws), or by the procedure described on the official board of the office.
  
-The aim is to serve as many client needs as possible in the first level of service, i.e. in [[nap:universalni_kontaktni_misto|universal contact points]] (also referred to as "UKM") - client centres such as the self-service Client Portal (citizen, entrepreneur, organisation representative and foreigner) in PVS and assisted CzechPOINT. Specialised contact points of the authorities will continue to be available for the necessary individual services.+The aim is to serve as many client needs as possible in the first level of service, i.e. in [[en:nap:univerzalni_kontaktni_misto|universal contact points]] (also referred to as "UKM") - client centres such as the self-service Client Portal (citizen, entrepreneur, organisation representative and foreigner) in PVS and assisted CzechPOINT. Specialised contact points of the authorities will continue to be available for the necessary individual services.
  
 The starting assumption in the design of the solution should be to make every effort to ensure that the client can find the maximum available information about his/her contacts and procedures with the public administration within the UKM. The starting assumption in the design of the solution should be to make every effort to ensure that the client can find the maximum available information about his/her contacts and procedures with the public administration within the UKM.
  
-However, in the case of assisted contact points (both universal and in territorial or agency OVS), the information on all information on the relationship between the client and the public administration will be mediated by a civil servant, solely on the basis of explicit authorisation by the client. This is the only case where the clerk is allowed to see more than one agenda at the same time, but is only allowed to see status information from [[nap:notifications|notifications]], i.e. whether the client should pay attention to the agenda for some right or obligation. Based on such an overview, the client may instruct the clerk to handle each agenda for it one by one.+However, in the case of assisted contact points (both universal and in territorial or agency OVS), the information on all information on the relationship between the client and the public administration will be mediated by a civil servant, solely on the basis of explicit authorisation by the client. This is the only case where the clerk is allowed to see more than one agenda at the same time, but is only allowed to see status information from [[en:nap:notifikace|notifications]], i.e. whether the client should pay attention to the agenda for some right or obligation. Based on such an overview, the client may instruct the clerk to handle each agenda for it one by one.
  
 All actions in the service channels must be adequately recorded and logged in the transaction log of the relevant IS and in the office's filing service. All actions in the service channels must be adequately recorded and logged in the transaction log of the relevant IS and in the office's filing service.
Line 214: Line 214:
  
 <WRAP center round tip 60%> <WRAP center round tip 60%>
-The description of centrally provided systems and their services, functional units and thematic areas is described in [[nap_document:architecture_a_sdilene_sluzby_verejne_spravy_cr|Description of shared services, functional units and thematic areas of public administration of the CR]].+The description of centrally provided systems and their services, functional units and thematic areas is described in [[en:nap_dokument:architektura_a_sdilene_sluzby_verejne_spravy_cr|Description of shared services, functional units and thematic areas of public administration of the CR]].
  
-Rules for individual shared services, functional units and thematic areas are described in [[nap_document:rules_for_functional_units_architecture|Methods of use of shared services, functional units and thematic areas by individual authorities]].+Rules for individual shared services, functional units and thematic areas are described in [[en:nap_dokument:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Methods for the use of shared services, functional units and thematic areas of individual offices]].
  
 The incorporation of the rules of this architecture layer shall be described by the authority in its information concept. The incorporation of the rules of this architecture layer shall be described by the authority in its information concept.
Line 236: Line 236:
 Decision support in managing the life cycle of application components of the VS information systems and at the same time expressing the best practice of their inventory and classification is provided by the so-called Application Architecture Reference Model, which is the basis of the Authority's Application Map. Decision support in managing the life cycle of application components of the VS information systems and at the same time expressing the best practice of their inventory and classification is provided by the so-called Application Architecture Reference Model, which is the basis of the Authority's Application Map.
  
-{{ nap-document:rozdeleni_aplikacnich_komponent.png |Dividing the Authority's application components into layers}}+{{ nap-dokument:rozdeleni_aplikacnich_komponent.png |Dividing the Authority's application components into layers}}
  
 The division is based on the purpose of the application components from above, starting from the role of user interface and navigation to platforms, completely independent of the types of users and services provided by the Authority. In the application map, this division is applied as layers of vertical dimension. The division is based on the purpose of the application components from above, starting from the role of user interface and navigation to platforms, completely independent of the types of users and services provided by the Authority. In the application map, this division is applied as layers of vertical dimension.
  
-{{ nap-document:rpzdeleni_transakcnich_a_informacnich_komponent.png |Division of transactional and information (analytical) components}}+{{ nap-dokument:rpzdeleni_transakcnich_a_informacnich_komponent.png |Division of transactional and information (analytical) components}}
  
 Further, the division of applications is based on the business logic of the business functions supported, where on the one hand there are functions (services) for external clients, partners and the public, and on the other hand there are functions that support in detail the individual key resources of the authority (knowledge, staff, assets and inventory (and their suppliers), or entrusted registers). Further, the division of applications is based on the business logic of the business functions supported, where on the one hand there are functions (services) for external clients, partners and the public, and on the other hand there are functions that support in detail the individual key resources of the authority (knowledge, staff, assets and inventory (and their suppliers), or entrusted registers).
Line 248: Line 248:
 This implies a currently feasible requirement to optimize the processes and application portfolio of the authority by using unified or even central shared components of the authority's application portfolio for cross-cutting agency processes (e.g. for customer service at counters, portal self-service, on-site control management, receipt and matching of payments, etc.), transcription of names of persons from countries using a script other than the Latin alphabet) within its office, or central shared application services made available to it by law or regulation at a higher level of government (corporations, central eGovernment). This implies a currently feasible requirement to optimize the processes and application portfolio of the authority by using unified or even central shared components of the authority's application portfolio for cross-cutting agency processes (e.g. for customer service at counters, portal self-service, on-site control management, receipt and matching of payments, etc.), transcription of names of persons from countries using a script other than the Latin alphabet) within its office, or central shared application services made available to it by law or regulation at a higher level of government (corporations, central eGovernment).
  
-Where multiple components across agencies are shared in this way within an office, these use not AIFO for external client identification, but preferably some common public client number of the citizen and the organisation within the office's master data system. The AIFO, as a non-public identifier, will only be used when externally exchanging client data within an agency via a back-end integration through the [[nap:reference interface]].+Where multiple components across agencies are shared in this way within an office, these use not AIFO for external client identification, but preferably some common public client number of the citizen and the organisation within the office's master data system. The AIFO, as a non-public identifier, will only be used when externally exchanging client data within an agency via a back-end integration through the [[en:nap:referencni_rozhrani]].
  
 === Cross-cutting, IT and security services === === Cross-cutting, IT and security services ===
Line 258: Line 258:
 It is the responsibility of the Authority's CIO (Technical Administrator) to take into account the similarity of the applications to each other according to their category when deciding whether to consolidate applications or to design application support in categories where it is insufficient or lacking. It is the responsibility of the Authority's CIO (Technical Administrator) to take into account the similarity of the applications to each other according to their category when deciding whether to consolidate applications or to design application support in categories where it is insufficient or lacking.
  
-A reference model of the application architecture with full details of the classification and with different content of key transactional components for different segments of the public administration (e.g. health, insurance agendas, subsidy agendas, network infrastructure management, etc.) will be released in the following versions [[[:nap_document|NAP]].+A reference model of the application architecture with full details of the classification and with different content of key transactional components for different segments of the public administration (e.g. health, insurance agendas, subsidy agendas, network infrastructure management, etc.) will be released in the following versions [[en:nap_dokument|NAP]].
  
-{{ :nap-document:prurezove_it_sluzby.png | Cross-cutting, IT and Security Services}}+{{ :nap-dokument:prurezove_it_sluzby.png | Cross-cutting, IT and Security Services}}
  
  
Line 273: Line 273:
 First and foremost, user interfaces of ISVs and operational systems must be ergonomically optimal to best support appropriate user roles and their performance of external and internal government functions. First and foremost, user interfaces of ISVs and operational systems must be ergonomically optimal to best support appropriate user roles and their performance of external and internal government functions.
  
-  * The authority must have all its forms primarily in the authenticated zone of the [[nap:portaly_verejne_spravy_a_soukromopravnich_uzivatel_udaju|portal]] and allow pre-filling of data from the [[:en:nap:propojeny_datovy_fond|PPDF]] using [[nap:elektronicka_identification_pro_klienty_verejne_spravy|guaranteed client identity]]+  * The authority must have all its forms primarily in the authenticated zone of the [[en:nap:portaly_verejne_spravy_a_soukromopravnich_uzivatelu_udaju|portal]] and allow pre-filling of data from the [[:en:nap:propojeny_datovy_fond|PPDF]] using [[en:nap:elektronicka_identifikace_pro_klienty_verejne_spravy|guaranteed client identity]]
   * Agency and local portals will be expanded from informational to transactional   * Agency and local portals will be expanded from informational to transactional
-  * Transactional portal content (forms or portal application user interfaces) must be integrated (federated) with PVS - [[nap:portal_obcana|Citizen Portal]]  +  * Transactional portal content (forms or portal application user interfaces) must be integrated (federated) with PVS - [[en:nap:portal_obcana|Citizen Portal]]  
-  * If a legal regulation or the exercise of competence requires proof of identity, proof of identity using electronic identification may only be enabled through a qualified electronic identification system. This identification is currently only provided through the [[nap:nia|National Identity Scheme]]+  * If a legal regulation or the exercise of competence requires proof of identity, proof of identity using electronic identification may only be enabled through a qualified electronic identification system. This identification is currently only provided through the [[en:nap:nia|National Identity Scheme]]
  
 Except in exceptionally justified cases, such as modelling or GIS tools, or when sufficient Internet bandwidth is unavailable, no business logic shall be included in the user interface, but shall be available uniformly from the application servers for all types of AI used (local client, web client, mobile client). The reason for this is to facilitate uniform maintenance of business logic during constant changes (parameterization) of IS functions. Except in exceptionally justified cases, such as modelling or GIS tools, or when sufficient Internet bandwidth is unavailable, no business logic shall be included in the user interface, but shall be available uniformly from the application servers for all types of AI used (local client, web client, mobile client). The reason for this is to facilitate uniform maintenance of business logic during constant changes (parameterization) of IS functions.
Line 355: Line 355:
 Each office is obliged to consider in its architecture the acquisition of a solution for central management of identities and user permissions (also called IDM (Identity Management) or IAM (Identity & Access Management)) of the office and its integration with the personnel system of the office on the one hand and with the central unified identity space of the civil servants of the Ministry of Justice on the other hand (currently the JIP/KAAS solution). Each office is obliged to consider in its architecture the acquisition of a solution for central management of identities and user permissions (also called IDM (Identity Management) or IAM (Identity & Access Management)) of the office and its integration with the personnel system of the office on the one hand and with the central unified identity space of the civil servants of the Ministry of Justice on the other hand (currently the JIP/KAAS solution).
  
-  * Obligation to connect client identification and authentication to a qualified system, which is currently only [[nap:nia|NIA]] +  * Obligation to connect client identification and authentication to a qualified system, which is currently only [[en:nap:nia|NIA]] 
   * Obligation to link identification, authentication and authorization of officials to JIP/KAAS   * Obligation to link identification, authentication and authorization of officials to JIP/KAAS
   * Recommendation to implement a central identity management of the office (IDM), linked for officials to HR (HCM)   * Recommendation to implement a central identity management of the office (IDM), linked for officials to HR (HCM)
Line 372: Line 372:
 The preferred way of integrating applications is to use a standard integration platform (also Enterprise Application Integration, hereinafter also referred to as "EAI", or synonym Enterprise Service Bus, hereinafter also referred to as ESB), which replaces the P2P integration of the authority and provides functions for, in particular, asynchronous integration (not waiting for a confirmation of the entry into the database or a response), queue handling, logging, etc. The preferred way of integrating applications is to use a standard integration platform (also Enterprise Application Integration, hereinafter also referred to as "EAI", or synonym Enterprise Service Bus, hereinafter also referred to as ESB), which replaces the P2P integration of the authority and provides functions for, in particular, asynchronous integration (not waiting for a confirmation of the entry into the database or a response), queue handling, logging, etc.
  
-Each authority will use its own or shared EAI connected to a central [[[:nap:egsb|eGSB / ISSS]].+Each authority will use its own or shared EAI connected to a central [[en:nap:egsb|eGSB / ISSS]].
  
 In line with the NAP, these rules assume a multi-tier hierarchical structure of integration platforms. In line with the NAP, these rules assume a multi-tier hierarchical structure of integration platforms.
  
-A central integration platform [[[:nap:egsb|eGSB / ISSS]] is built for the involvement of authorities in sharing within the interconnected data pool. The authorities preferably connect to it via the corporate integration platforms of the ministries (regions, ORP) or via their own EAI, if they have one.+A central integration platform [[en:nap:egsb|eGSB / ISSS]] is built for the involvement of authorities in sharing within the interconnected data pool. The authorities preferably connect to it via the corporate integration platforms of the ministries (regions, ORP) or via their own EAI, if they have one.
  
 The corporate EAI serves primarily for internal integration needs within the chapter or public corporation, as an external integration for the department or subdivision office, and as a shared service for subordinate organizations of the corporation for which it is not convenient to build an EAI of their own. The corporate EAI serves primarily for internal integration needs within the chapter or public corporation, as an external integration for the department or subdivision office, and as a shared service for subordinate organizations of the corporation for which it is not convenient to build an EAI of their own.
Line 413: Line 413:
  
 <WRAP center round tip 60%> <WRAP center round tip 60%>
-The description of centrally provided systems and their services, functional units and thematic areas is described in [[nap_document:architecture_a_sdilene_sluzby_verejne_spravy_cr|Description of shared services, functional units and thematic areas of public administration in the Czech Republic]].+The description of centrally provided systems and their services, functional units and thematic areas is described in [[en:nap_dokument:architektura_a_sdilene_sluzby_verejne_spravy_cr|Description of shared services, functional units and thematic areas of public administration in the Czech Republic]].
  
-Rules for individual shared services, functional units and thematic areas are described in [[nap_document:rules_for_functional_units_architecture|Methods of use of shared services, functional units and thematic areas by individual authorities]].+Rules for individual shared services, functional units and thematic areas are described in [[en:nap_dokument:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Methods for the use of shared services, functional units and thematic areas of individual offices]].
  
 The incorporation of the rules of this architecture layer shall be described by the authority in its information concept. The incorporation of the rules of this architecture layer shall be described by the authority in its information concept.
 </WRAP> </WRAP>
  
-<WRAP centre round info 60%>+<WRAP center round info 60%>
 The IS VS data architecture is formally part of a single layer together with the application architecture. Here they are described separately because of the emphasis on the work and rules for the system and the work and rules for the data/data they work with. The IS VS data architecture is formally part of a single layer together with the application architecture. Here they are described separately because of the emphasis on the work and rules for the system and the work and rules for the data/data they work with.
 </WRAP> </WRAP>
Line 438: Line 438:
 Any ISVS that contains any data holdings is required to provide (the ISVS administrator must): Any ISVS that contains any data holdings is required to provide (the ISVS administrator must):
  
-  - **Reference -** identify all subjects/objects held in the basic registers (natural persons - ROB, legal entities - ROS, address points and other territorial elements - RUIAN) and start receiving [[nap:notifications|notifications]] of changes to data on these subjects/objects both from the basic registers and from other agency sources.+  - **Reference -** identify all subjects/objects held in the basic registers (natural persons - ROB, legal entities - ROS, address points and other territorial elements - RUIAN) and start receiving [[en:nap:notifikace|notifications]] of changes to data on these subjects/objects both from the basic registers and from other agency sources.
   - **Unambiguity -** split the data pool into parts   - **Unambiguity -** split the data pool into parts
     - **Reference data** - must be consistent with the basic registers     - **Reference data** - must be consistent with the basic registers
Line 460: Line 460:
 All the data managed in the IS of the Authority, constitute the so-called **data pool of the Authority**. The basic existential (static, card catalogue) data on subjects (clients, suppliers, employees, etc.) and on public administration objects (registered vehicles, cultural monuments, livestock, property of the authority, etc.) constitute the so-called **data trunk of the authority**, or its master data. On the other hand, data on procedures (operations, actions) with or over public administration objects are called **transaction data of the authority**. Trunk and transactional data are the two most important components of the Authority's data holdings; other categories of data are presented below. All the data managed in the IS of the Authority, constitute the so-called **data pool of the Authority**. The basic existential (static, card catalogue) data on subjects (clients, suppliers, employees, etc.) and on public administration objects (registered vehicles, cultural monuments, livestock, property of the authority, etc.) constitute the so-called **data trunk of the authority**, or its master data. On the other hand, data on procedures (operations, actions) with or over public administration objects are called **transaction data of the authority**. Trunk and transactional data are the two most important components of the Authority's data holdings; other categories of data are presented below.
  
-A fundamental requirement of the information concept in terms of classification of data in public administration is the introduction of the concept of **agenda data**. Currently, the concept of reference data is already introduced in the Basic Registers Act (Section 2). An agency data has a similar data quality when it is used, but its quality and guarantee is guaranteed by its provider, which in most cases is [[nap:agendovy_model_verejne_spravy|agenda notifier]]. This includes, for example, data relating to drivers, vehicles, education of natural persons, qualifications of natural or legal persons to carry out activities according to the law (doctor, educational institution, accreditation centre, etc.).+A fundamental requirement of the information concept in terms of classification of data in public administration is the introduction of the concept of **agenda data**. Currently, the concept of reference data is already introduced in the Basic Registers Act (Section 2). An agency data has a similar data quality when it is used, but its quality and guarantee is guaranteed by its provider, which in most cases is [[en:nap:agendovy_model_verejne_spravy|agenda notifier]]. This includes, for example, data relating to drivers, vehicles, education of natural persons, qualifications of natural or legal persons to carry out activities according to the law (doctor, educational institution, accreditation centre, etc.).
  
 Applying the above principles, the data held in the data pool of the public administration information system (agenda), and collectively in the data pool of the authority, can be divided in several respects. The primary aspect is the classification of data objects in terms of responsibility for their validity, see above under **uniqueness.** Applying the above principles, the data held in the data pool of the public administration information system (agenda), and collectively in the data pool of the authority, can be divided in several respects. The primary aspect is the classification of data objects in terms of responsibility for their validity, see above under **uniqueness.**
Line 485: Line 485:
 The basic tool for the management of data objects about subjects and objects of law contained in the agenda data trunk is the Register of Rights and Obligations. When declaring an agenda, it is necessary to list the data maintained in the agenda according to Act 111/2009 Coll. on Basic Registers, § 51 (5) (h). These documents are used for the notifiers of other agendas who register a request for the use of these data according to point j) of this provision. The basic tool for the management of data objects about subjects and objects of law contained in the agenda data trunk is the Register of Rights and Obligations. When declaring an agenda, it is necessary to list the data maintained in the agenda according to Act 111/2009 Coll. on Basic Registers, § 51 (5) (h). These documents are used for the notifiers of other agendas who register a request for the use of these data according to point j) of this provision.
  
-The RPP maintains information on the data provided and used in this way from a legislative point of view, i.e. as specified in the relevant legislation. From a technical usage point of view, the ISVS administrator that provides the data via [[:nap:egsb|eGSB / ISSS]] is then required to publish the corresponding technical regulation as an XML template within the WSDL of the usage regulation of the published services [[:nap:egsb|eGSB / ISSS]].+The RPP maintains information on the data provided and used in this way from a legislative point of view, i.e. as specified in the relevant legislation. From a technical usage point of view, the ISVS administrator that provides the data via [[en:nap:egsb|eGSB / ISSS]] is then required to publish the corresponding technical regulation as an XML template within the WSDL of the usage regulation of the published services [[en:nap:egsb|eGSB / ISSS]].
  
-Thus, from a technical point of view, the binding prescription is how data is published for use on the [[nap:reference_interface|Basic Registry Information System and eGSB/ISSS]] interface. This unifies the reference interface of the public administration and ensures a clear technological presentation of legal concepts in terms of the data transmitted.+Thus, from a technical point of view, the binding prescription is how data is published for use on the [[en:nap:referencni_rozhrani|Basic Registry Information System and eGSB/ISSS]] interface. This unifies the reference interface of the public administration and ensures a clear technological presentation of legal concepts in terms of the data transmitted.
  
 At the same time, it is **not** foreseen that data can be exchanged between public administration information systems outside the reference interface. At the same time, it is **not** foreseen that data can be exchanged between public administration information systems outside the reference interface.
Line 522: Line 522:
  
   * The administrator (of the agenda) registers the data with the Register of Rights and Obligations as agenda data   * The administrator (of the agenda) registers the data with the Register of Rights and Obligations as agenda data
-  * Controller publishes the data within the selected context with a link to the subject/object via [[:nap:egsb|eGSB / ISSS]]+  * Controller publishes the data within the selected context with a link to the subject/object via [[en:nap:egsb|eGSB / ISSS]]
   * The administrator publishes changes to the agenda data   * The administrator publishes changes to the agenda data
   * The administrator accepts complaints about the state of the agenda data   * The administrator accepts complaints about the state of the agenda data
   * The agenda using the agenda data registers this request in the Rights and Obligations Register   * The agenda using the agenda data registers this request in the Rights and Obligations Register
-  * Agenda uses the data via [[[:nap:egsb|eGSB/ISSS]]+  * Agenda uses the data via [[en:nap:egsb|eGSB/ISSS]]
   * If the agenda stores this data in its data pool, it keeps it in compliance by subscribing changes   * If the agenda stores this data in its data pool, it keeps it in compliance by subscribing changes
   * If, during the operation of the agenda, a doubt is detected about the correctness of the data, then it notifies the data controller   * If, during the operation of the agenda, a doubt is detected about the correctness of the data, then it notifies the data controller
Line 533: Line 533:
  
   - If these data are not used in large quantities within an agenda, then the most efficient and secure use of them is based on online queries at the time of need. The data is then not permanently stored in the agenda data, but only the shape of the data retrieved at the time of the query and in the context of the purpose.   - If these data are not used in large quantities within an agenda, then the most efficient and secure use of them is based on online queries at the time of need. The data is then not permanently stored in the agenda data, but only the shape of the data retrieved at the time of the query and in the context of the purpose.
-  - If these data are used by the agenda in large quantities, or if there is a risk of delay in the event of unavailability of central systems, then it is efficient to maintain a local copy of the reference and agenda data on the subjects and objects of the agenda for the purposes of its execution. In this case, systematic maintenance of this data is absolutely necessary so that it is **consistent** with the data held in the underlying registers and agenda sources. To this end, it is necessary to use the [[nap:notification|notification]] process to change and update the data on the subjects and objects for which the change has been notified.+  - If these data are used by the agenda in large quantities, or if there is a risk of delay in the event of unavailability of central systems, then it is efficient to maintain a local copy of the reference and agenda data on the subjects and objects of the agenda for the purposes of its execution. In this case, systematic maintenance of this data is absolutely necessary so that it is **consistent** with the data held in the underlying registers and agenda sources. To this end, it is necessary to use the [[en:nap:notifikace|notification]] process to change and update the data on the subjects and objects for which the change has been notified.
  
-The principle of [[nap:notification|notification]] is fundamentally of the **pull** type and without passing data during [[nap:notification|notification]]. Thus, the agenda using the data requests a list of subjects or objects for which the data has changed in the past period (typically one day). It then uses this list to actively query the data source to retrieve data according to its permissions. This ensures that during [[nap:notifications|notifications]] no data can be passed that the agenda does not have permission to. At the same time, when querying a natural or legal person, an entry is created in the basic registers and the right holder concerned is informed that the agenda has updated the data about him in its data stem.+The principle of [[en:nap:notifikace|notification]] is fundamentally of the **pull** type and without passing data during [[en:nap:notifikace|notification]]. Thus, the agenda using the data requests a list of subjects or objects for which the data has changed in the past period (typically one day). It then uses this list to actively query the data source to retrieve data according to its permissions. This ensures that during [[en:nap:notifikace|notifications]] no data can be passed that the agenda does not have permission to. At the same time, when querying a natural or legal person, an entry is created in the basic registers and the right holder concerned is informed that the agenda has updated the data about him in its data stem.
  
-In case the OVS uses more than one own (local) agency information system and uses reference and agency master data, a local master data management solution must be implemented which, after the initial identification, keeps the agency master data up-to-date by receiving [[nap:notifications|notifications]] from the PPDF and does not burden the [[:en:nap:propojeny_datovy_fond|linked data pool]] with continuous on-line queries. Personal data obtained in this way is stored outside other agency information systems and is only used by individual systems when necessary. This ensures the separation and security of personal data with unquestionable auditing of access to personal data.+In case the OVS uses more than one own (local) agency information system and uses reference and agency master data, a local master data management solution must be implemented which, after the initial identification, keeps the agency master data up-to-date by receiving [[en:nap:notifikace|notifications]] from the PPDF and does not burden the [[:en:nap:propojeny_datovy_fond|linked data pool]] with continuous on-line queries. Personal data obtained in this way is stored outside other agency information systems and is only used by individual systems when necessary. This ensures the separation and security of personal data with unquestionable auditing of access to personal data.
  
  
Line 569: Line 569:
   * Elements defined by logical data schemas distributing the dataset whose semantics are significant must be linked to the concepts of the semantic vocabulary of terms in order to harmonize the semantics of the dataset according to the designated OFN published on POD.   * Elements defined by logical data schemas distributing the dataset whose semantics are significant must be linked to the concepts of the semantic vocabulary of terms in order to harmonize the semantics of the dataset according to the designated OFN published on POD.
   * In the case of duplication of published datasets or addition of data by different publishers to the same published entity, links to already published data in the VDF must be added. The obligation to complete the links falls on the publisher who publishes the additional data.   * In the case of duplication of published datasets or addition of data by different publishers to the same published entity, links to already published data in the VDF must be added. The obligation to complete the links falls on the publisher who publishes the additional data.
-  * For each dataset published to the VDF, information about the [[nap:notification|notification]] mechanism of changes according to the corresponding OFN listed on the POD shall be provided.+  * For each dataset published to the VDF, information about the [[en:nap:notifikace|notification]] mechanism of changes according to the corresponding OFN listed on the POD shall be provided.
   * The OSP publishing the dataset must ensure and guarantee the availability of the dataset distribution in an open and machine-readable format for all OSPs using it in the execution of their agendas.   * The OSP publishing the dataset must ensure and guarantee the availability of the dataset distribution in an open and machine-readable format for all OSPs using it in the execution of their agendas.
   * The administrator of the ISVS from which the dataset is obtained is responsible for the factual correctness of the content of the dataset. This means that it is responsible for:   * The administrator of the ISVS from which the dataset is obtained is responsible for the factual correctness of the content of the dataset. This means that it is responsible for:
Line 601: Line 601:
   * Be described in terms of content up to the level of data elements in the public administration information system up to the level of data elements. The data element corresponds to the spatial data class in geographic information systems.    * Be described in terms of content up to the level of data elements in the public administration information system up to the level of data elements. The data element corresponds to the spatial data class in geographic information systems. 
   * Publish spatial data sharing services    * Publish spatial data sharing services 
-  * Spatial data elements that are related, similar or identical to [[nap:ruian|RUIAN]] elements shall contain the [[nap:ruian|RUIAN]] element identifier (e.g. digital technical map buildings, address locations of properties affected by the agenda, etc.).+  * Spatial data elements that are related, similar or identical to [[en:nap:ruian|RUIAN]] elements shall contain the [[en:nap:ruian|RUIAN]] element identifier (e.g. digital technical map buildings, address locations of properties affected by the agenda, etc.).
  
  
Line 611: Line 611:
   - Linked data pool   - Linked data pool
     - Reference data from basic registers (using [ISZR services])     - Reference data from basic registers (using [ISZR services])
-    - Data published by the agencies and their AISs (used [[:nap:egsb|eGSB / ISSS]])+    - Data published by the agencies and their AISs (used [[en:nap:egsb|eGSB / ISSS]])
   - Public Data Pool   - Public Data Pool
     - Public registers and lists published in a way that allows remote access)     - Public registers and lists published in a way that allows remote access)
Line 620: Line 620:
  
 <WRAP center round tip 60%> <WRAP center round tip 60%>
-The description of centrally provided systems and their services, functional units and thematic areas is described in [[nap_document:architecture_a_sdilene_sluzby_verejne_spravy_cr|Description of shared services, functional units and thematic areas of public administration of the Czech Republic]].+The description of centrally provided systems and their services, functional units and thematic areas is described in [[en:nap_dokument:architektura_a_sdilene_sluzby_verejne_spravy_cr|Description of shared services, functional units and thematic areas of public administration of the Czech Republic]].
  
-Rules for individual shared services, functional units and thematic areas are described in [[nap_document:rules_for_functional_units_architecture|Methods of use of shared services, functional units and thematic areas by individual authorities]].+Rules for individual shared services, functional units and thematic areas are described in [[en:nap_dokument:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Methods for the use of shared services, functional units and thematic areas of individual offices]].
  
 The incorporation of the rules of this architecture layer shall be described by the authority in its information concept. The incorporation of the rules of this architecture layer shall be described by the authority in its information concept.
Line 653: Line 653:
  
  
-PaaS and IaaS [[nap:egovernment_cloud|eGC services]] can be used to replace any service at the technology layer of the authority's architecture, or the internal implementation of a given service ("function" in terms of the architectural model) can be replaced by a PaaS or IaaS service. PaaS and IaaS [[nap:egovernment_cloud|eGC services]] will be subject to at least the same architectural requirements as on-premise platforms. For [[nap:egovernment_cloud|eGC services]] and on-premise, the security requirements corresponding to the security impact assessment level of the ISVs using these platforms shall be the same.+PaaS and IaaS [[en:nap:egovernment_cloud|eGC services]] can be used to replace any service at the technology layer of the authority's architecture, or the internal implementation of a given service ("function" in terms of the architectural model) can be replaced by a PaaS or IaaS service. PaaS and IaaS [[en:nap:egovernment_cloud|eGC services]] will be subject to at least the same architectural requirements as on-premise platforms. For [[en:nap:egovernment_cloud|eGC services]] and on-premise, the security requirements corresponding to the security impact assessment level of the ISVs using these platforms shall be the same.
  
 The practical use of PaaS and IaaS services is expected mainly in the form of groups of services corresponding to the operational platform of a specific ISVS or operational information system, or a clearly defined part of it (e.g. web front-end), either at the level of a fully managed technology platform including OS management (PaaS) or at the level of virtualised computing and disk resources (IaaS), which the Authority will manage in-house or using third party services. From an eGC perspective, the use of PaaS services is preferred to achieve a higher level of efficiency. The practical use of PaaS and IaaS services is expected mainly in the form of groups of services corresponding to the operational platform of a specific ISVS or operational information system, or a clearly defined part of it (e.g. web front-end), either at the level of a fully managed technology platform including OS management (PaaS) or at the level of virtualised computing and disk resources (IaaS), which the Authority will manage in-house or using third party services. From an eGC perspective, the use of PaaS services is preferred to achieve a higher level of efficiency.
Line 668: Line 668:
  
 <WRAP center round tip 60%> <WRAP center round tip 60%>
-The description of centrally provided systems and their services, functional units and thematic areas is described in [[nap_document:architecture_and_sdilene_sluzby_verejne_spravy_cr|Description of shared services, functional units and thematic areas of public administration of the CR]].+The description of centrally provided systems and their services, functional units and thematic areas is described in [[en:nap_dokument:architektura_and_sdilene_sluzby_verejne_spravy_cr|Description of shared services, functional units and thematic areas of public administration of the CR]].
  
-Rules for individual shared services, functional units and thematic areas are described in [[nap_document:rules_for_functional_units_architecture|Methods of use of shared services, functional units and thematic areas by individual authorities]].+Rules for individual shared services, functional units and thematic areas are described in [[en:nap_dokument:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Methods for the use of shared services, functional units and thematic areas of individual offices]].
  
 The incorporation of the rules of this architecture layer shall be described by the authority in its information concept. The incorporation of the rules of this architecture layer shall be described by the authority in its information concept.
Line 676: Line 676:
  
  
-KIVS/CMS is a system whose primary purpose is to provide a controlled and registered connection of information systems of state and local government entities to services (applications) provided by information systems of other state and local government entities with defined security and SLA parameters, i.e. access to eGovernment services. KIVS/CMS can thus be called a private network for the performance of public administration on the territory of the state. KIVS/CMS as a private network of public administration uses dedicated or leased network resources for secure interconnection of public administration officials (PIAs) working in public administration agencies with their remote agency information systems, for secure network interconnection of agency systems with each other and for secure access of individual PIAs to the Internet.+KIVS/CMS is a system whose primary purpose is to provide controlled and registered interconnection of information systems of state and local government entities to services (applications) provided by information systems of other state and local government entities with defined security and SLA parameters, i.e. access to eGovernment services. KIVS/CMS can thus be called a private network for the performance of public administration on the territory of the state. KIVS/CMS as a private network of public administration uses dedicated or leased network resources for secure interconnection of public administration officials (OVS) working in public administration agencies with their remote agency information systems, for secure network interconnection of agency systems with each other and for secure access of individual OVS to the Internet. 
 + 
 +OVS and SPUUs access eGovernment services, such as [[en:nap:propojeny_datovy_fond|connected-data-fund,]] exclusively via CMS in one of four possible ways:
  
-Connection to the CMS can be implemented via:+  - Through the Regional Networks (currently in the Vysočina, Pilsen, Karlovy Vary, Zlín and partly Pardubice regions + others if built).  
 +  - Through [[en:nap:metropolitni_site|metropolitan networks]] connected e.g. to the [[en:nap:its|Integrated Telecommunication Network (ITS) of the MVČR]].  
 +  - Through the Communication Infrastructure of Public Administration (KIVS) using commercial offers competed through the Ministry of the Interior.  
 +  - Via the public Internet, via a secure VPN SSL or VPN IPSec tunnel.
  
-  * Non-public KIVS operator (Regional networks, Metropolitan networks, ITS of the Ministry of Interior and others) +If the Authority wishes to use the KIVS, i.e. to compete through the central contracting authority of the Ministry of the Interior, it is necessary to define the requirements in accordance with [[https://www.mvcr.cz/clanek/komunikacni-infrastruktura-verejne-spravy-278660.aspx|catalogue sheets]] and then implement the purchase in the dynamic purchasing system. CMS services can also be used via [[en:nap:narodni_datova_centra|National Data Centres]].
-  * Public KIVS operator (KIVS operator competition through the central contracting authority of the Ministry of the Interior) +
-  * IPsec VPN +
-  * SSL VPN+
  
-Only the first 2 options - Non-public and public KIVS operator - are allowed for OSS, thus communication between individual OSS is conducted exclusively via KIVS/CMS, i.e. individual OSS are obliged to access public administration information systems (ISVS) only via KIVS/CMS.+Only variants 1 to 3 are admissible for the Public Procurement Service (PPA), so that communication between the PPAs is conducted exclusively via the KIVS/CMS, i.e. the individual PPAs are obliged to access the Public Administration Information Systems (ISVS) only via the KIVS/CMS.
  
 With the exception of the so-called operational information systems, which are listed in Section 1(4)(a) to (d) of Act No 365/2000 Coll., on public administration information systems (ZoISVS), Section 6g(3) of this Act imposes an obligation on the administrators of ISVS to provide public administration information system services through the CMS. Public administration bodies are obliged to use the electronic communication networks of the CMS by means of Section 6g(4) ZoISVS. With the exception of the so-called operational information systems, which are listed in Section 1(4)(a) to (d) of Act No 365/2000 Coll., on public administration information systems (ZoISVS), Section 6g(3) of this Act imposes an obligation on the administrators of ISVS to provide public administration information system services through the CMS. Public administration bodies are obliged to use the electronic communication networks of the CMS by means of Section 6g(4) ZoISVS.
  
-As the services of the so-called [[nap:reference_interface|reference interface]], as defined in § 2(j) of ZoISVS, are published through the CMS, the obligation imposed in § 5(d) of ZoISVS, i.e. the obligation of ISVS administrators to ensure that the links of the ISVS they administer to the ISVS of another administrator are made through the CMS, is also related to the CMS.+As the services of the so-called [[en:nap:referencni_rozhrani|reference interface]], as defined in § 2(j) of ZoISVS, are published through the CMS, the obligation imposed in § 5(d) of ZoISVS, i.e. the obligation of ISVS administrators to ensure that the links of the ISVS they administer to the ISVS of another administrator are made through the CMS, is also related to the CMS.
  
 In view of the characteristics of the CMS, as well as the legal aspects described above, it may also be added that the use or non-use of the CMS is a relevant factor for assessing the fulfilment of the related legal obligations, in particular the obligations in the field of cyber security or protection of personal data, as well as the obligation of sound and economic management of public funds and the obligation to prevent damage. In view of the characteristics of the CMS, as well as the legal aspects described above, it may also be added that the use or non-use of the CMS is a relevant factor for assessing the fulfilment of the related legal obligations, in particular the obligations in the field of cyber security or protection of personal data, as well as the obligation of sound and economic management of public funds and the obligation to prevent damage.
Line 727: Line 729:
 ==== Clerk's view ==== ==== Clerk's view ====
  
-{{ :nap-document:egov_4_client_overview_ur.png |}}+{{ :nap-dokument:egov_4_prehled_klient_ur.png |}}
  
 ==== Client view - legal entities ==== ==== Client view - legal entities ====
  
-{{ :nap-document:egov_4_client_overview_po.png |}}+{{ :nap-dokument:egov_4_prehled_klient_po.png |}}
  
 ==== Client view - natural persons ==== ==== Client view - natural persons ====
  
-{{ :nap-document:egov_4_client_overview_fo.png |}}+{{ :nap-dokument:egov_4_prehled_klient_fo.png |}}