The ADEPT Architecting Process

Iterative, Recursive, and Modular

The ADEPT Architecting Process is a universally applicable step-by-step approach to developing good Systems Architectures. The following graph gives an overview of the process:

9HTPs

The process is of course iterative and recursive. It can be applied top-down (as listed below), middle-out or, e.g. for Reverse Architecting, bottom-up.

Use Systems Thinking

9HTPs

This is not really a step in the process, but a general recommendation: make sure you understand why the challenge is relevant and why it landed with you

Do write a Problem Statement about

  • Context
  • Relevance
  • Objectives

Employ Systems Thinking to probe deeper into the challenge and to better structure your understanding of it. Use the 9 Holistic Thinking Perspectives by Joe Kasser and Tim Mackley to further develop that structure.

Analyse the Challenge

Challenge CD

NOTE: you have to do this regardless, as it allows you to find out how much SE is needed.

Verify you understanding of the project and engineering aspects. Identify for both aspects:

  • Assumptions
  • Deliverables
  • Interfaces
  • Make Assumptions Explicit

Categorise the Challenge

Cynefin

NOTE: from the context analysis, you should get enough information to perform this task.

Some tips:

  • not all challenges are proper projects
  • if they lack novelty or are of small scope, they can probably be treated as simple.
  • do not underestimate “the fold of disorder”, into which any project can plunge when certain assumptions were wrong or key members of the team leave.

Fill the Context Diagram Registers

CD

NOTE: The diagran is static. Each box is a register to be filled.

The steps are:

  • Make Assumptions Explicit
  • Discuss your understanding of the challenge with the Customer
  • Define likely Variants and Operational Modes
  • Engage with all relevant Stakeholders
    • Customer (Need/Constraint)
    • User (Need/Flow/Hazard)
    • Aux System (Flow/Hazard)
    • Other SH (Constraint)
  • Identify Ext Interactions the Actors with the SOI
  • Analyse the Object Flows, their possible failures (Hazards) and associated Risks
    • Control Signals
    • Energy
    • Matter
    • Information

From the Registers you can the derive the Customer Requirements (ReqC). Note, that in ADEPT, the ReqC are not the ones you receive from the Customer, but a set of formal Requirements that you must agree with the Customer. Make sure to take all Assumptions made back to the associated Stakeholders for Verification!

They typically comprise the following Elements:

  • Scenarios (top-level Operational REQs)
  • Capabilities (top-level Functional REQs)
  • Qualities (top-level Non-Functional REQs)
  • Interfaces (Object Flows, complete with Object properties)
  • Constraints

Some Notes on Modelling

All modelling is an iterative and recursive process. However, in ADEPT, the Operational and Functional Analysis, yielding the Operational and Functional Architectures, respectively, are the natural starting point for developing the System Behaviour (which is typically what the customer pays for).

Each Diagram of the Architecture represents an element that contains lower-level elements of the same type. Each of these can then be further analysed in a new Diagram (hierarchical analysis).

Here is some general advice:

  • always start from the “Sunshine Version”
  • use the “pull principle” (i.e. start at the end, here the expected Flow)
  • capture all assumptions and decision with the discussion that has gone into the Model

Develop the Operational Architecture

This is the principal Architecture for explicit Decision Making, comparing Data, and interpreting Information. It therefore can become the blue print for developing the Control Unit of the SOI.

OD

NOTE: The separation of Operations and Functions (see below) allows you to identify all required operations without any notion of their functional implementation.

Define top-level Scenarios using Sequence Diagrams or similar tools.

The steps are:

  • Analyse and Cluster Scenarios
  • Develop their Operational Diagrams
  • Include “Failure" and consider “Back-up” Operations for them
  • Include the Data Objects required to run an Operation, take a decision etc.

Develop the Functional Architecture

Functions are “stupid”, i.e. they cannot make logical decisions. They are controlled by the Operations and provide them with the Signals required for their execution.

To develop the Functional Diagrams you best start from the expected Object Flows that are generated by the Function.

FD

Here is some advice for the process:

  • All Flows must balance on the Functions
  • You must not end up with “lose” Object Flows. If you cannot connect them internally, you require a new external Flow (here, the “Measuring Function” has no input, but it does require some energy for the measurement - either from the hot milk, or externally)
  • You cannot split or merge Object Flows without a Function for it.
  • Logical Decisions cannot be modelled in the Functional Architecture.

Connect Operations to Functions

SignalExchange

Functions must never be part of an Operational Diagram and vice-versa. Instead, they are 'connected' by a Signal Exchange, which acts as a reminder that at some point in the development, the two Flows exchanged have to meet and be converted.

Some Functions need Operations to tell them when to start and when to stop. And some Operations need Functions to provide information about the physical aspects of the System, e.g. what State a particular Part or Object is in. As the (abstract) Operational Architecture cannot directly generate or consume a (physical) Signal, they have to be converted from a Physical Object (e.g. pressing a button to open a door) to the related Data Object meaning (“Open door“). However, there is no clear rule who does the conversion. Instead COFLP provides a dedicated model element, the Signal Exchange. It allows to connect the flows between the two Architectures, without belonging to either.

Develop the Logical Architecture

The Logical Architecture defines, how the System is broken down into lower-level elements, Sub-Systems or Components.

LD

Its objective is to:

  • reduce complexity
  • optimise the number of interfaces
  • keep the overview
  • delegate responsibility for the development
  • decouple development strands

A System can be broken down by several logical aspects - hence the name!

Component Specifications and Mapping

CPM

Components are specified in order to source physical parts for them

  • through the purchase of COTS parts,
  • from partial or complete reuse of Parts or Modules from other projects, or
  • by developing them from scratch.

Develop the Physical Architecture

PD

The Physical Architecture presents the final architectural model of all the physical units (Parts and Modules) with additional technical information, i.e. their Logical Relationships including the Functional and Control Flows, to allow for an understanding of their higher-level dependencies.

Arrange the physical units such that it gives guidance for System Integration. Make sure that

  • the Object Flows between the units can be realised, guaranteed and possible optimised (straight, short distances)
  • no one unit is overloaded with connections
  • the units and the order of their assembly allow for efficient verification (inspections/tests) keep the overview

For some of the Parts, new Flows emerge. This is particularly prevalent for electric power supply and additional external Flows, e.g. the noise made by some of the chosen Parts.