Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | |||
en:nap_dokument:pravidla_tvorby_a_udrzby_vlastni_ctyrvrstve_architektury_jednotlivych_uradu [2021/08/17 14:29] – [IS VS Physical and Communication Infrastructure Rules] Tomáš Šedivec | en: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: |
- | 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: |
- | {{ nap-document:nap.png |}} | + | {{ nap-dokument:nap.png |}} |
Line 35: | Line 35: | ||
- | < | + | < |
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. | ||
</ | </ | ||
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: |
- | Rules for individual shared services, functional units and thematic areas are described in [[nap_document:rules_for_functional_units_architecture|Methods | + | Rules for individual shared services, functional units and thematic areas are described in [[en:nap_dokument: |
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), | * Operational functions - performed by the Authority as a management of essential resources to ensure its sustainable existence (operations), | ||
- | {{ 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), | The Authority Business Architecture Reference Model further divides the core functions for performing services mainly to external clients (citizens and representatives of organizations), | ||
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' | Identified functions in the authority' | ||
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: | + | The purpose of this notation, the notification of the agendas in the [[en:nap: |
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/ | * According to the medium of communication and means of filing/ | ||
- | 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 " | + | 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 " |
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]], | + | 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]], |
All actions in the service channels must be adequately recorded and logged in the transaction log of the relevant IS and in the office' | All actions in the service channels must be adequately recorded and logged in the transaction log of the relevant IS and in the office' | ||
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: |
- | Rules for individual shared services, functional units and thematic areas are described in [[nap_document:rules_for_functional_units_architecture|Methods | + | Rules for individual shared services, functional units and thematic areas are described in [[en:nap_dokument: |
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' | 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' | ||
- | {{ nap-document: | + | {{ nap-dokument: |
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: | + | {{ nap-dokument: |
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' | 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' | ||
- | Where multiple components across agencies are shared in this way within an office, these use not AIFO for external client identification, | + | Where multiple components across agencies are shared in this way within an office, these use not AIFO for external client identification, |
=== Cross-cutting, | === Cross-cutting, | ||
Line 258: | Line 258: | ||
It is the responsibility of the Authority' | It is the responsibility of the Authority' | ||
- | 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: | + | {{ :nap-dokument: |
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 [[: | + | * 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 [[: |
* 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: | + | * Transactional portal content (forms or portal application user interfaces) must be integrated (federated) with PVS - [[en:nap: |
- | * 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: | + | * 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: |
Except in exceptionally justified cases, such as modelling or GIS tools, or when sufficient Internet bandwidth is unavailable, | Except in exceptionally justified cases, such as modelling or GIS tools, or when sufficient Internet bandwidth is unavailable, | ||
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: | + | * Obligation to connect client identification and authentication to a qualified system, which is currently only [[en:nap: |
* Obligation to link identification, | * Obligation to link identification, | ||
* 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, | The preferred way of integrating applications is to use a standard integration platform (also Enterprise Application Integration, | ||
- | Each authority will use its own or shared EAI connected to a central [[[: | + | Each authority will use its own or shared EAI connected to a central [[en: |
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 [[[: | + | A central integration platform [[en: |
The corporate EAI serves primarily for internal integration needs within the chapter or public corporation, | The corporate EAI serves primarily for internal integration needs within the chapter or public corporation, | ||
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: |
- | Rules for individual shared services, functional units and thematic areas are described in [[nap_document:rules_for_functional_units_architecture|Methods | + | Rules for individual shared services, functional units and thematic areas are described in [[en:nap_dokument: |
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. | ||
</ | </ | ||
- | < | + | < |
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. | ||
</ | </ | ||
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/ | + | - **Reference -** identify all subjects/ |
- **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**, | 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**, | ||
- | 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: | + | 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: |
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 [[: | + | 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: |
- | 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/ | + | * Controller publishes the data within the selected context with a link to the subject/ |
* 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 [[[: | + | * Agenda uses the data via [[en: |
* 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, | + | 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, |
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: | + | * Spatial data elements that are related, similar or identical to [[en:nap: |
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 [[: | + | - Data published by the agencies and their AISs (used [[en: |
- 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: |
- | Rules for individual shared services, functional units and thematic areas are described in [[nap_document:rules_for_functional_units_architecture|Methods | + | Rules for individual shared services, functional units and thematic areas are described in [[en:nap_dokument: |
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: | + | PaaS and IaaS [[en:nap: |
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 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, | ||
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: |
- | Rules for individual shared services, functional units and thematic areas are described in [[nap_document:rules_for_functional_units_architecture|Methods | + | Rules for individual shared services, functional units and thematic areas are described in [[en:nap_dokument: |
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 681: | Line 681: | ||
- Through the Regional Networks (currently in the Vysočina, Pilsen, Karlovy Vary, Zlín and partly Pardubice regions + others if built). | - Through the Regional Networks (currently in the Vysočina, Pilsen, Karlovy Vary, Zlín and partly Pardubice regions + others if built). | ||
- | - Through [[en: | + | - Through [[en: |
- Through the Communication Infrastructure of Public Administration (KIVS) using commercial offers competed through the Ministry of the Interior. | - 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. | - Via the public Internet, via a secure VPN SSL or VPN IPSec tunnel. | ||
Line 691: | Line 691: | ||
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 the services of the so-called [[en:nap:referencni_rozhrani|reference interface]], |
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 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, | ||
Line 729: | Line 729: | ||
==== Clerk' | ==== Clerk' | ||
- | {{ :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 |}} |