Architectural Description

One of the major challenges of large projects with multiple stakeholders is the documentation to help various stakeholders understand the characteristics, features and design of the system, and to establish a common reference among parties involved in the deployment, operation, maintenance and support of the system. The ISO/IEC/IEEE 42010:2022¹ Architecture Description (AD) international standard helps organisations to express and document architecture descriptions of large and complex systems in a standardised manner.

Every complex system has multiple stakeholders across the federated digital ecosystem. Expressing a system’s architecture using AD will help all the stakeholders to understand its evolution, composition, behaviour and maintainability. The AD methodology is useful to specify requirements of various entities, including software, systems, enterprises, systems of systems, families of systems, products (goods or services), product lines, service lines, technologies and business domains. The Architectural Description conceptual foundations² are summarised below.

AD Concepts

• A system is situated in an environment. The environment of a system may contain other systems. The system’s environment is bounded by and understood through the identification and analysis of the system’s stakeholders and their concerns. The environment determines the totality of influences upon the system throughout its life cycle, including its interactions with that environment.

• Stakeholders have interests in a system, which are expressed as concerns. Concerns arise throughout the life cycle from system needs and requirements, from design choices and from implementation and operating considerations. A concern could manifest in many forms, such as in relation to one or more stakeholder needs, goals, expectations, responsibilities, requirements, design constraints, assumptions, dependencies, quality attributes, architecture decisions, risks or other issues pertaining to the system.

• Architecture of a system constitutes what is essential about the system in relation to its environment (in an abstract form). The term system-of-interest is also used to refer to the system whose architecture is under consideration in the preparation of an AD.

• Architecture descriptions (AD) are used to express architectures for systems of interest (in a documented form). They include one or more Architecture Views that address the concerns of stakeholders. AD may include information not part of any architecture view. Examples include system overview, architecture rationale etc.

• An Architecture Viewpoint frames one or more concerns and a concern can be framed by more than one viewpoint. Examples of viewpoints are i) business/ mission viewpoint, ii) deployment viewpoint.

• Each Architecture Viewpoint has exactly one Architecture View that expresses the architecture of the system of interest in accordance with the Architecture Viewpoint and addresses the concerns framed by the governing viewpoint. Thus, a viewpoint is a way of looking at systems and a view is a result of applying a viewpoint. Examples of views are i) business/ mission view, ii) deployment view, iii) operations view.

• Architecture View is composed of one or more Architecture Models. Each architectural model is developed using the conventions and methods established by its associated viewpoint. An architectural model may participate in more than one view. Consistency between the views is maintained using correspondence rules.

• Architecture decisions pertain to system concerns. Architecture rationale records explanations, justifications and reasoning about architectural decisions. The rationale for a decision may include the basis for the decision, alternatives and trade-offs considered, and potential consequences of the decision.

• Execution views consist of a set of models that describe and document what a software system does at runtime and how it does it. The term runtime refers to the actual time that the software system is functioning during testing or in the field.

Architecting

Architecting is an activity that is performed throughout the system lifecycle within the context of a project and/ or organisation. An architecture description is a work product resulting from the execution of architecting activities within the lifecycle of the system of interest. Annexure C of ISO/IEC/IEEE 42010 demonstrates the use of architecting in the context of system and software lifecycle processes defined by ISO/IEC 15288 and ISO/IEC 12207 respectively.

Uses of Architectural Descriptions

Some of the uses of architecture description methodology by various stakeholders throughout the system life cycle are given below:

• as basis for system design and development activities

• as basis to analyse and evaluate alternative implementations of an architecture

• as development and maintenance documentation

• documenting essential aspects of a system, such as:

  • intended use and environment

  • principles, assumptions and constraints to guide future change

  • points of flexibility or limitations of the system with respect to future changes

  • architecture decisions, their rationales and implications

• as input to automated tools for simulation, system generation and analysis

• specifying a group of systems sharing common features

• communicating among parties involved in the development, production, deployment, operation and maintenance of a system

• as basis for preparation of acquisition documents (such as requests for proposal and statements of work)

• communicating among clients, acquirers, suppliers and developers as a part of contract negotiations

• documenting the characteristics, features and design of a system for potential clients, acquirers, owners, operators and integrators

• planning for transition from a legacy architecture to a new architecture

• as guide to operational and infrastructure support and configuration management

• as support to system planning, scheduling and budgeting activities

• establishing criteria for certifying implementations for compliance with an architecture

• as compliance mechanism to external and project and/or organization-internal policies

• as basis for review, analysis, and evaluation of the system across its life cycle

• as basis to analyse and evaluate alternative architectures

• sharing lessons learned and reusing architectural knowledge through viewpoints, patterns and styles

• training and education of stakeholders and other parties on best practices in architecting and system evolution.

Example of Application of AD Concepts

Application of the Architectural Description concepts to a sample project is given below. Only a subset of the concepts and requirements from the standard is used in this document after due adaptation.

A sample project is conceptualised for a ‘National Cyber Defence System’ to enable CSEs and the national nodal agencies to exchange threat related information in near real-time. The NCD System has two parts: one which addressess the requirements of CSEs (Entity NCD System) and the other which addresses the requirements of central agencies (Central NCD System). The major stakeholders of NCD system are:

A.       Acquirers/ Users - Critical Sector Entities, Central Agencies.

B.       Suppliers & Service Providers - Product OEMs, System Integrators, support, maintenance and other service providers.

C.       Development and Support Agencies - Custom application development and support organisations.

D.       Program/ Project Owner

The NCD System stakeholder concerns are addressed using the Architecture Description approach to

• help the stakeholders understand the characteristics, features and design of the system.

• establish a common reference among parties involved in the deployment, operation and maintenance of the system.

Stakeholder Concerns

The major concerns of stakeholders of NCD System (system-of-interest) are identified and listed below:

A. Critical Sector Entities and Central Agencies

1. Business/ Mission Objectives

• What purpose does the NCD System achieve towards the business/ mission objectives of the organisation?

• What is the business architecture of the NCD System?

• Do the capabilities of the NCD System align with the organisation’s business/ mission requirements? What are the challenges, risks and impact?

• What alternative solutions equivalent to the NCD System are available in the market?

• What is the investment required for prototype evaluation and production system?

2. Technology Implementation, Integration, Transition

• What is the technical architecture of the NCD System? Is it appropriate to the business/ mission purpose, scope and constraints?

• What are the deployment models of the NCD System?

• What are the components (BoM) of the NCD System?

• What are the infrastructure requirements and their sizing for implementation of the NCD System? How will they be sourced?

• What are the integration requirements of the NCD System?

• What teams and skill sets are required for implementation and integration activities? Are they available in-house or should the work be given to a SI?

• What security aspects for protection of the NCD System should be considered in this phase?

• What is the investment budget required for this phase?

3. Technology Operations and Support

• How will the NCD System infrastructure’s operational status, performance and security be monitored during the operating phase?

• What teams and skill sets are required for IT and Information Security operation activities of the NCD System? Are they available in-house or should the work be given to a service provider?

• What is the product lifecycle support for the NCD System?

• What is the investment budget required for this phase?

4. Business/ Mission Operations and Management

• How should the NCD System capabilities be exploited during the operating phase?

• How should the NCD System be configured for use by teams and groups based on their roles and responsibilities?

• How will the NCD System business/ mission functions, performance and security be monitored during the operating phase?

• What skill sets are required for carrying out business/ mission functions using the NCD System? Are they available in-house or should the work be given to a service provider?

• How will the teams be trained to use the NCD System?

B. Suppliers and Service Providers

• What products and services can be provided to critical sector entities and central agencies?

• What open source software products and solutions are being used in the NCD System? How should their product lifecycle and security be handled?

• What components of the NCD System can be sourced from Indian companies?

• What are the integration requirements of the NCD System?

• What skill sets are required of the teams providing services?

C. Development & Support Agencies

• What is the scope of NCD software lifecycle support?

• How should the software and AI/ML enhancement activities be handled and managed?

• What are the teams and skill sets required?

• What is the funding required and its management?

D. Program/ Project Owner

• How should the NCD software lifecycle be implemented through two separate agencies, one for software design and development and the other for software sustenance support?

• The artefacts of NCD software (architecture, design, code, documentation, test cases, reports, user documentation etc) will be stored by the development agency in various project repositories. How will these artefacts be handed over to a different software support agency for its maintenance?

• How should the software and AI/ML enhancement activities be handled and managed?

• What teams and skill sets are required during the lifecycle of the NCD Program?

• What is the NCD Program funding requirement and its management?

Architectural Views

The following architectural views are envisaged to be documented:

Purpose View

Business purpose, capabilities and functions delivered by the NCD System. It captures the Cyber Defence Ecosystem (CDE) constituents and the expectations from the NCD System from the perspectives of critical sector entities and the central agencies.

The Purpose View represents a Concept of Operations (ConOps) perspective that gives the broad vision and objectives of the System (what and why) to the larger group of stakeholders.

Functional View

The functional or logical view is concerned with the functionality that the NCD System provides to acquirers and the end-users. It captures the functional (logical) and process views of the NCD System from the perspectives of critical sector entities and the central agencies.

The Functional View represents an Operational Concepts (OpsCon) perspective that gives a more detailed insight into the operation of the System (who and how), specifically to engineers and designers.

Mission Operations View (Use Cases)

The Mission operations view depicts the system from the Business User/ End User point of view. It captures the Mission Operations view of the NCD System from the perspectives of critical sector entities and the central agencies.

This view can be further utilised to develop use cases and scenarios to describe the outcomes expected from the NCD system, which will serve as a starting point for the acquirers to define NCD System user acceptance test cases.

Development View

The development view illustrates a system from a developer’s perspective.

Deployment View

The deployment or physical view depicts the system from a system engineer’s point of view. It is concerned with the topology of physical hardware, software and security components and the physical connections between these components. It captures the deployment (physical and structural) views of the NCD System from the perspectives of critical sector entities and the central agencies.

IT Operations View

The IT operations view depicts the system from an IT and Security Operations team point of view. It captures the IT and Security Operations view of the NCD System from the perspectives of critical sector entities and the central agencies.

Supply Chain View

This view depicts the system from the Suppliers and Service Providers point of view.

Program Management View

This view depicts the NCD system from the program management point of view.

Mapping of Stakeholder Concerns to Architecture Viewpoints and Views

In the table below, the stakeholder concerns are mapped to specific architecture viewpoints and views. The table also includes a mapping of the architecture views to ISO/IEC/IEEE 15288 system engineering lifecycle processes and NIST SP800-160 Vol 1 system security engineering lifecycle processes.