Public administration is primarily governed by legislation. Therefore, it is extremely important to both understand the legal order well and to include legislation as a motivating and contracting framework in the architectures.
Basic state information systems and services related to law and legislation
| System | Legal | Description | Examples of Use |
|---|---|---|---|
| eCollection | Ministry of the Interior | An electronic collection of legislation with its consolidated temporal text | Using the ESEL interface services, it will be possible to automatically download decomposed legislation and thus have it as a linking resource for incentive, process and business architecture. eCollection will be the initial reference source for text and changes to legislation |
| eLegislation | Ministry of the Interior | Information system to support the drafting and negotiation of legislative amendments and to computerize the process of legislation adoption | The ESEL services will provide tracking of the status of drafting and negotiation of amendments and proposals, as well as an environment and tools for the creation of proposals for legislative amendments (may come from the results of optimization proposals according to the architecture) |
| ODOK | Government Office | IS for the circulation of documents for the government agenda and for meetings of the government and its bodies | This information system contains documents and information within the government agenda, documents for government meetings, but also tracks government and legislative tasks |
| EKLEP | Government Office | The Electronic Library of the Legislative Process serves as an IS to support the entire process of discussing, commenting on and approving legislative proposals | |
| EKLEP | Government Office | The public part of the EKLEP library | It is also published schematically according to XML schema metadata and as opendata, so it can be used in many cases as an information resource |
| RPP | Ministry of the Interior | The Register of Rights and Obligations also contains reference and binding data on individual agendas, links to legislation, OVM competences and actions and activities in these agendas | It serves as an authoritative and reference source on the performance of public administration |
Each of these IS can and should be used both as a source of information for the authorities and as one of the components in optimising the activities of the authority. For example, if we want to optimize an agenda in an office, we should have its architecture. One of the inputs for this architecture is the legislation (source ESEL) and the agenda model of the given agenda (source RPP). After designing the process optimisation, it will probably be necessary to amend the legislation as well, which in turn will be supported by the above-mentioned information systems.
The extent to which the above-mentioned information systems and their shared services can, and even must, be used depends on the position of the relevant authority in relation to the specific legislation.
In this case, we can therefore divide the authorities into the following three categories:
In each of these three basic roles, the information systems mentioned above can be actively used.
Not forgetting the duties of the file service, which of course also apply to the processes of drafting and debating legislation. Therefore, if I am the responsible person for legislation, I will first of all ensure the integration of my authoring systems into the ESSL and subsequently the integration into the obligatory information systems (eLegislation, ODOK, EKLEP, etc.).
In the evaluation and subsequent preparation of proposals for change, the two key sources are the legislation in force (the actual wording of the legislation and its links) and the impact on actual performance (the source is the RPP and the agenda model and list of tasks in the agenda). Using the links with other legislation, the Authority will also map the context to other capabilities. For example, with the agenda law, the file service obligations, the obligation not to request data that I already have, etc. should also be taken into account. Even with this in mind, it is always useful to have the current or expected versions of legislation as a source.
When designing the architecture, it is then highly advisable to have elements of the architecture linked to the relevant legislation. For example, if I am managing an information system, this is used to support the process in the law. Thus, I know that I am operating the system based on the ISVS Act and the relevant agency Acts and function requirements must ensure that the relevant processes in each Act are implemented.
Sources of information on laws and their projection into public administration agendas are also useful for creating and updating internal directives and regulations in the organization. For example, if the legislation on the basic registers or the filing service changes, I know that this will have an impact on my processes and therefore on the regulations and directives that define the processes. So there will certainly be changes to the agenda process methodologies, changes to the Filing Regulations, etc. This is also why I have to use the above mentioned resources and ensure their integration to the components I use to maintain documentation.
If the office in question is not the authority responsible for the relevant legislation, but is nevertheless bound by the legislation, then it should also comply with some of the above basic principles. Up-to-date data on the status of legislation, including the link between each provision and each piece of legislation, must serve as the basis for the business architecture. The second source is the data in the register of rights and obligations.
It is therefore advisable to: