Architecture development process

After the previous chapters have defined What?, i.e. in what organization and what components of the architecture the authority is modeling, this chapter sets out How? exactly this is to be proceeded throughout the architecture life cycle.

Of the pair of disciplines of 1) architecture management and 2) architecture governance, this chapter focuses on the processes of both, but the structures, authorities, and selected functions of both are in a separate chapter.

For the architecture development process, the NA VS CR methodology adopts the cycle from the TOGAF ADM (The Open Group, 2018). This is divided into phases and these are further divided into steps, explained in the description of each phase. In each phase, it is always necessary to check that the outputs and outcomes of the phase match the expectations of the whole engagement and the methodological requirements for that phase. The following phases are found in the ADM methodology cycle:

Preliminary Phase, which describes the preparation and initiation of the activities required to translate business needs into architecture, including the adaptation of the architectural framework and the definition of principles and boundary conditions.

Phase A: Architecture Vision describes the initial phase of the architecture cycle. It includes defining the scope, getting to know the stakeholders, developing the architectural vision, and obtaining approvals for the architectural plan.

Phase B: Business Architecture describes the development of the business architecture, the organization's mission to support the achievement of the stated vision.

Phase C: Information Systems Architectures describes the process of developing the IS architecture, including the application and data architecture.

Phase D: Technology Architecture describes the development of the IT technology infrastructure architecture.

Phase E: Opportunities & Solutions performs the initial implementation planning and identification of the means of delivery of the architectural changes defined in the previous phases.

Phase F: Migration Planning is the detailed planning of the necessary implementation steps.

Phase G: Implementation Governance represents the architectural oversight of the implementation process.

Phase H: Architecture Change Management establishes procedures for managing architectural changes.

Requirements Management is the link between IT requirements management and architecture change management processes. The (Architecture) Requirements Management phase is continuous. The outputs of one phase can (or even should) be modified by subsequent phases.

ADM is built on iteration between processes. The goal of these iterations is to build an optimal architecture. Each iteration is prefaced by a decision about what should be covered by a given architectural engagement, what level of detail is required and in what timeframe the target architecture (the outcome of the iteration) should be reached. Of course, it is also specified what architectural standards (components) will be used and under what constraining conditions.

The TOGAF ADM methodology assumes that it will be tailored to the organisation, which is also true for the Czech public administration. The adaptation of the ADM for NA VS CR is described below.

Before starting any sub-architectural work in an office, the decisions below need to be made again and the parameters of that engagement set.

The ADM methodology is an iterative process, with iterations between phases and within each phase. For each iteration in ADM, for each new architectural assignment (engagement) in the office/enterprise, there must be a prior, in Request for architecture work¹⁾, see the template in the Knowledge Base, is specified (The Open Group, 2018):

• the breadth of coverage of the authority/enterprise by architectural engagement, both in terms of parts of the authority (enterprise) - STR/SGM/SCH, and in terms of the context of architecture in the corporation and the public service delivery chain - VLST/SPOL/ROZS
• required level (depth) of modelled detail (EA or SA, probably not SD) and (L0-overview/L1-basis/L2-detail)
• time horizon of the target architecture (e.g. typically 1 year and 5 years)
• modelled domains (Motivational and BADT²⁾) and their concepts
• architectural inputs, whether these are results of previous phases or previous cycles in the office or architectural materials from anywhere, such as reference models from OHA MV or from around the world.

Over and above the TOGAF standard, this methodology specifies the NA VS CR to already specify in the Architectural Work Requirement in advance of the engagement:

• The key stakeholders (stakeholders) in addition to the sponsor, who is automatically included, their needs, and the key architectural artifacts and deliverables that can meet their expectations.

A definitive and binding specification of deliverables will always be provided by the approved Statement of architecture work. )), which is the response of the Authority's architecture team to the Request for Architectural Work and the actual assignment of the following architecture project.

The primary decision is whether the architecture within the office/enterprise (enterprise) or a part of it (segment, capability) responds to the client's required intent, or whether an "extended office/enterprise" will be modeled together with external partners, contractors and authorities. It is therefore relevant whether the architecture engagement in question will be a VLST³⁾, SPOL⁴⁾ or ROZS⁵⁾.

In any architecture assignment for individual models within an authority (enterprise), a decision needs to be made as to whether it will be a holistic, strategic architecture or a segmented or even capability-only architecture.

However, it is always important to respect the principle that even however partial the architecture is, it is modelled with the full architectural context of the authority in mind. With the first sub-engagements, it is also necessary to create basic overview diagrams (maps) of the different layers of the architecture of the whole authority, otherwise full architectural decision making is not possible.

For the models within the NA VS CR, unless otherwise specifically justified in the Architectural Work Requirement, the so-called enterprise/office architecture shall be modelled for each architectural engagement according to the scope in the previous point. That is, the level of detail of the "Enterprise Architecture" modeling all occurrences of capabilities, processes, applications, platforms, etc. according to the NA VS CR metamodel that are currently located or targeted to be located within the organization's scope (whole, segment, or sub-capability). Thus, in terms of diagram details, the standard expectation is the so-called level L1 - Basic. However, for each inventoried or projected object, the model asks only for its existence and for several attributes fundamentally related to its existence, e.g. whether the application component is purchased or programmed, from whom, when it was created and when it will disappear without support, or whether it is part of the strategic infrastructure of the state, etc.

Depending on the need from the engagement brief, the basic diagrams of the model can be supplemented with overview-L0 and detailed L2 diagrams.

Only for chosen opportunities identified in the Authority Architecture for change or for the purpose of back-documentation of existing solutions, Authority Solution Architectures may subsequently be created in the next architecture cycle (with a separately specified assignment), with a level of detail of "Solution Architecture". These, for changes intended for implementation, answer the question: "How should it work (inside-function and outside-services)?" and represent, in the form of full functional and non-functional specifications, service catalogues and other detailed architectural artefacts, the essential basis for the selection and conclusion of a contract with an internal or external contractor for the implementation of changes (including the implementation of information systems).

Specific Design solutions are never again created under the responsibility of the Authority's architecture units. The exception is when the mandatory pattern must, for reasons specified by OHA, extend to the level of a detailed solution design pattern. Then the Authority's architects must be able to demonstrate that even at this level the mandatory pattern has been followed and must address the design or review (at design by the contractor) of the solution design in conjunction with this pattern.

In any architectural engagement, a decision needs to be made about the time horizon (how long) of the target proposed architecture. On the one hand, the length of the required horizon is lengthened by the requirement for long-term stability of the design, on the other hand, it is shortened by the inherent inability to predict anything for longer than about three years (especially in the IT domain).

The actual length of the time horizon of the architectural engagement stems from the need to manage to meet the requirements of the client (the management sponsor of the change). Naturally, the horizon in the VS is derived from political and economic milestones, which represent the so-called fixed (absolute) horizon. For the current NA of the VS of the Czech Republic, in accordance with European and national strategic documents, such an absolute fixed horizon is the year 2020, followed by the year 2023 (5 years of the IK of the Czech Republic) and the year 2030.

In addition, the architecture of the office should always provide sufficient information and basis for decision-making. Therefore, this methodology stipulates that a horizon rolling (relative) period of 5 years from the submission of the architecture for approval must be used as the next milestone of the target architecture. This is particularly true for the overall Authority architecture developed for the purpose of updating its OVS Information Concept, which is also for 5 years.

The implementation of the architectures is done in steps, corresponding to development programmes and projects. Each of these, when successfully completed, moves the current state to the next projected future state of the architecture. Such time slices of architectures are called transition (state) architectures. Given the persistence of the annual management (and budget) cycle in the State Government and the limited degree of predictability of things to come, it is mandated that the path to the Authority's target architecture horizon (2020, 2023, 2030, or 5 years) must be mandatorily broken down into at least transition architectures corresponding to Year 1 and Year 2 of their implementation. In addition, it must be possible to present from the architectural model in the authority repository (or subsequently in the central national repository) the projected authority transition architecture to each milestone of completion of the implementation project or programme.

For all office/enterprise architectures within the NA VS CR, with the same rolling (relative) horizon (5 years, corresponding to the budgetary outlook), they will be updated at the level of the strategic office architecture on a regular basis each year so that the identified (and refined) transition projects for the following year can serve as an informed basis for negotiating the structure and size of the budget.

For the architecture models for individual architectural engagements in the offices, the NA VS CR concept expects them to always include a description of the architecture (models and artifacts) in all its domains, see Structure of modeled architectures. This applies without exception at least to the regularly updated overall strategic architecture of the authority.

Authorities will not always have sufficient time, skills, capacity or resources to design (or have designed) all sub-architectures in all domains. Therefore, for segment and capability architectures associated with incremental reform or IT change, it is not necessary to design all domains of the authority's architectures unless it is necessary to meet the requirements of the sponsor, the sponsor of the architectural engagement. However, non-proposed domains should always be at least marginally considered.

Example: If the sponsor is tasked with designing which technology platform components can be moved to the two target virtualized county data centers and which can even be moved to one of the NDCs (eGCs), then the IT technology layer and communications layer must be complete, but the application layer only needs to be implied and the data, business, motivation and performance layers do not need to be modelled at all as it is assumed as part of the engagement brief that application services and data against the business and higher layers must not change with the change in technology layers.

In its updates, this methodology sets out a progressively growing set of mandatory and recommended accelerators (patterns, taxonomies and reference models, guidelines, examples). These, depending on the level of bindingness, must or can be used in all corresponding engagements.

If there is a choice or the corresponding accelerators for a given engagement are not yet provided by the concept, it is necessary that the specification of each engagement is also refined by reference to the inputs specified for it.

Similarly, this applies to existing architectural artefacts. Each engagement brief should specify which previous architectural artefacts and outputs it is intended to build on, refine or replace.

Before the architectural engagement begins, key stakeholders must already be identified in the Requirement for Architectural Work⁶⁾, their requirements and needs, and the architectural artifacts (views of the model) that can be used to meet those needs, unless this is implied by the binding documents for some engagements, such as the OHA Request for Views or the development of the OVS Information Concept.

In particular, it is the case that the Authority's managers will need to make investment decisions in relation to the architectural engagement (based on its outcomes) to implement changes and the outputs of the architectural work must support and facilitate these decisions.

This section explains which phases of the ADM methodology will be applied, to what extent and how adapted in specific situations where the authority is already required to demonstrate its knowledge of the authority's architecture and sub-architecture appropriate to the solution being developed. Currently, these types of architectural engagements are:

• Design of the Authority's architectural vision
• Enterprise project architecture (PSA)
• Documentation for requesting OHA's opinion on an ICT project
• Update of the Information Concept of the Public Administration Authority, as an elaboration and concretization of the Information Concept of the Czech Republic (approved by the Government on 3 October 2018 on the basis of the amendment to Act No. 365/2000 S.).
• Solution Architecture (SA)

More in the following sections.

A guidance note or link to a separate document will be added here.

Instructions or a link to a separate document will be added here.

Here guidance or link to a separate document will be added.

In this section, customizations, extensions and modifications to the NA creation, maintenance and use cycle, according to the TOGAF ADM, will be added to the structure below and explained here.

Currently, the form of the so-called Architectural Work Requirement, the part of the Preparatory Phase and the Architectural Principles, as part and tool of Phase A of the cycle, are adapted to the needs of the NA VS CR in this way. The other parts have a blank structure according to the original TOGAF ADM.

The objective of this phase is to perform all the preparatory activities required to start any architectural work in the office. Therefore, this phase is usually performed only once, at the beginning of building the architectural capability of the Authority, in case of major changes in the conditions for architectural work.

The preparatory phase has the following main objectives:

1. Determine the required architectural capability (skill) of the Authority:

• Verify the organisational context for building the Authority's enterprise architecture capability.
• Identify and determine the scope of the Authority's organizations involved in the architecture development.
• Identify the management and governance frameworks, methods and processes already in place that intersect with the architectural capability.
• Determine target architectural maturity.

2. Create (establish, establish) architectural capability (skill and capacity):

• Define and establish an enterprise architecture organizational model.
• Define and establish the processes and resources needed to manage and govern the enterprise architecture.
• Select and implement tools to support the architectural capability.
• Define architectural principles.

=== Inputs, Process Steps, and Outputs ===.

Determine architectural principles

A guide or link to a separate document will be added here.

Requirement for architectural work (PAP)

After preparing the organization and building its capability to produce architecture comes the first architectural task, called the engagement, for example, to compile architectural documents to complete the OHA request for proposal. The initiation of such work must be preceded by the identification of a sponsor (sponsor) and the receipt by the architectural team of what is called an Architectural Work Request. For more information about the Request for Architectural Work and the response to it, called the Task for Architectural Work, see Architectural Work Process and following.

The architectural vision phase involves defining the scope of the architecture, identifying stakeholders⁷⁾) and the creation and approval of the architectural vision for the following architectural cycle. Phase A: The architectural vision has the following main objectives:

1. Create a high-level vision of the capabilities and values that will be delivered as a result of the subsequently proposed enterprise architecture for the Authority.
2. To Obtain an approved Architecture Statement of Work (SOW) that defines the scope and approach that will be used to implement the architecture project to develop and deliver the architectural vision.

The phase begins with the receipt of a Request for Architectural Work (ROW) by the Authority's Architecture Office from the sponsoring (requesting) organization, department.

All available reference materials, primarily provided by OHA as part of the NAR and NAP, will be used for the Authority's architectural work, followed by additional experience and best practices.

Architectural Principles

The Architectural Principles are rules derived from the eGovernment development goals, agreed upon after broad discussion, and used primarily to ensure that they are fully adhered to when designing the target architecture of the public administration (and its information systems) that will most fully meet the reform goals of the Public Administration Strategy.

The scope of the application of the principles is the same as the scope of the obligation to model the architecture of the authority, i.e. it is expanding with the successive stages of the implementation of the National Architecture of the Public Administration.

For the purposes of the NA VS CR, we distinguish three categories of principles, differing in the way they influence the design of the architecture:

• Overall⁸⁾ principles - i.e. principles that influence reform and investment decisions and the behaviour of the authority/enterprise as a whole.
• Architectural principles - which determine what the correct content of the proposed target architecture should be in all its domains (business - process, application, data, IT technology, infrastructure, security and eventually performance).
• Methodological principles - which set out the basic rules for the process of creating and using the architecture, discussed in more detail throughout the concept of NA VS ČR

The Principles are intended for architects of the authority (enterprise), architects of the authority's solutions, IT managers and all other managers of authorities, for political representation and the general public. In particular, the principles have the following uses:

• the set of principles provides an information base for authority management for decision-making in the areas of eGovernment and IT management.
• as criteria for decision-making and evaluation of solution architectures and product selection
• as criteria for assessing the conformance of an authority's target architecture to requirements and for assessing the conformance of individual projects
• as an aid for assessing both existing systems and target architecture options
• the justification of the principles provides a link between the objectives, the desired state of government and the necessary architectural activities
• the implications of the principles provide a list of expected changes that must take place to meet the principles. This list can be used to check whether the submitted projects sufficiently comply with the principles in terms of their architectural content and planned activities.

The current catalogue of the principles of the National Architecture of the Czech Republic (and the current National Architecture Plan NAP) has been published as part of the government-approved Information Concept of the Czech Republic, under the designations P1 to P17. These architectural principles have also been included in the OHA opinion request form, and a list of the implications of these principles, along with supporting checklist questions, will serve as a check-list for evaluating the compliance of submitted IT projects with the ICCR and NAP.

In addition, authorities have the possibility to seek and formulate other principles that are specific to their own strategic objectives. Thus, the objective of the preliminary phase of the architecture development process in each individual architecture engagement is to find all currently valid and relevant architectural principles, if they already exist - i.e. have been formulated - in the ICCR or in the IK OVS. If they are not sufficient or up-to-date, they will have to be created and updated during the phase.

The sources of information for the architectural principles in the Authority tend to be the IKCR and the IK OVS in addition to the IKČR:

• The Authority's strategy (policy)
• IT Strategy
• Guidelines
• Procedures

All principles are interrelated, they must be applied as a whole set. Sometimes the principles compete and create creative tensions (for example, between wide availability and trustworthiness of data). The resulting decisions must be based on a detailed explanation of the requirements and be a balanced compromise.

For more on architectural principles, see Guidelines and techniques for architecture creation.

Stakeholder analysis

A description or link to a separate document will be added here.

Design of the architectural vision

A description or link to a separate document will be added here.

Requirements for architectural work

A description or link to a separate document will be added here.

Not yet adapted for NAR.

=== Phase Objectives ===.

The objective of this phase is the development of a business architecture for government services, as an elaboration of the changes resulting from the approved architectural vision for the Authority.

Phase B - Business Architecture has the following main objectives:

1. Develop a target business architecture, which describes how the Authority's business objectives will be achieved, articulated through needs, strategic initiatives (policies)⁹⁾ and stated objectives (achievable tasks).
2. Define candidate work packages (projects) for the architecture roadmap, identified based on differences between the baseline (current) and target business architectures.

Not yet adapted for NAR.

The objective of this phase is to develop the information systems architecture in the public agency, including the development of their data and application architectures.

Phase C - IS Architecture has the following main objectives:

1. Develop a target information systems (data and application) architecture that describes how the IS will enable the realization of the business architecture and architectural vision.
2. To Define candidate work packages (projects) for the architecture roadmap, identified based on differences between the baseline (current) and target IS (data and application) architectures.

=== Inputs, process steps and outputs ===.

Not yet adapted for NAR.

The goal of this phase is to develop a technology architecture that includes HW, SW, and communications infrastructure.

Phase D - Technology Architecture has the following main objectives:

1. Develop a target technology architecture that enables the implementation of the logical and physical application and data components and architectural vision.
2. To Define candidate work packages (projects) for the architectural roadmap, identified based on differences between the baseline (current) and target technology architecture.

=== Inputs, process steps and outputs ===.

Not yet adapted for NAR.

The goal of this phase is to identify projects, programs, or portfolios that will effectively deliver the target architecture defined in the previous phases.

Phase E - Opportunities and Solutions has the following main objectives:

1. Generate an initial (initial) full version of the Architecture Roadmap, based on the gap analyses and candidate components for the Architecture Roadmap defined in Phases B, C, and D.
2. Determine whether a step-by-step approach is needed and if so, define a transition architecture that will, in particular, ensure the ongoing delivery of business value.

Not yet customized for NAR.

The goal of this phase is to define migration plans to get from the current architecture to the target architecture.

Phase F - Migration Planning has the following main objectives:

1. Finalize the architectural roadmap and implementation and migration plan.
2. Ensure that the implementation and migration plan is coordinated with other change management and deployment approaches in the organization.
3. Ensure that business value, cost of implementation and any transition architecture are understood by key stakeholders.

=== Inputs, process steps and outputs===.

Not yet adapted for NAP.

The objective of this phase is architectural oversight of the implementation of the architecture.

Phase G - Oversight of Implementation has the following main objectives:

1. Ensure compliance of implementation project deliverables with the target architecture (architectural oversight).
2. Perform appropriate governance of the architecture for the solution and any implementation-driven architectural change requests.

=== Inputs, process steps, and outputs ===.

Not yet adapted for NAR.

The objective of this phase is to establish procedures for managing changes to the new architecture.

Phase H - Change Management has the following main objectives:

1. Ensure that the architectural cycle is maintained.
2. Ensure that the architecture oversight framework is met.
3. Ensure that EA capability grows in line with current requirements.

Requirement for architectural work

Not yet customized for NAR.

The goal of this phase is to establish a process for managing architectural requirements during the architecture development process. Phase: requirements management has the following main objectives:

1. To ensure that the requirements management process is supported and applied to all relevant phases of the architecture development methodology.
2. To manage architectural requirements identified during the architecture cycle and/or phase.
3. Ensure that relevant architectural requirements are available** for each phase of the architecture development methodology.