Development of the Capability Level Architecture at national level

This part describes the lifecycle followed by the Yellow country for developing the Search and Rescue solution in a national perspective at capability level. This includes the production of the national capability architecture and the integration of transition architectures, grouping implementation projects provided by contractors or by the Yellow Acquisition community of interest[^3]. The implementation project consists in:

  • A Project architecture detailing the implementation of the system.

  • Information related to contracts, costs and implementation.

  • Complementary information on the realization of the project.

The lifecycle is built using the different stages depicted in :

  • Prepare the capability:

    To identify organisations, processes and documents needed for establishing the architecture capability. It is accomplished by stage: Establish the architecture Landscape (AL).

  • Adjust architecture motivation data

    To align architecture activities with objectives, and remain consistent with requirements, standards and any key motivation’s elements. It is accomplished by step (stage: Manage architecture motivation data and dashboard (MD).

  • Describe the architecture;

    To conduct the definition of the RA, including the development of alternatives of architectures and producing the architecture products needed, it is accomplished at three stages: establish architecture vision) (AV), describe alternatives of architectures (AD) and evaluate architecture alternatives and propose trade-off (AE).

  • Integrate implementation projects;

    To provide a coherent implementation and migration plan including the capability architecture and the implementation projects (including existing elements, subcontractor’s deliveries or subsystems descriptions). It is accomplished at stage Plan migration (MP).

  • Govern the implementation and manage changes;

    To ensure the project remains implemented and executed according to the initial mandate, to adjust when change is needed (if the operational or the technological environment changes for instance). It is accomplished at stages govern application of architecture (AG) and decide on architecture change (AC).

Steps of the Method for Architecture Development
Steps of the Method for Architecture Development

The following sections provide a detailed description of the phases to consider for the development of the Capability Level Architecture (RA).

Establish Architecture Landscape

This initial and preliminary phase of the NATO architecture development method ensures that an architecture capability exists in the organisation for producing the architecture. The architecture team will be set-up, a lead architect appointed and the information to be used earmarked.The elements provided during this phase are captured in an architecture management plan, which will be updated at each step of the development.

The architect captures each element available in order to describe the concepts supporting the architecture. To address the capability architecture of the Yellow country on Maritime Surveillance, the main questions to answer are:

  1. What is the definition of Search and rescue? What are the related concepts? What are the authoritative documents to be used for doctrine, capabilities, operational functions and other aspects of this domain?

  2. What are the (Internal/External) stakeholders to consider?

  3. What is the objective of the architecture effort? Is there any existing work to re-use? Is there any legacy system to integrate?

  4. What are the limits of search and rescue with the maritime surveillance domain? What are the relationships to maintain with the other domains? What is the overarching scope to consider?

  5. What are the constraints related to time, costs, resources …etc.?

The Famous 6 questions of DODAF[^4] could be used during this step for guiding the questions and the investigations for documentation.

Aspects to address for architecture development
Aspects to address for architecture development

The following elements provide the key points to address during the “Establish Project Architecture Landscape” step and in the architecture management plan, they are summarized in the table at the end of the paragraph:

Prerequisite

The documents related to the context, drivers and constraints of architecture capability are available (at least a list of references and reference points has been identified).

Steps

  • From the Enterprise architecture the architect identifies the points relating to the architecture capability and the documents containing the appropriate information:

    • Architecture scope (Yellow Country) and Yellow national expectations,

    • Elements existing at Rainbow level related to the execution of the maritime surveillance and search and rescue,

    • Existing concepts for search and rescue, references to doctrine, description of the operational functions and activities; exchanges of information,

    • Business strategy, system/product/product-line strategy, Product/project portfolios,

    • Reference to the business strategy. Links with the strategic frameworks used in other areas of the organization,

    • Capabilities lists referred in the Enterprise architecture on interoperability within the Rainbow organization,

    • Elements to be provided:

      • Capabilities: Links to the Catalogue of capabilities, definition of capabilities,

      • Legacies (capabilities and systems): Timeframe of the legacies, time frame of the “to be” architecture, List of existing systems with date of obsolescence. The portfolios are used as inputs for providing this information (technological and products for existing projects).

      • Budget: Elements of budget to be considered for the development of the reference architecture,

  • From the system and capabilities available, the architects build the list of existing elements, systems, capabilities and the portfolio of existing rules directing them. The architect identifies potential projects which relate to the architecture effort. He identifies the possible partnerships for developing the architecture and some contracts agreements (tools and subcontractors).

  • The capability architecture is included in maritime surveillance. It focuses on SAR. The architecture is indented to direct the definition of standards and the national regulations.

  • The architect checks if the documents on acquisition, costs analysis, technology assessment exists.

  • The architects confirms he owns elements on :

    • identification of the objectives,

    • definition of the architecture method and tools to be used, in particular those enabling the identification and comparison of architecture alternatives

  • The architect proposes an OBS, a WBS and the related costs.

  • The architect defines the criteria for selecting the views based on a set of architecture principles.

    • The aim of this phase is to select the grid rows and columns relevant for meeting the architecture management plan objectives related to architecture products

    • Stakeholders define the criteria for assessing alternatives:

      • Operational effectiveness,

      • System performances,

      • Compliance to standards,

      • Global cost of ownership.

  • The architect defines the content of the architecture management plan.

  • The architect checks that a repository is set up for storing architecture products and the reference elements. He defines the rules for accessing and managing architecture products and additional information to documenting the architecture products.

  • The architect gets stakeholders agreements on :

    • The proposed architecture method and stages

    • The proposed architecture tools,

    • The rules to establish the appropriate links with other disciplines useful for the definition of the system (system engineering, requirements engineering)

    • Inputs, methods, tools and references of the Rainbow community

    • The architecture management plan.

Outputs

The main outputs consist in the view A5[^5] of the NAFv4 grid (this view corresponds to the NAV-1 in NAFv3) with an outline of the architecture management plan[^6]. A statement of work can also be produced if any specific need is identified. A modelling management plan can be produced to prepare the necessary project architecture tools.

The structure of the architecture summary information-1 is highlighted hereunder: An illustration of an architecture management plan is provided in Appendix1, it uses[^7] the following outline:

  • Architecture Development overview

    • Project Overview

    • Architecture development goals and objectives

    • Architecture development scope

    • Architecture Interactions with other disciplines

      • Customer Procurement

      • Customers’ Capability Management

      • Local System Engineering[^8]

    • Architecture Development key stakeholders

      • Organization of architecture team

      • Approval Authority

      • Lead System Architect,

      • Architects

      • Internal stakeholders

      • External Stakeholders

    • Success Factors

    • Architecture development strategy

    • Architecture development lifecycle

  • Architecture Development Commitment

    • Scope of architecture delivery

    • Schedule of architecture delivery

    • Budget of architecture delivery

    • Resources involved in architecture delivery

The architecture management plan must highlight the following aspects:

  • The Architecture capability is defined in terms of organization, process, resources, tools and principles.

  • The Process of architecting is defined, including methodology tailoring and selection architecture frameworks.

  • Architecture charter (or architecture mandate).

  • Methodology, Framework, References (Operational, System, Technologies, Services, Capabilities), possible tailoring.

  • Resources: define skills and roles in architecting process (roles, job descriptions).

  • Project schedule, identifying the main phases of the development?

  • Policies for the definition, selection, preparation and adjustment of supporting tools (documentation, configuration management).

  • Principles: general rules and guidelines related to objective and drivers, selected from enterprise and/or architecture domains.

The following diagram describes the views of the grid to be considered for this stage.

Zones of the Grid used in the Establish Project Architecture Landscape Stage
Zones of the Grid used in the Establish Project Architecture Landscape Stage

The following views will be developed.

NAF v4 views NAF V3 views ———————– ———————————————————————- A1 Meta data definition NAV-1 Overview and Summary Information and architecture management plan A1 Meta data definition NAV-2Integrated Dictionary C1 Capability Taxonomy NCV-2 Capability Taxonomy C2 Enterprise Vision NCV-1, Capability Vision

A1 Meta data definition View
A1 Meta data definition View
C2 Capability Taxonomy View
C2 Capability Taxonomy View
C1 Capability Taxonomy View
C1 Capability Taxonomy View

Establish Architecture Vision

Based on the information provided by the “Establish architecture landscape” stage, or according to the existing architecture capability, the architect builds the elements of architecture supporting the goals and objectives as defined in the outline of the Architecture Management Plan. The outputs consist in the development of the Architecture Management Plan and of the main drivers of the architecture. These elements are presented in a communication plan to the stakeholders in order to ensure buy-in and support before conducting the main effort of architecture development.

The development of the architecture management plan will include the answers to the following questions:

  • What must be done?

  • Who does what in this effort?

  • Where is the work executed?

  • When the work is executed (schedule)?

  • How the job is executed (WBS, OBS, Structure, Management)?

  • Why is this job executed?

The elements related to decisions, authority, results and acceptance of the architecture are included in the high level descriptions of the system which will be in the capability architecture.

To establish architecture vision, the architect extracts drivers from goals and objectives of the CONOPS for Maritime Surveillance of the Yellow country. This CONOPS can be identified in the Enterprise architecture (Overarching Architecture)[^9]. The main drivers are:

  • Increase the effectiveness of maritime surveillance.

  • Enforce standards rules and implementation.

  • Conduct Monitoring surveillance and information sharing.

  • Address environmental aspects.

The following options can be selected for supporting the architecture development:

  • Improve the coordination and maximize re-use (of systems, information or processes) between the nations,

  • Synchronize the milestones for “delivery time” at capability and enterprise levels,

  • Reduce the costs of operation and the Total Cost of Ownership (TCO).

A draft of the operational part of the vision focusing on operational functions, actors and domains is added. Operational drivers are defined as follow:

  • Increase the effectiveness of maritime surveillance, by:

    • Building a safe zone including the Yellow TW[^10] and the Rainbow TW (integration of Yellow information).

    • Operating in the safe zone with the limitations of Yellow regulations (for vessels of other countries operating under Raibow flag), in liaison with the civilian actors and the security actors.

  • Baseline for interoperability:

    • Maximizing the use of AIS,

    • Interoperability with air traffic (for SAR),

    • Interoperability with the emergency actors (Medical) and other agencies (environment, human, security).

The architect builds a consolidated report and a communication package describing the vision to be presented to the sponsor and the decision makers in order to obtain the approval on the organization on the scope of work, the work share and the deliverables.

Prerequisite

The Architecture board is nominated (officially) and has agreed on the preliminary framework within available Budget.

Steps

  • Confirm /Update situation, context and constraints.

    • The architect checks the objectives of the architecture contract,

    • The architect confirms the list of stakeholders and the information they can provide. He builds a stakeholder management matrix on the stakeholders’ concerns as part of the stakeholders’ management,

    • The architect identifies and provides answers if the change, subject of the architecture development, implies the redefinition of the system (change of manning, change of resources, new areas or interoperability challenges to consider)

    • The architect confirms the tailoring of the views, of the architecture products and of the process for architecting.

  • Identify the main architecture options and critical issues (time/ availability, quantity, quality, life cycle costs, risks)

    • The architect defines the timelines for delivering the architecture products,

    • He identifies the work streams to execute for delivering the portfolio,

      • What are the subjects to address?

      • What is the level of granularity of each subject?

      • Which views will be used?

      • What is the information to be used for developing each architecture product?

      • What are the drivers for change to be used for developing the new part of the architecture (What change drives the “to be” architecture?)?

      • What is the best way for integrating the requirement for Rainbow interoperability rules?

      • Process for architecting: the architect tailors the NATO ADM for building the appropriate sequence for the development of architecture; he clarifies the rules for inputs outputs of architecture products (what is to be produced? How? What are the dependencies between the views?).

  • Define the stages and views necessary to scope and map capability needs to AoA products.

    • The architect identifies the different steps of the development, the portfolio to be produced at each stage of the method and the mapping with existing references (capabilities, operational functions, organizations; services; legacies and pre-existing building blocks.

    • The architect selects the portfolio of views based on the stakeholders concerns by using the grid.

Outputs

During this phase the following documents are produced:

  1. An architecture definition document or ideally an architecture management plan approved by the sponsor.

  2. A first iteration of the A5 (NAV-1) establishing the foundation and the target for the architecture development.

  3. A synthetic narrative description of the vision included in a communication plan.

The architect develops an architecture management plan and the first high level elements of the architecture. The documents include at minimum the following elements

  • A high-level description of the scope for the architecture, using capability goals and principles

  • A high level description (or views…) of the capability context ((business, industrial, political, operational, legal),

  • Documents to be officially approved and accepted by the sponsor or by the customer,

  • High level description of project level strategic objectives and goals as understood by the architecture team; and taking into account the viewpoints of key stakeholders.

  • Approach considered for architecture development

  • The answers to the stakeholders’ concerns

  • A communication plan including the approval of the architecture management plan.

The following diagram describes the views of the grid to be considered for this stage.

Zones of the Grid used in the Establish Architecture Vision Stage
Zones of the Grid used in the Establish Architecture Vision Stage

The following views will be started or developed:

NAF v4 views NAF V3 views ——————————– ———————————————————————- AMP Architecture Management Plan NAV -1 Overview and Summary Information ( state the chapters updated A5 Architecture Status A1 Meta data definition NAV-3a, Architecture Compliance Statement (Meta Data) NAV-2Integrated Dictionary C2 Enterprise Vision NCV-1, Capability Vision C1 Capability Taxonomy NCV-2, Capability Taxonomy ACD Architecture Concept Diagram NOV-1, High-Level Operational Concept Description L2 Logical Scenario S1 Service Taxonomy NSOV-1, Service Taxonomy S3 Service NSOV-2, Service Definitions P2 Resource Structure NSV-1, System Interface Description) P3 Resource Connectivity ( including Human and Technical Aspects of the capability ) Cr Capability Roadmap (Capability roadmap) ——————————————————————————

The Architecture Concept Diagram
The Architecture Concept Diagram
The A5 Architecture Status View
The A5 Architecture Status View
The L2 Logical Scenario View
The L2 Logical Scenario View
The S1 Service Taxonomy View
The S1 Service Taxonomy View
The S3 Service Interfaces View
The S3 Service Interfaces View
The P2 Resource Structure View
The P2 Resource Structure View
The P3 Resource Connectivity View
The P3 Resource Connectivity View
The Cr Capability Roadmap View
The Cr Capability Roadmap View

Describe Alternatives of Architectures

Performing architecture description is the more concrete and output related activity in the development of the architecture. This stage embraces the production of the views, documents and their links to the references in order to describe the capability expected, its structure and links in its environment. The description is fully aligned with the vision detailed in the architecture management plan. The architect focuses on the identification of architectures and on the different options of the realisation.

The alternatives of architectures (AOA) consist in a limited architecture work answering a typical concern and securing the aspects related to them. The AOA evaluation report provided aims at supporting decisions for engaging the new baselines of Architecture based on AOA selected by the stakeholders. AoA is a key element in risk mitigation at project or capability levels.

At the end of the phase, the architecture portfolio is issued, including all views developed and an architecture report (or an architecture definition document) and circulated in order to achieve the consensus on the description of the capability.

Pre-requisites

The following pre-requisites are met for engaging this phase.

  • The vision has been published, the review of the sponsor provide sufficient guidance and resources for ensuring the development of the architecture will be conducted successfully.

  • The architecture management plan is agreed and the work breakdown structure is funded

  • The Architecture framework and principles are set and accessible to stakeholders.

  • The Tailoring, rules, processes for architecting are clear and agreed.

  • All the catalogues and taxonomies available are shared and used for supporting the development (NTL[^11], UJTL[^12]; Capability lists[^13])

  • An architecture baseline is accessible to stakeholders (in a repository consolidating artefacts and describing the appropriate references)

  • All the documents needed for developing the architecture are grouped and available for the architecture team including documents and models on the legacies

  • The method and principles for developing the architecture are produced and shared. The architect has a list of views to be developed for each domain (communication, IT, information, and operational activities) and level of the architecture considered (capability, project, and implementation). If the model is developed with a tool, the method and mechanisms for producing the documentation are in place. The templates and the information to be included in the documents are available and tested.

Activities

The architect based on the documents available will develop the views in order to describe the different perspectives of the system considered. He will start by aligning the design of the solution to a top down approach based on capabilities and operational views definition. He will identify the options or alternatives to the top down and document them in specific views. A sensible approach can consist in listing the capabilities and operational activities supported by the system. Having a layer or a tree representation of the capabilities or activities can be very convenient the “candy chart” developed for describing the capabilities provides a useful template of the capabilities.

Usually using a blocks and liaison models enables the description of the following subjects:

  • Nodes and need lines

  • Systems elements and interfaces,

  • Services and messages

The following cycle can be considered for developing the architecture

  1. Confirm/ update architecture drivers (qualitative assessment)

  2. Confirm/ update list of artefacts (views, rationale, etc.)

  3. Develop architecture views including mapping views to resources, and backward links to “evolution needs”.

  4. Update principles list , define the rules and provide the views: Describe the different types of views (Matrix, diagrams; UML use cases, state machine).

The architecture team produces the views according to the specific perspectives and viewpoints selected in the grid. The team limits the develop effort to the “good enough” solution in order to avoid over-specifications. A Stop criterion can be “did you answer all specific questions raised by the vision “.

The architect must remember that some tools have a tendency to drive the architecture development in too much level of details[^14]. Hence the limitation in the description and a permanent verification of the scope of the architecture are key concerns of the architect.

Key point1:

NAF refers regularly to the “views”. A view is not necessary a diagram nor a graphical and imprecise description. Views can be produced by the following artefacts:

  1. Tables, lists

  2. Narratives

  3. Diagrams

  4. Matrices,

The architect decomposes the subject of architecture efforts in main elements according to specific perspectives or concerns. The identification of the following aspects is key for producing a reliable architecture:

  1. The objects to be described

  2. The domains

  3. The relations between objects at the same levels,

  4. The information exchanged

Key point 2:

Each object of the architecture must be correctly and completely documented with an explicit and unambiguous information and reference document.

Even if a model is used for documenting and producing the architecture, the architect gives great care to the nature[^15] of the reports to be generated; in fact these documents constitute the basic reference for the evaluation of the model.

Outputs

During this phase the architect team provides the following documents and artefacts.

  1. An updated version of the architecture model with the appropriate views, the artefacts must match the alternatives that have been identified.

  2. A list of alternatives with the views considered.

  3. The documents for supporting the realization of the system and its delivery.

The views provide answers to the questions (raised by the vision) and describe alternatives and options to be assessed later. Options translate strategic, operational, technical, service and/or programmatic options. The following elements could be provided in line with the Architecture Management Plan:

  • A Draft architecture report capturing the portfolio as tailored in the vision and earlier phases.

  • The alternatives of architectures with the appropriate views,

  • When necessary, a proposal to update / enrich refine the vision drivers and the architecture management plan.

During this phase the architect conducts most of the effort for developing the architecture documents. The architecture must meet the needs described in the vision; for instance procurement, realization, evolution or definition. The architect defines the right granularity to describe architecture elements. The delineation between “black box” and “white box” allows limiting the development effort. A basic question is: “do I need to open this black box for providing another black box description[^16]? Which elements will be highlighted by this effort?”

The architecture team document[^17] architecture findings so as to enable their validation by the stakeholders, and to ease decision making at governance level. The validation of a model is completed by the validation of the associated documentation.

The following diagram describes the views of the grid to be considered for this stage.

Zones of the Grid used in the Describe Alternatives of Architecture Stage
Zones of the Grid used in the Describe Alternatives of Architecture Stage

The following views will be started, developed or refined

NAF v4 views NAF V3 views ——————————– ———————————————————————– AMP Architecture Management Plan NAV-1 Overview and Summary Information (architecture management plan) A5 Architecture Status
A1 Meta data definition NAV-3a, Architecture Compliance Statement (Meta Data) NAV-2Integrated Dictionary C2 Enterprise Vision NCV-1, Capability Vision C1 Capability Taxonomy NCV-2, Capability Taxonomy Architecture Concept Diagram NOV-1, High-Level Operational Concept Description L2 Logical Scenario NOV-2, Operational Node Connectivity Description L3 Nodes Interactions NOV-3, Operational Information Requirements L4 Logical Activities NOV-5, Operational Activity Model L7 Logical Data Model NOV-7, Information Model S1 Service Taxonomy NSOV-1, Service Taxonomy ) S3 Service Interfaces NSOV-2, Service Definitions P2 Resource Structure NOV-4, Organizational Relationship Chart P2 Resource Structure NSV-1, System Interface Description ( including Human and Technical Aspects of the capability ) P1 Resources Types NSV-2, Systems Communication Description P4 Resource Functions NSV-4, System Functionality Description NSV-11a, Logical Data Model

                              Lines of development   -----------------------------------------------------------------------------------------
The L3 Nodes Interactions View
The L3 Nodes Interactions View
The L4 Logical Activities View
The L4 Logical Activities View
Logical Data Model View
Logical Data Model View
The P4 Resource Functions View
The P4 Resource Functions View
The P7 Physical data model View
The P7 Physical data model View
The Lr Lines of Development View
The Lr Lines of Development View

Evaluate Alternatives of Architectures and perform trade-off

During this phase the architect reviews the architecture against principles, vision and other criteria (costs, legacies, capabilities and other elements) in order to identify if a faster, a more effective or a more efficient delivery of the system is possible.

The review of architecture provides an updated vision and a list of trade-off grouped by Alternatives of Architectures.

The trade-off enables to check and assess the alternatives for considering “what if” scenarios (what if the costs reduction are the key factor? What if shorter delays are needed?). More important, this phase enables to identify the technical questions and to secure the delivery of the solution.

Pre-requisite

  • The criteria and the concerns for securing the delivery of architecture are delivered.

  • Alternatives of Architecture include confirmed key drivers, constraints, weights (priorities, criticality, etc.).

    • The dimensions of the evaluation criteria are available (costs, effectiveness, politics, force structure, schedule, risks, flexibility, budget, TCO…)

    • The weights and measurements of the values associated to each criterion are available.

  • Up-to-date vision and the architecture framework and principles are available

Activities

The architect lists the criteria for supporting the evaluation. The architect:

  • Captures the concerns which can have an impact on the delivery of the project.

  • Produces the views, mostly matrices which support the evaluation of the architectures.

  • Prioritizes the criteria and weights each criterion in order to facilitate the assessment.

  • Determines/confirms the architecture evaluation grid.

  • Conducts the evaluation and the comparison w.r.t architecture goals and objectives.

  • Determines trade-offs that optimize (weighted) objectives.

  • Assesses trade-off architecture w.r.t key drivers and constraints.

The architect builds an assessment view of architecture alternatives, highlighting the compliance of each to planning assumptions and constraints. The architect builds an assessment matrix for identifying the best trade-off (this assessment matrix is not included in the portfolio of NAF views).The architect issues an assessment report on the trade-off highlighting the selected trade-off.

Outputs

This stage enables the production of an Evaluation report with an assessment grid including:

  • The score of (identified and assessed) alternatives of architecture against the selected criteria

  • The list of the trade-off and the precise definition of their contents…

  • The list of alternatives and their measurement against the trade-off (trade off criteria: TRL, effectiveness, efficiency, costs, delays…)

  • The selected trade off, stated and approved. It will be used as driver for the new baseline.

  • The list of views and the contexts to change in the future architecture baseline are clearly stated in the report.

  • The evaluation report is presented to the architecture board for decision on the trade-off.

The following diagram describes the views of the grid to be considered for this stage.

Zones of the Grid used in the Evaluate Alternatives of Architecture Stage
Zones of the Grid used in the Evaluate Alternatives of Architecture Stage

NAF v4 views NAF V3 views ————————————- ————————————————————————————- A8 Standards NTV-1, Technical Standards Profile NTV-2, Technical Standards Forecast C1/S1 Capability to Service Mapping NCV-5, Capability to Organizational Deployment Mapping C1/S1 Capability to Service Mapping NCV-7, Capability to Services Mapping C4 Standard Processes NCV-6, Capability to Operational Activities Mapping For a specific Scenario L5 Logical States NOV-6b, Operational State Transition Description L6 Logical Sequence NOV-6c, Operational Event-Trace Description L7 Logical Data Model NOV-7, Information Model L8 Logical Constraints NOV-6a, Operational Rule Model P1 Resources Types NSV-2, Systems Communication Description P2 Resource Structure NSV-1, System Interface Description P5 Resource States NSV-10b, Systems State Transition Description P6 Resource Sequence NSV-10c, Systems Event-Trace Description P7 Physical data model NSV-11b, Physical Data Modelling the transition architecture and the Migration Plan P8 Resource Constraints NSV-10a, Systems Rule Model S4 Services Functions NSOV-3, Services to Operational Activities Mapping S6 Service Interactions NSOV-4, Service Orchestration Target A8 Standards NTV-1, Technical Standards Profile + NTV-2, Technical Standards Forecast L4/P4 Activity to Function Mapping NSV-5, Systems Function to Operational Activity Traceability Matrix P1 Resources Types NSV-2, Systems Communication Description P2 Resource Structure NSV-1, System Interface Description P3 Resource Connectivity NSV-2b, System to System Port Connectivity +NSV-2c, System Connectivity Clusters P1 Resources Types NSV-2a, Systems Communication Description P4 Resource Functions NSV-3, Systems to Systems Matrix Pr Configuration management NSV-8, Systems Evolution Description

The C1/S1 Capability to Service Mapping View
The C1/S1 Capability to Service Mapping View
The C4 Standard Processes View
The C4 Standard Processes View
The L4/P4 Activity to Function Mapping View
The L4/P4 Activity to Function Mapping View
The L5 Logical States View
The L5 Logical States View
The L6 Logical Sequence View
The L6 Logical Sequence View
The L8 Logical Constraints View
The L8 Logical Constraints View
The P1 Resources Types View
The P1 Resources Types View
The P5 Resource States View
The P5 Resource States View
The P6 Resource Sequence View
The P6 Resource Sequence View
The P8 Resource Constraints View
The P8 Resource Constraints View
The Pr Configuration management View
The Pr Configuration management View
the S4 Services Functions View
the S4 Services Functions View
The S6 Service Interactions View
The S6 Service Interactions View

Plan Migration

This stage will enable the development of a migration plan based on the aggregation of transition architectures[^18] which consolidate implementation projects. The architect acts as a coordinator supporting the sponsor in order to guarantee a feasible and manageable trajectory achieves the realization of the solution[^19]. The outcomes of this stage will allow governing the implementation/allocation according to the roadmap.

The migration plan is an input for updating other documents like the Project Management Plan (PMP) or the System Engineering Management Plan (SEMP) of the “Yellow solution for SAR” through one or several baselines. The architecture views describing the baselines can be issues according two options:

  • Either the Architecture views related to the Migration Plan describe either a specific baseline (E.g. Pr (NSV-1))

  • Or the views describe Lines of development (trajectories/roadmaps) crossing baselines (E.g. NCV-3, NSV8, NSV-9, NTV2 [NAF v4 names here]).

Baselines could be expressed with conceptual, logical or physical approach (Capability provision, Service provision, asset delivery/allocation).

Pre-requisite

  • The architecture development is completed.

  • The portfolio of AoA is available, trade-offs have been proposed and the agreed trade-off has been selected.

  • The list of concerns and options guiding the AoA are in the architecture repository,

  • The AoA evaluation report has been produced

  • The baseline of guiding documents are available

    • Architecture contract.

    • Architecture management plan.

    • Vision.

    • Architecture repository.

Activities

The architect receives the information on the implementation of the solution. This information consists in legacies, deployment of implementation projects or systems and future capabilities which need to be blended for building the solution.

The architect aggregates the information in coherent chunks describing the transition from one step to another, and aggregates transition architectures in a coherent migration plan according to the selected architecture roadmap. The architect ensures the changes applicable to architecture are issued and managed.

The work packages and the roadmaps are presented to the sponsor and to the stakeholders in order to ensure their buy-in

Outputs

  • Updated Architecture Definition

  • Preliminary WBS, PBS, Roadmaps and Implementation Plan for the impacted projects

  • Transition architectures

  • Migration Plan

  • Approved WBS including the list of work packages (provided at sub system level)

  • Approved Roadmaps

  • Architecture changes requests.

  • Approval of the migration plan by the sponsor.

The following diagram describes the views of the grid to be considered for this stage.

Zones of the Grid used in the Plan Migration Stage
Zones of the Grid used in the Plan Migration Stage

NAF v4 views NAF V3 views —————————- ————————————————————————– A5 Architecture Status] NAV-1 Overview and Summary Information and architecture management plan A6 Architecture Versions] NAV-1 Overview and Summary Information and architecture management plan A8 Standards NTV-1, Technical Standards Profile + NTV-2, Technical Standards Forecast Ar Architecture Roadmap NAV-1 Overview and Summary Information and architecture management plan C2 Enterprise Vision NCV-1, Capability Vision C3 Capability dependencies NCV-4, Capability Dependencies Cr Capability Roadmap NCV-3, Capability Phasing P1 Resources Types NSV-1, System Interface Description

Table : The A5 Architecture Status View

The A6 Architecture Versions View
The A6 Architecture Versions View
The Ar Architecture Roadmap View
The Ar Architecture Roadmap View
The C3 Capability dependencies C3 Capability dependencies view
The C3 Capability dependencies C3 Capability dependencies view

Govern Application of Architecture

The aim of this stage is to check that the migration plan is applied by the projects and that the situations requiring changes are correctly identified and notified towards the architecture board as a delta to the architecture baseline (e.g. changes to views describing the baselines including roadmaps/trajectories: P2 A5 and A6 at least, Cr, Pr, P1, A8).

Based on the evaluation report, the architect updates the architectures, if required, in order to implement the migration plan. The objectives of this phase aim at:

  • Ensuring the implementation projects impacted by the WBS and Roadmaps are aligned with the architecture including architecture products (interfaces, constituents, interactions and configurations)

  • Performing the functions for governing the implementation of the architecture

The approach for governing the application of architecture includes the following activities:

  • Identify the connections between the WBS[^20] and Roadmap with their components, work packages, deliverables, products and milestones, in order to ensure the synchronization between:

    • The architecture contents,

    • The scheduling,

    • The WBS, PBS[^21], Roadmaps and the list of CI[^22].

  • Check that the architecture management plan and the architecture contract support the adherence and includes the verification mechanisms between the implementation and the architecture.

Pre-requisite

  • The architecture is delivered,

  • The migration plan is delivered

  • An agreed WBS, PBS and Roadmap are available and shared,

  • All the deliverables of the preceding phases are stored in the architecture and in the project repositories.

The architect owns the architecture evaluation report (in the architecture repository) describing:

  • Confirmed drivers and constraints

  • Confirmed architecture trade-off, hypotheses and rationale

  • Descriptions of alternatives of architecture: capability, operational, system, technical, phasing, and mapping views

  • Trade-off report

Activities

The architect conducts the following steps in order to govern the architecture.

  • Confirm the scope and priorities,

  • Identify resources and skills needed,

  • Guide the development of the solutions according to the migration plan,

  • Perform compliance reviews,

  • Perform post-implementation reviews and close the implementation.

  • Review trade-off report and confirm consistency with drivers and constraints

Outputs

The following outputs will be delivered at the end of this phase.

  • (New version of) architecture contract and portfolio baseline

  • Updated architecture management plan

  • WBS, PBS, Roadmaps and Implementation Plan

  • Populated architecture repository

  • Change requests

  • Architecture vision (post-implementation)

Zones of the Grid used in the Govern Application of Architecture Stage
Zones of the Grid used in the Govern Application of Architecture Stage

NAF v4 views NAF V3 views ————————— ————————————————————————————- A2 Architecture Products NAV-3b, Metadata Extensions + NAV-3a, Architecture Compliance Statement (Meta Data) A5 Architecture Status NAV-1 Overview and Summary Information and architecture management plan A8 Standards NTV-1, Technical Standards Profile + NTV-2, Technical Standards Forecast Ar Architecture Roadmap NAV-1 Overview and Summary Information and architecture management plan C7 Performance Parameters NCV-1, Capability Vision C8 Planning Assumptions Cr Capability Roadmap NCV-3, Capability Phasing Lr Lines of Development NPV-2, Program to Capability Mapping P1 Resources Types NSV-1, System Interface Description P2 Resource Structure NSV-2, Systems Communication Description P5 Resource States NSV-10b, Systems State Transition Description P6 Resource Sequence NSV-10c, Systems Event-Trace Description P7 Physical data model NSV-11b, Physical Data Modelling the transition architecture and the Migration Plan P8 Resource Constraints NSV-10a, Systems Rule Model Pr Configuration management NSV-8, Systems Evolution Description Sr Service Roadmap

The A2 Architecture Products View
The A2 Architecture Products View
The C7 Performance Parameters View
The C7 Performance Parameters View
The Sr Service Roadmap View
The Sr Service Roadmap View

Decide on Architecture Change

Based on the precedent work aiming at defining a new baseline, the architect assesses the work to be done on architecture and, if needed, initiates a change request and presents it to the Architecture Management Board, in order to engage another architecture development cycle.

The following cases can trigger a change:

  • The capability is not effective enough, or it does not meet the operational requirements, or the objectives included in the vision. The description of the capability is not aligned with the architecture management plan.

  • Critical constraints (RAMS, budget and work-share) are not met.

  • The alignment of the new baseline is above the responsibility of the architecture team. Some skills, budget or planning adjustments are required.

The architect provides a basis for definition of a change including:

  • A description of the change.

  • The adjustments to the plan.

  • The adjustment to the architecture management plan.

  • The updated architecture contract

These documents are presented to the Architecture Management Board for approval.

Activities

The architect:

  • Conducts a gap analysis

  • Formalizes the architecture changes requests

  • Presents the changes and obtains agreements within an architecture board meeting.

  • Baselines architecture change requests as agreed at Architecture Board Meeting.

Outputs

The architect provides the following documents:

  • A description of the change.

  • The adjustments to the plan and the assessments of the impacts to consider.

  • The adjustments to the architecture management plan.

  • The updated architecture contract.

The architecture management plan must capture the gap analysis statement, the architecture decisions agreed in the architecture board and they are stored in the Architecture Motivation Data definition repository…

The following elements are stored in the repository

  • The gap analysis

  • The change request agreed with resources updated (Budget, timelines, new scope, skills…)

  • A new version of architecture baseline stored in the repository

  • Preliminary Architecture development Plan stored in the repository

  • Notification of changes published towards architecture Stakeholders

The nature of the change request impacts the views and architecture products to be used.

Input Views

  • Any product of interest in the architecture repository.

Output Views

  • All Views and perspectives impacted by architecture change.

  • The nature of change may address capabilities, system or capability milestones, functions, services, organization, activities, etc.

Outputs are either

  1. Stop here.

  2. Iterate[^23] through an update of the Architecture vision and the following consequence of the vision update.

Manage Architecture, Dashboards and Motivation data

The aim of this stage is to set and maintain architecture up-to-date motivation data to feed the dashboard, monitor architecture progress and stop/continue activities according to enterprise directives. Motivation data translate project stakeholders’ expectations into measurable objectives to allocate to architecting activities. Key factors are considered to drive analyses and decisions.

This stage is executed after each stage of the architecture development method. It allows cross-checking goals, objectives, requirements and motivation along the execution of the project.

For the yellow country, the architect cross-checks after each stage that:

  1. The capability lists, objectives and the capabilities covered by the SAR solution remains lined-up,

  2. Requirements on the SAR System remain consistent and SMART.

  3. The Requirements are well allocated.

This stage prevents the derivation of the project from architecture objectives. It ensures that changes are recorded and their impact assessed against requirements.

This stage bridges the stages related to architecture development and the stages focusing on the delivery of the system.

The stage focuses on:

  1. Capabilities: for maintaining the architecture in line with the other aspects of the acquisition process.

  2. Requirements: For maintaining the specification and the description (both key elements of the acquisition) aligned.

  3. Constraints and metrics: For ensuring all information remains under control and included in the architecture development.

Pre-requisite

The architecture team builds a documentation baseline on the following domains:

  • Capabilities: the capabilities are gathered in a coherent set of lists with specifications, roadmaps and definition documents. The stage “Set Architecture motivation data” ensures that a reliable list of capabilities is used for guiding the architecture development and that the elements of the architecture development, when needed, are integrated in the capabilities lists[^24].

  • Requirements: The requirements support the specification of the capabilities to be met by the system of the capability level architecture. Requirements bear the quantitative description of the system. Hence a strong link must be maintained between the architecture and the requirements.

  • Major inputs

    • Yellow architecture landscape,

    • Architecture KPIs

    • Yellow SAR vision

    • Elements of planning for delivering the Yellow solution (where to stop , when to issue the baselines)

    • A baseline of requirements at appropriate level

Activities

The architect, after each phase:

  • Ensures that an agreement exists on the definition of the capabilities factors and their weights,

  • analyses top level requirements

  • checks the consistency of the existing capability lists and the requirements attached,

  • Maintains an effective and technically coherent management of the baselines of capabilities and requirements.

A consistent set of requirements and capability lists is maintained by the architect and kept under configuration management.

Outputs

The architect ensures the following elements are kept updated:

  • List of selected/discarded/changed factors (or any of the motivation data)

    • List of maintained/discarded top level requirements

    • List of maintained /discarded objectives

    • List of maintained/discarded milestones

The outputs are managed in consist in configuration management and version control modules.

Zones of the Grid used in the Establish Architecture Landscape Stage at Project level
Zones of the Grid used in the Establish Architecture Landscape Stage at Project level

A requirement database is the key asset for managing motivation data and dashboard.

NAF v4 views NAF V3 views ———————— ——————————————————— C1 Capability Taxonomy NCV-2 Capability Taxonomy C2 Enterprise Vision NCV-1, Capability Vision S1 Service Taxonomy NSOV-1, Service Taxonomy + NAV-2, Integrated Dictionary S3 Service Interfaces NSOV-2, Service Definitions