Architecture Portal

Assessing architecture and method

Questions for judging speed, quality and useful life.

Adrian Sutherland · Version 1.0 · · © 2005–2026

Two assessments

A cancellation process may give every learner a clear owner, yet take months to agree because decisions keep returning without new information. Conversely, a quick design exercise may leave staff unable to resolve a failed handover. The resulting architecture and the method used to develop it need separate assessment.

Judge the architecture by how well people can develop, operate, support and change the service. Judge the method by the time and effort needed to reach useful, accepted decisions. Consider the outcome for learners alongside both.

Suggested questions

Use these questions to compare options in a stated context. Agree which qualities matter, the scope being compared and how a result would be checked.

Criterion Architecture or solution Methodology
Speed Can a useful change be built, integrated and accepted in the time needed? How much time goes into decisions, waiting, review and rework?
Fitness for purpose Does the service meet the relevant needs and quality requirements? Are those needs understood and important assumptions tested early enough?
Development Can a team understand responsibilities, implement changes and check interactions? Do people receive usable decisions, contracts and information when needed?
Operation and support Can staff observe problems, recover the service and take over responsibility? Do operators shape the design, acceptance and continuing records?
Change Can rules, components or technologies change with proportionate effort and risk? Can findings reopen affected decisions while retaining sound ones?
Useful life What remained useful, through which changes and at what support cost? Are knowledge, ownership and review sustained after initial delivery?

Reliability, security, accessibility, performance and information integrity matter according to the service. Keep cost, scale, risk and team experience visible when interpreting a result. A faster draft is one observation; elapsed time to an accepted and usable change is another.

In the example

For the proposed manual trial, record time from cancellation to an accepted resolution, together with ownership gaps and incorrect bookings. Separately, record time and effort spent agreeing the process, reviewing it and preparing staff. The fictional trial has no actual results yet.

A later software option adds checks for concurrent handovers, repeated requests and recovery. Passing those checks would support specific technical claims; it would not establish that learners receive a better service or that the method caused an improvement. The measurement example keeps service outcomes, method effort and technical quality separate.

Evidence and limits

Before a trial, record the expected result and the proposed check. After it, retain the actual observation, scope, dates, versions and conditions. Identify missing information and competing explanations, such as changed workload, staffing or policy. The Metrics guide explains how to define a measure.

Useful longevity needs a dated history of operation, support, change and retirement. An old design document establishes its date; it does not show that the solution remained useful. Continued use may also reflect the cost of replacement. The fictional example cannot establish a longevity result.

The comparisons on this site describe selected contributions from named sources. They are starting points for examination, with source links and limits on each comparison page. Implementation examples provide separate records to inspect when judging a claim.

A useful first review

Start with the business decision. Choose one requirement and follow it through the worked trace to its decisions, contracts and proposed checks. Use the paired measure and quality records to retain what would be observed and what decision it would inform. Review the findings through your own process.

Methodology configuration

Use your own names for quality requirements, service objectives, acceptance criteria and decision records. A single service review may consider both architecture quality and method performance; keep the questions and observations distinguishable. Configuration guidance connects these records to your activities and reviews.

About this edition

Refreshed for the September 2026 website update. This edition develops the earlier Architecture Portal and ASAF material.

Scope, limitations and next checks

Status and accountability

Read this page with its boundaries visible

Status

In development

Last reviewed

Intended users

  • Architects comparing and improving their existing approach

Non-goals

  • A mandatory method or a claim of universal effectiveness

Limitations

  • Guidance and examples need application in the reader’s own context.

Next evidence sought

  • Try the guidance with a practising architect and retain the decisions and results.