Architecture Portal

Technology decision cycles

From service needs to operation.

Adrian Sutherland · Version 1.0 · · © 2005–2026

A changed assumption

A recovery exercise restores the database but takes longer than people can manage without the service. The finding may require a different backup process, more capacity or a revised continuity procedure. It should return to the people who own the affected service requirement and design.

Process areas

Visioning, Transforming, Operating and Governing are the continuing process areas in A Simple Architectural Framework (ASAF). They can overlap within a service review or delivery increment. A cycle may revisit one question or connect several areas; its scope and trigger determine who needs to take part.

ASAF process area Work and decision What can reopen it? Retained information
Visioning Agree service needs, workload and intended platform qualities; compare arrangements. A changed location, capacity or recovery need challenges the direction. Requirements, assumptions, alternatives and responsibilities.
Transforming Provision environments, apply reviewed configuration and check release readiness. Compatibility, migration or recovery checks expose a problem. Package and configuration versions, checks and transition plans.
Operating Run and support the environment, observe cost and capacity, and exercise recovery. Incidents, growth, restoration findings or supplier changes need attention. Measurements, incidents, configuration history and improvement proposals.
Governing Agree platform policies, change authority, service acceptance and exceptions. A change exceeds an agreed service constraint or accepted risk. Accepted requirements, policy decisions, exceptions and review triggers.

A configuration fault may need a local correction. A new data-location requirement or a supplier ending support can reopen the platform choice. Changes to acceptable interruption or lost work return to the business and process decisions as well.

Retaining the environment

Keep the accepted configuration, deployed versions, operating responsibilities and change reasons together. Record differences between test and service environments. An infrastructure template is part of the baseline; so are the protected management state, external settings and operational procedures needed to use it.

For a model dependency, retain the selected model and configuration where the provider permits it. Plan for supplier changes and recheck the step contract. For mobile clients, include versions still in use when checking a release.

Returning a finding

The worked example asks whether case records, operation receipts and pending notifications can be restored together. If an older copy omits an accepted transfer, technical restoration alone cannot establish who now owns the case. The service owner must accept the reconciled position before writes resume.

Methodology configuration

Map these concerns to environment design, release approval, service reviews, incident management and supplier reviews. Several may occur in one delivery cycle. Methodology configuration explains the mapping; the records retain the decisions between cycles.

Dials

The concerns below help apply the six shared dials. For example, limited exposure sets batch size, release authority sets who may proceed, and operating observations determine what needs reconsideration.

A staged programme may establish environments and service arrangements before application releases begin. Incremental delivery can introduce only the capacity and dependencies needed for the next useful change. Repeated small releases still need compatible versions, retained configuration and a clear recovery path.

Concern Question
Preparation Which dependencies or lead times require an earlier decision?
Exposure Can a change be introduced to a limited group or instance set first?
Automation Which steps are repeatable, and who accepts their proposed effects?
Recovery Can the previous version still use the records after this change?
Feedback Which service signals stop a rollout or reopen a design assumption?

An artificial intelligence (AI) assistant may prepare configuration or investigate an incident. Its output follows the same review of permissions, effects and recovery as another proposed change. Increased generation speed does not shorten an observation period or prove a restore works.

Diagram

Technology decision cycles

Design, release and service learning.

Technology decision cyclesDesign, release and service learning. The full nodes and connections are described below the diagram.directionreconsideraccepted changeimprovementprioritieschange authoritypolicyfindingsVisioningTransformingOperatingGoverning
  • Visioning

    Agree service needs, workload and intended platform qualities; compare arrangements.

  • Transforming

    Provision environments, apply reviewed configuration and check release readiness.

  • Operating

    Run and support the environment, observe cost and capacity, and exercise recovery.

  • Governing

    Agree platform policies, change authority, service acceptance and exceptions.

Read the connections
  • VisioningTransforming: direction.
  • TransformingVisioning: reconsider.
  • TransformingOperating: accepted change.
  • OperatingTransforming: improvement.
  • GoverningVisioning: priorities.
  • GoverningTransforming: change authority.
  • GoverningOperating: policy.
  • OperatingGoverning: findings.
Version 1.0 · September 2026 · © 2005–2026 Adrian Sutherland. The arrows show selected exchanges and feedback. Work can repeat within any area or reopen a wider decision. Governing applies to direction, change and operation; the areas can overlap. Retain accepted decisions between cycles.

About this edition

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

Scope, limitations and next checks

Status and accountability

Read this page with its boundaries visible

Status

In development

Last reviewed

Intended users

  • Architects adapting their existing method to technology and deployment

Non-goals

  • A prescribed product stack or implementation methodology

Limitations

  • Guidance illustrated by a fictional, unimplemented design with unrun checks.

Next evidence sought

  • Review the records and apply the proposed checks in a real implementation.