Architecture Portal

Change and review

Keep decisions connected as the service changes.

Adrian Sutherland · Version 1.0 · · © 2005–2026

Process areas

The ASAF process areas continue around each design state. They overlap and return to earlier decisions when an observation changes an assumption.

Area Work in this example What may be reopened
Visioning Establish accepted resolution, ownership, scope and options. Purpose, agreement rule or choice of service scope
Transforming Prepare the process trial; later migrate records and introduce software if agreed. Responsibilities, contracts, rollout and acceptance checks
Operating Observe handovers, unresolved cases, costs, access events and recovery. Procedures, capacity, support, supplier behaviour or design assumptions
Governing Assign decision authority, review exceptions and accept service changes. Shared policies, funding, risk acceptance and standards

These areas are not the process-only and software increments. Either increment requires appropriate work in all four areas, at the needed level of detail.

A change to follow

L1 (Partner confirmation gap) identifies a suitable partner alternative without an agreed confirmation owner. Record the finding, then follow its consequences through SU-D1 (Partner responsibilities), information references, permissions, support, cost and the check for partner handover. The service owner and business-area owner resolve the responsibility before expanding scope. The internal case owner and learner-agreement rule continue unless a separate decision changes them.

Review the affected records

  1. Identify the changed assumption or rule, the affected design state and who can decide it.
  2. Follow the object references to the views, contract, procedure and checks that depend on it.
  3. Update those records together; retain why the previous decision changed.
  4. Run the relevant checks and record actual results separately from expected behaviour.
  5. Accept the new arrangement and prepare the people who operate it. Feed observations back to the appropriate process area.

The records keep source and view identities together. Their edition identifies the website material; an application release, case version or operation identity has its own meaning and must not be substituted for that edition.

Methodology configuration

Map these activities into your actual reviews, iterations and operating routines. One meeting may cover several process areas. A changed rule may require several teams to revisit a small set of records without recreating the whole architecture.

Dials

Choose review cadence, change size, coordination and decision authority to match the work. A small process trial can use short feedback cycles; a shared contract change needs coordinated acceptance. More automation can shorten production of artefacts, while checked results and accepted decisions still determine readiness. See Methodology configuration.

About this edition

Refreshed for the September 2026 website update. This edition develops earlier Architecture Portal and ASAF material; the fictional service example was added in 2026.

Scope, limitations and next checks

Status and accountability

Read this page with its boundaries visible

Status

Proposed

Last reviewed

Intended users

  • Architects describing, comparing and adapting an architecture

Non-goals

  • A prescribed product stack or a claim of measured service outcomes

Limitations

  • The service is a fictional design. Its proposed implementation and operational checks remain unrun.

Next evidence sought

  • Apply the views and linked checks to an actual service.