Architectural Repository and Tool

Each authority is to design and discuss with the OHA MoI what characteristics its "architectural repository" should have as a subset of the "enterprise repository" for managing the authority's knowledge, how it will serve as a shared repository for other authority organizations (department, county corporation, ORP) on the one hand, and how (and when) it will be integrated with the central national public administration architectural repository on the other.

A central National Architecture Repository project is being developed which will on the one hand be a consistent central repository for all authorities' models and on the other hand allow selected authorities to access the modelling tool. Other authorities can model in their own tools, including the open source tool ARCHI, which is free. As a condition, they will share their models with the central repository in a standardised format, The Open Group ArchiMate File Exchange Format, in the scope and content according to the mandatory requirements for each type of architectural engagement.

All models and views created will, together with all related and downstream documents, be stored in an architectural repository (repositories) that is an integral part of the overall authority/enterprise repository (enterprise repositories) and its knowledge management mechanisms (processes and systems). In terms of modelling, the repository is primarily a repository of metamodels, reference models, or mandatory models and individual models of the architecture of the authority and subordinate organisations. These three types (packages) of models are decomposed into greater detail where necessary. Views are derived from the models, which show the elements and links from the sub-models according to the perspective being viewed.

The need to uniformly maintain the architectures of the individual OVSs (called local), together with the need to centrally maintain the architecture of shared central eGovernment elements and services, and together with the need to jointly evaluate and manage the local and central architectures, leads to the following formulations of the required properties of the individual architectural repositories.

The descriptions of the architectures in the office form a system of outputs, categorizable from many perspectives, for example according to the purpose and level of detail of the models, see Structure of modelled architectures.

The architectural repositories, both national and local, described in the following sections are used for the "Enterprise Architecture" level of description. However, it is found in the overall Authority repository along with the output on all other more detailed levels of description "Solution Architecture", "Solution Design" and Service Delivery Operational Documents. Optimally, all corresponding and related documents are cross-referenced in the target form.

The repository for the "Authority/Enterprise Architecture" level must include, according to this NA VS CR methodology, with reference to the TOGAF standard, a means for storing outputs (models, documents) from the following areas, as shown in rough detail in the following Figure:

• Architectural Framework (orig. Architecture metamodel) - definition (documentation) of the modified architectural framework of the NA VS CR, including the methodology for architectural content (glossary of terms, metamodel, definition of viewpoints, etc.) and methodology for the creation and maintenance of architecture (processes and procedures according to phases, roles and responsibilities, etc.).
• Architecture Capability of the Authority - definition (documentation) of all the requirements (strategy, org. structure, knowledge, roles, control mechanisms, etc.) of the Authority's architecture department.
• Library of individual architectures (orig. Architecture landscape) - documentation of the description of the own individual architectures of the Authority and its subordinate organizations, across all domains and levels. Architectures are stored as models and artifacts (catalogs, matrices, and views) derived from the models as well as documents using, commenting on, and extending these artifacts.
• Reference Library (orig. Reference Library) - contains tutorials, classification and reference models, output templates and patterns, examples and all other forms of accelerators to facilitate and accelerate the creation and maintenance of descriptions of individual authority architectures.
• Standards Information Base - includes documentation of all standards and mandatory design patterns that the proposed individual architectures of the Authority and its subordinate organisations must comply with.
• Audit Log (orig. Governance Log) - Documentation of all activities by which architectural governance has been carried out, such as the results of architectural design reviews, Architectural Board minutes and decisions, waivers granted, etc.

The content areas Architectural Framework, Individual Architecture Library, Reference Library and Standards Library, i.e. the first four areas above in the following figure, require IT support with an Enterprise Architecture Management (EAM) modelling tool due to the nature of their content based on architectural models.

The effective work of any architecture office, including the OHA MV, must naturally be complemented by a set of additional tools for knowledge management, sharing and communication, such as a Document Management System (DMS) and Knowledge Management System (KMS), a collaborative maintenance and knowledge sharing tool (Wiki), a social network portal, etc. All these systems should be accessible to knowledge users (not model editors) through the Authority's internal portal. In the case of OHA we also talk about the Library or Knowledge Base of the National Architecture of the Czech Republic as the Czech GEA BoK (Body of Knowledge).

Since the National Architecture is the conceptual foundation of other public administration modeling disciplines, we expect the NAP repository to become a key element of the set of information systems that together represent the meta-information system of the state, such as ISoISVS, RPP and IS Modeling, among others. Therefore, the central EAM tool will support downstream notations in addition to the mandatory ArchiMate notation, certainly BPMN, ERD and the core UML models. Other modelling notations are not yet planned to be used and may not be supported by the central tool.

All architectural outputs - models, views and variants of these views - must be classified according to a uniform set of attributes in the local repositories of the authorities and in the central architectural repository of the NA VS CR.

Whether access to the model in any repository is mediated in the menu or navigation by any combination (order) of the dimensions listed below, the model must always be mandatorily classified by all the attributes listed below, unless otherwise specified in the rules for any attribute. The linearized classification string of a model (view) may become a technical, coded part of its label.

VS organisations and their models are classified in the following groups of dimensions for the purpose of management and governance of the NA VS CR:

• Classification of modelled (modelling) public sector entities
• Classification of architectural models
• Classification of model views

A special form of classification of authorities and their models is their:

• Segmentation of authorities and models by similarity.

A list of the defined classification and segmentation dimensions in each group can be found in Appendix 2 and in Knowledge base.

The different types of models, differing according to their purpose in the process of creating, maintaining and using public administration architecture models, will also differ in their ability, need and obligation to be classified according to the above dimensions of the architecture space. In this section, analyses and suggestions are made for the selection of classification and segmentation attributes according to the types of models, which are:

• IM - Individual Authority Architecture Models
• MM - Model with metamodel and view definitions (viewpoints).
• RM - Reference Models
• VM - Mandatory and Recommended Models
• PM - Models of theoretical and anonymised practical examples

All types of models can be referred to by one common string (Attribute1=value;Attribute2=value;…;AttributeN=value), while for some types of models a number of attributes will take the value "0 - empty"

Examples of filling the attribute string with values for different types of models and their explanations are given in the following sections.

Thus, one common repository for the statewide vision and overview models, for shared eGovernment elements and for local authority architectures will contain the following models and views:

• The overall hierarchy and navigation of the NA VS CR models.
• Models of definitions of the NAR architectural framework (metamodels, aspects, methodological schemes, model structures, etc.)
• Reference models of diverse purpose and scope
• Library of standards, building blocks and architectural patterns
• Models of individual (real) office architectures

This structure will be repeated in the models at each level of the hierarchy of government, which is inherently federated. This means that a more general national reference model for, for example, a department or county must adopt the department or county corporation's reference model if it is published, but they can add their own specifics to it and store the department or county's reference model so modified in their (local) reference model library. This is regardless of whether the department or county will use a single common central repository or whether they can/need to use only their local tool or both.

The focus of the architectural deliverables is a set of individual models for all agencies/enterprises (enterprise) of the public administration of the Czech Republic, comprising simultaneously the architectures of the current state (As-Is), the future state (To-Be), all identified necessary intermediate architectures on the way between them and, exceptionally if necessary, the architectures of the past state (As-It Was).

The NAR methodology assumes that each VS office/enterprise (meaning enterprise) will need to have model objects and selected views of all "architecturally" superior (broader, higher, more general) public administration architectures in its own local repository (architectural repository) for correct modeling and understanding of its own architecture and the architectures of the organizations for which it is responsible in the sense of this methodology. Namely, the architectures of those parent authorities whose shared or generic elements it must or may use in its current state or plans to use at any time in the future, bounded by the modelling horizon.

Conversely, it is not assumed that independent modelling units (e.g. a ministry or a county) have in their repository objects of models of the sharp individual architectures of their 'neighbours' at the same level of the hierarchical segment (e.g. other counties) or even of authorities with which they have nothing in common. Except when an authority uses (shares) elements provided by another authority - then it must include these elements and models of these authorities in the hierarchy of its architecture model repository to the extent necessary. The exact manner and extent of this "necessary extent" will first be verified by pilot projects.

Some more advanced tools allow the content of the central repository to be not only divided into so-called models, but also grouped into so-called projects or packages. When you need to load a model into the editor, you need to open and load the whole project, the package in which the submodel is contained. From this point of view, it is more efficient to divide the content of the repository into several projects (packages), for example one for each department or regional corporation, ad absurdum for each individual OVS.

On the other hand, all views within a single project (package) can arbitrarily share objects from all models with each other, and any change to an object is immediately visible in all views, as opposed to cross-package integration, which is more limited and difficult in tools. The Slovak example demonstrates the placement of the architectures of all the IMSs as individual models in a single common package.

There is not yet a publicly available and content-filled central NA repository and the partial models already created do not yet form a coherent hierarchy. It will be gradually created according to the rules presented here.

The model used as a means to create the illustrations of this document, i.e. the meta-model definitions and the NAR viewpoint definitions, is stored and publicly available in an exchangeable format in the NA VS CR Knowledge Base, where it will also be updated regularly.

Of the reference library models, the following are currently available in the NA VS CR Knowledge Base:

• RM-BA, a reference model of public administration business architecture (generic, not scaled for individual categories of OSS),
• RM-AA, reference model of public administration application architecture (generic, non-scaled for individual categories of OSS).

Further models will be added here as the NAP is developed and the NAR is updated.

The NAP (and the whole NA VS CR) library of standards and patterns currently contains only a set of models of solution architectures for connecting AIS to central eGovernment elements, called Architectural Patterns for Shared eGovernment Services.

This section will provide examples of what the structure of ArchiMate model repositories in a local EAM tool of typical modelling units in a government hierarchy could/should look like, or corresponding content snippets in a central repository, which, as noted below, will be synchronised with each other. There are initial OHA proposals for what the structure could look like, but there has been no pilot project to test the proposed structure in a realistic mode of sharing models between local and central repositories.

Also, in the hierarchies of the models of the individual CAOs, the models of the individual chapter offices can be grouped into directory structures for easier understanding and navigation, optionally, for example, according to the way the organizations are set up, financed and controlled by the ministry, as for example in the case of the MoE these are:

• Organisational units of the state
• State funds
• State Contributory Organisations
• State joint stock companies
• State-owned enterprises
• National enterprise
• Public research institutions

For other ministries, with a large number of subordinate organizations, segmentation by similarity in segments may be useful. Ministries with a small number of subordinate organizations do not need to make their architecture structure directory "at all costs", it can remain completely flat, see the example of the MIT.

Meanwhile, in another project of a single ministry organization, a flatter structure is also being worked with, divided into a number of separately maintained files. These would represent projects or packages when eventually transferred to a more powerful or central tool.

• Project (package, file) - Individual models of the XY office
  • "office xy"
    • Navigation diagrams
    • Views
      • Strategic architecture
        • Motivational architecture
        • Business architecture
        • Application architecture
        • Technology architecture - IT infrastructure
        • Technology Architecture - Communication Infrastructure
      • Segment Architecture
        • Capability Architecture
      • Elements
        • Business architecture
        • Application architecture
        • Technology architecture
        • Motivational architecture
• Project (package, file) - Reference models
  • Reference models of eGovernment of the Czech Republic
    • further structure as for the individual model above
  • Reference models of the corresponding ministry "office xy"
    • further structure as for the individual model above
• Project (package, file) - Sample (shared) models
  • Patterns of eGovernment of the Czech Republic - Architectural patterns of shared services
    • further structure as for the individual model above
  • Ministry patterns
    • further structure as for the individual model above
• Project (package, file) - Example models
  • Examples published by OHA MV
    • further structure as for the individual model above
  • Examples within the ministry
    • further structure as for the individual model above
  • Other examples obtained
    • further structure as for the individual model above
• Project (package, file) - Metamodel and view definitions
  • Central metamodel and view definitions of the eGovernment of the Czech Republic
  • Modified metamodel and view definitions of the Ministry
  • Further modified metamodel and view definitions of "office xy".

The division into model packages in repositories (package) or, for smaller tools, into separate files is based on the need not to combine in one model objects actually existing in the office with theoretical objects (reference models and models), objects of other offices (examples) and with definition objects (meta-level).

Here, the statewide and county elements (shared between multiple counties) act as superordinates, should they exist. The individual county organization architectures are designed to be grouped by the branches of government as previously identified for those organizations. This process of refining the sectors will continue, currently on the MsK pilot.

Here is an example of the rich use of intuitive structuring and directory navigation in the creation and maintenance of architectures for a county corporation with about 250 organizations from a range of government sectors. Behind each node of this structure is one or many EA models, one for each organization.

In addition to the classification of each model and the directory structure according to one of the segmentation dimensions (VS hierarchy, VS sector, or the form of financing and control of the organization, or others), each model will be classified in its attributes (properties), i.e. marked with the corresponding value to the classification model of that dimension.

Currently, the NA VS CR methodology assumes that the structure of the architectural repository for local government entities at the level of cities and municipalities will be similar to the structure of architectures of local government organizations at the level of regions.

A hypothetical structure of models and views on an artificial example for the organization of the city of Benesov, as it might appear to be included in a central architectural repository.

In doing so, it is assumed that the model of each subordinate organization will have the same structure as the City of Benesov.

However, no pilot project has yet taken place to test the proposed structure. Since the synchronization of the city and municipality models into a central repository is not foreseen in the next few years, see below, the pressure for a unified structure of local EAM tools will not be too strong.

The current level of understanding of the needs of NA management in the SCS and the capabilities of EAM tools leads OHA to decide that the overall management of NA management tools will be combined, i.e. in the part of obliged persons central, provided as a shared service, and in the part distributed, operated locally, with models periodically uploaded to the central database.

The central EAM tool will be available for active editing of models by OHA architects and architects of selected obliged entities, i.e. OVS at the level of OHA, KRJ and ORP, with a gradual roll-out envisaged. The first users of the central EAM tool will be architects of chapters (ministries), architects of administrators of central shared eGovernment services, architects of major independent OHAs and architects of regional corporations, in the number of up to about 50 modeling organizations. Subsequently, it is envisaged that the tool will be gradually extended as an option to all central government organisations, county corporations and selected cities, with a total of approximately 300 modelling organisations. If the central EAM tool continues to prove successful each time the scope is expanded, it will also be offered in this form to all remaining ORPs and other municipalities and subordinate organizations of county corporations and ORPs.

The advantage of this central modeling is the fully consistent use of central shared eGovernment elements in the models of each organization, significantly easier use of templates, model sharing, and governance of the development of the VS architecture. On the other hand, it requires very powerful central repositories with effective teamwork support.

Users of the central EAM tool are expected to maintain, in particular, the strategic models of the authorities' architectures, at least to the extent mandatory under the National Architecture Framework rules, directly by remote access in the tool. Or they may maintain them locally, but they will have full responsibility for "their" modelling content also in the central repository.

With the full compatibility of the central tool with The Open Group ArchiMate File Exchange Format standard, they will be able to export their models to XML and import them into their local tools if they already have one or wish to acquire one. And vice versa if they prefer to develop them locally. We expect that in this way they will locally extend the mandatory models with additional objects registered for their own use and, in particular, they will deepen the models of the Enterprise Architecture to more detailed levels of solution architectures and solution design. To do this, they will probably use notations not used centrally, such as UML and others, in addition to ArchiMate notation.

Public administration organisations other than those that will be mandatorily or optionally invited to use a central EAM tool will use only their local or peer-shared EAM tools to model their office architecture. This is on the understanding that, if obliged to do so, they will periodically submit the mandatory part of their models to the DS for "upload" to the central repository. The two levels of architectural repository management will be aligned with each other, in a bi-directional manner. This means that all local repositories will have available and will be required to use for modelling all contextually relevant information on generic, central and shared elements of the NA VS CR architecture, reference models, standards and mandatory architectural patterns. In the reverse direction, all local repositories will be required to synchronise all mandatory Authority architecture creation and maintenance deliverables (custom, group and extended) to the extent and in the manner specified by the current rules of each engagement type.

The distribution of the architecture repository to the VS CR may (may) be multi-tiered. That is, organizations responsible for synchronizing their group "corporate EA" models to a central repository may manage their local repositories in a local-central mode and delegate local management of a subset of their area of responsibility to subordinate organizations. However, they must then ensure that the information provided to the NA VS CR centre (and back) is timely, complete and correct. This means that it must synchronise its local-centre repository downwards to subordinate repositories in a similar way to how it is itself synchronised upwards. Conversely, models created locally must be imported by organisations with central modelling responsibilities into their parts of the central model, applying all governance tools there, i.e. for example, uniquely using existing eGovernment elements in their models. Crucially, organisations will be fully responsible for the correctness of their models in the central repository, whether the models are created by manual editing or import.

The primary means of model synchronisation will be a single XML file exchange format, respected by all participants and supported by their tools, ArchiMate, announced as a standard by The Open Group in August 2015¹⁾²⁾). It is likely that the structure of this XML standard will be extended to accommodate the data synchronisation needs of the NA VS CR, which all EAM tools used in VS will have to be able to accommodate. In The Open Group ArchiMate forum working group, the approach has been announced in connection with the new version of the ArchiMate 3.0 specification that only a tool that will fully support export and import using the standard exchange format is declared compliant with the specification when certifying tools. It can be assumed, then, that most tools supporting ArchiMate will also accept the interchange format.

For the case of the extension of EA in public administration, when mandatory or voluntary modelling organisations and their models will be numerous and the management of these models in the active repository of the central EAM tool, i.e. in its repository directly dedicated to the editing of graphical diagrams over models, will already be complicated and inefficient, a so-called passive (secondary) central repository has been created. It takes the form of a graph database in which all models and their diagrams are stored in a volume and indexed form optimised for speed of retrieval. This secondary repository will include, in addition to the already existing functions, a tailor-made service program that will allow, according to the linear indexing (classification) of models and their objects, to build any section of the stored data, to create a file in the exchangeable format TOGAMEFF, and thus to take it to create graphical diagrams in the active part of the central repository, and from there to publish and return it. For example, it may be a task to build an application map of all types of ERP systems or file services of all modeling entities across the entire VS.

This approach is particularly important for the ability to leverage the analytical capabilities of the central EAM tool to evaluate model attributes across a range of object relationships, one of the strengths of the chosen ArchiMate modeling language.

The solution of a central (primary) repository with a supporting secondary repository database) was designed to ideally combine and leverage the strengths of both environments, right from the start. In such a database, which stores the structure of all objects and their relationships, it is possible to store bulk control and statistical tasks over the entire set of models that would be difficult or inefficient in an active team editing tool and its resources. In contrast, the editing tool subsequently assumes its role in handling identified inconsistencies in the models, in collaborative model building projects, or in preparing managerial analysis output and graphs over the models.

There are at least several dozen commercial and freeware EAM tools on the market, with up to ten of them in common use in the country. Each of them is equipped with a different set of functional and non-functional features and are de-facto not comparable and competing with each other.

This situation puts high demands on the team and the Authority Architecture Manager to make a good assessment of the requirements they have and will have in the future for creating, maintaining and using Authority Architecture models and diagrams in ArchiMate notation and more detailed models in downstream notations (such as BPMN and ERD or UML). Cannot compete a commodity tool on price.

NAR makes it easier for architect leaders to choose a local tool with several rules and aids:

• The EAM tool must support working in ArchiMate notation, including extensions with specialized stereotypes as defined by NAR, and including full support of the TOGAMEFF exchange format for importing and exporting models. This is preferably in the form of a verified certification of the tool for ArchiMate by The OpenGroup.

In addition to ArchiMate, the * EAM tool must support at least the BPMN notation (required for process modeling and optimization) and the ERD notation or part of UML (for the Bureau's conceptual and logical data model).

• The supplier of the EAM tool must contractually commit to (automatically, immediately and included in the investment and regular software support) support always the latest highest version of ArchiMate and at least BPMN and ERD/UML.
• The tool should have support for bulk editing operations, at least support for import and export of models in Excel/CSV format.

Other already optional requirements can be selected by the contracting authority from the checklist and sample functional and non-functional specifications for the VZ tender documentation, which are part of the NA VS CR Knowledge Base.

The list of requirements for selecting an EAM tool in an office should allow the office's Chief Architect to assess what his/her team's real needs are relative to the tool, at a minimum, in the following categories:

Table - Overview of EAM tool requirement categories.

Detailed documentation of the EAM tool requirements will be maintained in the Knowledge Base of the NA VS CR based on the generalization of the experience of the public administration architect community.