Development of the Project architecture

The Yellow country based on the national Capability Level Architecture and on the Rainbow documents on architecture develops a contract for the acquisition of a system for Search and Rescue .A Project architecture will be the cornerstone of the technical part of the contract.

The oroject architecture (PLA) :

1. Describes the system to develop;

2. Describes the interfaces with the existing and future systems;

3. Describes the acquisition process[^25];

4. Specifies the system elements of the system (CI[^26]);

5. Describes the operational environment of the system and its capabilities.

The Project architecture is delivered as part of the contract. The contractors will document this architecture and demonstrate the compliance to the stakeholders’ needs, to the requirements and to design constraints.

The architect and his team will execute the 8 stages of the NAF method at project (Target) level

Establish the architecture landscape

This stage establishes the architecting capability according to expectations and context, scope and target of the project. A set of assumption are considered:

• There is capability for architecting,

• a repository of information exists.

The architect uses the architecting capability and draws the resources, means and references of the scope for the development of the project architecture.

The approach includes:

• The identification of the references for issuing a statement of work for architecture,

• Outline of architecture contract and architecture management plan.

The architecture management plan defines the following references documents:

• Context and constraints of the project, in particular, the links between the existing references and project architectures,

• Capabilities, operational needs, acquisition process, limits, constraints, tools and standards,

• Links between architecture and other disciplines like system engineering, requirements management, project management, etc.

• Localisation and accesses to the architecture development repository.

• Definition of skills, people and resources for conducting architecture activities.

Prerequisites

The following pre-requisites are met for engaging this stage:

• Context, drivers and constraints are available

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

• Capability Level Architecture scope and expectations are precisely fixed Architecture method and tools: Norms, Standards, know-how necessary to describe, to assess and to compare architecture alternatives are determined and available in the architecture team,

• An Architecture repository (accessible to the architecture team as agreed with the support teams), to store and manage documented architecture is defined and implemented.

• The Capability architecture related to the domains addressed by this architecture project exists at national and multinational levels.

Activities

From the Capability Level Architectures the architect checks he has all elements for setting-up the architecture resources at project level and that the appropriate information is available:

• Architecture scope (Yellow Country), relationship with the architecture developed at Rainbow level related to the execution of the maritime surveillance?

• Elements to be provided:

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

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

• Legacies: List of existing systems with date of obsolescence. The portfolios are used as inputs for providing this information (technological and products for existing projects).

The architect analyse architecture requirements within the contract in order to define expected architecture products. Following questions are

• Is the architecture work a deliverable of the contract?

• Which parts of the architecture work are concerned? For instance, an operational concept document may be elaborated to orient architecture work, even if not specified in the list of main deliverable.

• Which architecture views support architecture activities?

The Project architecture is here limited to the implementation of functions of search and rescue, based on the functions identified in the capability architecture of Yellow and Rainbow.

Stakeholders agree to the decisions made regarding :

• The architecture tools,

• The Method,

• The links with other disciplines useful for the definition of the system (SE, Requirements Engineering),

• The inputs and references of Rainbow community.

The architect defines the criteria for selecting the views, using architecture principles. This activity aims at selecting the grid rows and columns of relevance for meeting the architecture management plan objectives.

The stakeholders define the criteria for assessing alternatives:

• Operational criteria,

• System criteria,

• Standard criteria,

• Costs.

The architect defines the content of the architecture statement of work, of the architecture management plan and the structure of the architecture repository (accessible for architecture team as agreed with support teams) storing the documented architecture.

• The architect identifies the architecture products to store in the repository.

• The architect defines the complimentary information used for documenting the architecture products.

Outputs

The outputs consist in the A1[^27] (Initial) with an outline of the architecture management plan which supports the issue of a statement of work. The architecture management plan addresses the following points:

• Description of the architecture capability[^28] in terms of organization, processes, resources, tools and principles.

• The process of architecting: description of the tailoring of the methodology and the need for selecting complementary architecture frameworks.

• The architecture charter

  • Methodology, Framework, References (Operational, system, technologies, services, capabilities).

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

• A project schedule identifying the main phases of the development.

• Support tools (modelling and requirements): for defining, selecting, preparing and adapting the tools.

• The management of the documentation and the configuration[^29] rules to be enforced in the project.

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

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-2 Integrated Dictionary C1 Capability Taxonomy NCV-2 Capability Taxonomy C2 Enterprise Vision NCV-1, Capability Vision Architecture deliverables AMP Architecture Management Plan (Outline)

Establish Architecture Vision

During this phase the architect aggregates the elements of the architecture in order to provide a detailed vision of the system to deliver and he documents it in the architecture management plan. The goal of the vision stage is to obtain the approval of the sponsor of the project and his buy-in. The elements complementing the outline of the architecture management plan will answer the following questions:

• What are the scope and the content of the system?

• Who does what for defining the system?

• Where is the work executed?

• When the work is executed (schedule)?

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

• What is the trajectory considered for building the system?

• Why is this job executed?

• What is the end state to achieve when the system is delivered?

The elements related to decisions, authority, results and acceptance of the architecture are included as high level descriptions of the system in a communication plan.

Objective

The stage “Establish architecture vision” provides a context for describing the system to deliver in terms of capabilities, operational activities, system functions, system elements, data, interactions and other aspects[^30] related to the implementation. It includes these descriptions in the project architecture. This stage confirms that the statement of work and the outline of the architecture management plan are complete, well understood and supported by the stakeholders.

The following key drivers direct the execution of the stage Architecture Vision.

• Provide a solution for search and rescue,

• Deliver a solution compliant with standard rules,

• Conduct Monitoring surveillance and information sharing for supporting search and rescue.

• Address airborne and maritime search and rescue teams.

The following options support the definition of the purpose of the architecture effort:

• Deliver a solution compliant with the performance and design requirements of search and rescue systems as defined in the Capability Level Architecture,

• Provide a solution re-using the legacies and increasing the coordination of search and rescue activities in the Yellow country and between the nations,

• Provide a roadmap for contracting synchronizing the “delivery time”(milestone) of the capability with the Yellow country milestones (from the CLA[^31]),

• Provide the information for the acquisition.

The architect defines the key drivers for example:

• Operational drivers:

  • Increase effectiveness of the systems of search and rescue,

  • Optimize the liaison with the civilian actors

  • Optimize the liaison with the security actors,

• Baseline for interoperability :

  • Maximizing the use of AIS

  • Optimize the Interoperability with air traffic

  • Optimize the Interoperability with Emergency actors

The architect builds a consolidated report describing the vision, work share, deliverables. The elements of the architecture descriptions are grouped in a communication plan.

Prerequisite

The repository and the architecture landscape is in place, the CLA are included in the architecture repository, the resources are sufficient, for conducting the stage.

The Architecture board is nominated (officially) and has agreed on the architecture management plan work within available budget.

Steps

• Confirm/Update stakes, context, constraints,

• The architect checks the objectives of the architecture contract.

• The architect checks the capabilities, operational functions, drivers, objectives and key level information needed for developing the PLA[^32].

• The architect confirms the list of stakeholders and the information they can provide.

• The architect provides the appropriate answers, if the change implies the redefinition of the system or of one of its parts, (change of manning, change of resources, new areas or interoperability challenges to consider).

• The architect confirms the tailoring of the views and of the architecture products or of the process (process for architecting.)

• The architect selects the portfolio of views based on the grid…

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

• The architect identifies the work streams to execute for delivering the portfolio.

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

Outputs

This stage enables the delivery and the approval of the following documents:

1. An architecture definition document or ideally an architecture management plan,

2. A first iteration of the A5 establishing the foundation and the scope for the architecture development,

3. A synthetic narrative of the vision

The architect develops an architecture management plan including at minimum the following elements

• High-level scope for the architecture, using text-based capability goals.

• 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.

• Communication plan.

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 C1 Capability Taxonomy            NCV-2, Capability Taxonomy ACD Architecture Concept Diagram  NOV-1, High-Level Operational Concept Description L2 Logical Scenario               NOV-2, Operational Node Connectivity Description S1 Service Taxonomy               NSOV-1, Service Taxonomy S3 Service Interfaces             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)

Describe Alternatives Architectures

This stage is the more concrete activity in the development of the architecture. It embraces the production of the architecture products (views and documents) describing the “to be “system. This stage ensures that the description is fully aligned with the vision and includes the different options of the implementation. The alternatives of architectures (AOA) consist in a limited architecture work –usually a scenario- answering a typical stakeholder’s concern.

The architecture development is complete at the end of this stage. The views are included in an architecture report.

Pre-requisite

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

• The vision has been published and is agreed by the sponsor.

• The architecture management plan is published and agreed. The resources for developing the architecture are funded, manned and equipped.

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

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

• The CLA[^33] for developing the PLA[^34] are shared. The architect has a list of views to be developed for each domain (communication, IT, information, and operational activities), each type ( Business , Information, Application and Technology architectures). 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.

• Drivers for identifying the possible AoA are available.

Activities

The architect, based on the available documents, develops the views describing the system. The architect aligns the design of the solution to a to down description of the capabilities and operational views. The architect identifies the options or alternatives to the top down description and documents them in specific views. The architect uses a tree structure[^35] for detailing the operational functions, capabilities, services, system functions, system elements and other information elements to be captured in the architecture work. The grid links the views, the information elements and the concerns. For the project architecture, the architect focuses on concerns related to implementation and to links with the existing capabilities and processes; the architecture is more concrete, easy to check and traced back to requirements. The following cycles can be considered for developing the architecture

1. Confirm/ update architecture drivers (qualitative assessment)

2. Identify possible AoA,

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

4. Confirm / update the list of views (based on the grid),

5. Develop architecture views including the mapping between views and resources. (“As is” and “To be”)

The architecture team produces the views according to the specific perspectives and viewpoints selected in the grid. It will bear in mind the need to limit the develop effort to the “good enough” solution in order to avoid over-specifications. The architect, for the Project architecture, limits his work to the “system only” perspective and avoids pushing the description to a sub-system element level.

The views are produced by the following artefacts:

1. Tables, lists

2. Narratives

3. Diagrams

4. Matrices,

The architect beaks-down 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: each object of the architecture must be correctly and completely documented with an explicit and unambiguous information and reference link[^36].

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.

2. A list of alternatives and their description ,

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

According to the architecture management plan, the following elements could be provided:

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

• The scenarios related to the alternatives of architectures with the appropriate views,

• The vision drivers and the architecture management plan which have been updated, if necessary.

During this phase the architect conducts most of the effort for developing the architecture documents.

The architect must bear in mind the importance of the granularity to consider for describing the elements of the architecture. The delineation between the description in “black box” and “white box” must be the driver for limiting the development effort. A basic question could be “do I need to open this black box for providing another black box description? What is highlighted by this specific architecture decomposition?”

The architect gives a great care to the documents to be validated by the stakeholders. The validation of a model is very difficult and can be completed, only through the validation of the documentation which is generated by the modelling tool.

NAF v4 views NAF V3 views ———————————– ————————————————————- AMP Architecture Management Plan\ NAV-1 Overview and Summary Information (AMP) A5 Architecture Status
A1 Meta data definition NAV-3a, Architecture Compliance Statement (Meta Data) NAV-2Integrated Dictionary 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 ————————————————————————————————-

Evaluate Alternatives of Architecture and propose a trade-off

During this stage, the architect assesses the options for reducing costs, de-risking the acquisition, ensuring the adequate solution is delivered and an easy acceptance of the system. He evaluates the compliance level of the architecture with the stakeholders and system requirements.

The architecture is usually developed with a main track and alternatives, the architect identifies the “what if” scenarios supported by the alternatives and the related trade-off.

The review of architecture provides an updated vision and a series of trade-off grouped by Alternatives of Architectures. The criteria used for identifying the AoA are confirmed key drivers , constraints and confirmed weights (priorities, criticality, etc.)are the.

The trade-off enables to check and assess the alternatives against criteria in order to consider “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 key technical questions and to secure the delivery of the solutions.

Pre-requisite

• The key criteria for securing the delivery of the architecture are delivered. The concerns influencing the project have been identified by the stakeholders. Architecture alternatives are described, with key drivers and constraints including confirmed weights (priorities, criticality, etc.)

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

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

• If need be an Up to date shared vision and the architecture framework and principles are available.

Activities

The architect builds a list of criteria and weights them. Some examples of criterion are

• Costs reduction;

• Assessment of the level of resources needed for developing each component;

• Assessment of the parts which can be outsourced and the one requiring sole source acquisition;

• Insurance of meeting the requirements and the expected capabilities;

• Identification of options for better meeting the requirements;

• Identification of the dependencies against some of the capabilities components;

• Insurance that the timelines will be met;

• Make or buy decisions;

• Technical options;

• An evaluation grid captures the evaluation and the options considered;

A report describes the options selected for developing AoA.

The architect:

• groups the AoA according to the planning options and builds only the views related to AoA.

• builds an assessment matrix for each trade-off.

• issues an assessment report on the trade-off highlighting the selected trade-off leading to some options on the delivery of the solution.

Outputs

The architect issues an evaluation report describing the main options for mitigating the risks in the PLA and in the system. This report includes the score of (identified and assessed) alternatives of architecture, the list of the trade-off and the precise definition of its contents, the list of alternatives and their measurement against a trade-off off (trade off criteria: TRL, effectiveness, efficiency, costs, delays…).

Each selected trade-off is clearly stated when approved. It will be used as driver for development of the AoA. The list of views and the contexts to change in the future architecture developments are clearly statedin the report. The evaluation report is presented to the architecture board for decision on the trade-off.

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 ( This view is to be done) C1/S1 Capability to Service Mapping NCV-7, Capability to Services Mapping C4 Standard Processes NCV-6, Capability to Operational Activities Mapping (this is to be refined) 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 Project architecture 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

Plan Migration

This stage will enable the development of a migration plan based on the aggregation of transition architectures[^38] 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[^39]. 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 “solution” 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]).

This stage enables the delivery of work packages, roadmaps and a work breakdown structure for a coherent realization of the system. The architect assesses the WBS[^40], a list of CI, a Schedule of delivery or a roadmap for delivering the system. The Work packages can consist in the following elements:

1. Infrastructure

2. Core services

3. Service management and control

4. Information Assurance

5. User services

6. Operational services

The architect coordinates the work packages supporting the architecture.

The Project architecture provides the list of work packages and the roadmap.

Pre-requisite

• The architecture development is completed,

• The portfolio of AoA is available,

• 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 is available

• Architecture contract,

• Architecture management plan,

• Vision,

• Architecture repository.

Activities

The architect assesses the list of configuration items included in the system elements. They have been grouped in coherent packages and allocated to providers for supporting the integration, by the work packages owners.

The work packages are allocated to sub-system level providers. The work packages and the roadmaps are presented to the sponsor and to the stakeholders in order to ensure their buy-in.

Iteratively, the stakeholders synchronize the roadmaps and the WBS. The agreed and synchronized WBS/Roadmaps packages are presented to the sponsor for official approval.

Outputs

• Approved WBS including the list of work packages

• Approved Roadmaps

  • Updated Architecture Definition

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

  • Detailed implementation plan

  • Detailed migration plan

  • List of possible CI

  • Change requests

NAF v4 views NAF V3 views —————————- ————————————————————————– A5 Architecture Status) NAV-1 Overview and Summary Information and AMP A6 Architecture Versions NAV-1 Overview and Summary Information and AMP A8 Standards NTV-1, Technical Standards Profile + NTV-2, Technical Standards Forecast Ar Architecture Roadmap NAV-1 Overview and Summary Information and AMP 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

Govern Application of Architecture

During this phase, the architect updates the architectures according to the evaluation report (ref. Establish Alternatives architectures and get trade-off). The objectives of this stage are:

• Ensuring that the implementation projects impacted by the WBS and the Roadmaps are aligned with the architecture,

• Performing the functions for governing the implementation of the architecture in the system.

The approach for governing the application of architecture includes identifying the connections between the WBS and the Roadmap, in order to ensure the synchronization between:

• The architecture contents,

• The scheduling,

• The WBS, PBS[^41], Roadmaps and the list of CI[^42].

The architect checks that the architecture management plan, the project architecture and the architecture contract support the implementation of the system. The architects confirms that each sub-system identified is associated to a WBS, a PBS, roadmap and costs for ensuring that each sub-system element can be achieved.

Pre-requisite

• The architecture is delivered,

• WBS[^43], PBS and Roadmaps are available and shared.

• The architecture evaluation report has been approved.

• The Trade-off report has been delivered and approved.

Activities

The architect:

• Conducts the following steps in order to govern the architecture.

• Confirms the scope and the priorities.

• Identifies the resources and the skills needed for implementing the system.

• Supports compliance reviews.

• Supports post-implementation reviews which close the implementation.

• Reviews trade-off report and confirms its consistency with the drivers and the constraints.

Outputs

The following outputs are delivered at the end of this phase.

• An updated architecture contract

• WBS, PBS, Roadmaps and Implementation Plan

• A Populated architecture repository

• The list of change requests

• The Architecture vision post-implementation

• A Migration Plan

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

Decide on architecture change

The list of changes is gathered and the architecture management board assesses the changes to be done and it engages the management procedures.

The following cases can trigger a change:

• The performances are not met, the interfaces need further development, the tests planned are not conclusive and need to be refined and complemented.

• 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.

Activities

The architect performs the following tasks

• Gap analysis,

• Formalization of architecture changes requests,

• Presentation of the changes and obtain agreements within an architecture board meeting,.

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

Outputs

The architect provides the following documents:

• A description of the change including the adjustments to the roadmap and to the architecture management plan.

• The updated architecture contract

The AMP is updated for capturing the gap analysis statement. The architecture decisions agreed in the architecture board are stored in the Architecture Motivation Data definition repository.

The following elements are stored in the repository:

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

• Preliminary Architecture development Plan stored in the repository

• Notification of changes published towards architecture Stakeholders

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

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 NADM. It authorizes to cross-check that goals, objectives, requirements and motivation data remain aligned with the execution of the project.

This stage is repeated between phases of the architecture development. The architect will use the following techniques for consolidating the delivery of the Project architecture :

1. Requirement engineering:

   The architect will synch-up with the requirements engineering team in order to build a coherent baseline of requirements, to allocate the requirements with the architecture elements in order to provide a coherent description and a specification of the system. The contractual requirements are linked with the Project architecture .

2. Project Management:

   The decomposition of the project is presented with consistent roadmaps and plans. This activity is conducted with the support of the architecture team for producing the requirements and traceability’s related to WBS, PBS and schedules. They are elaborated and updated in each phase of the project.

3. Risk Management:

   A risk register is maintained and linked to the changes and to the architectures. Achieving this guarantees the delivery of the contract or of the system. The risk register is kept and maintained in the architecture repository.

4. Capabilities development:

   A traceability matrix is maintained in order to ensure that the system supports a specific set of capabilities even when they change.

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 phase “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[^44].

• Requirements: The requirements support the specification of the capabilities to be met by the subject of the RA. Hence a tight link must be maintained between the architecture and the requirements.

Activities

The architect, after each phase:

• Updates the requirement databases, the risk register, the plans and roadmaps.

• Updates the list of the capabilities, checks the consistency of the existing capability lists against the requirements attached,

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

The architect maintains a consistent set of requirements and capability lists. He ensures the motivation data are managed under configuration management.

Outputs

The architect ensures the following elements are up to date:

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

  • Database of requirements with Validation Cross Reference Index

  • Database of capabilities with definitions and links to operational functions and activities.

  • Plans and roadmaps for implementation

  • Risk register.

All these deliverables are stored in the architecture repository under configuration management.

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