Local and wider decisions
In our fictional training provider, one case owner can arrange an alternative course within agreed rules. If a partner runs the replacement course, the team may discover that nobody has agreed who confirms the booking. That finding requires a wider responsibility decision. It need not reopen the service’s purpose or every part of the design.
Here, a cycle is an architecture loop: a recurring question, the work to answer it, a check, an accepted result and feedback that may change later work. The diagram below connects the four process areas. The table distinguishes the scope of decisions made within that work.
| Scope | What starts it? | Who accepts the decision? | What remains useful afterwards? |
|---|---|---|---|
| Business purpose and architecture | A new need, changed constraint or failed shared assumption. | The business owner for the affected service or responsibility. | Purpose, outcomes, definitions, principles, ownership and open assumptions. |
| A delivery increment | An agreed priority or a specific uncertainty to resolve. | The delivery team within delegated scope; the business/service owner accepts the result. | A change decision, affected records, checks and a usable handover. |
| Operation and service learning | Service use, a support issue or a scheduled review. | The service owner; affected owners join when a shared decision changes. | Observations, support knowledge, unresolved cases and improvement proposals. |
The same process areas apply at each scope. For example, a delivery increment can revisit the intended outcome, introduce a change, prepare operation and obtain the required acceptance. Its result can reopen a wider responsibility without replacing every agreed decision.
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 the intended learner outcome, service scope and future responsibilities. | A new need or a failed assumption about purpose or ownership. | Purpose, outcomes, definitions, principles and alternatives. |
| Transforming | Prepare the process-only trial, change the affected work and check the handover. | A rehearsal or delivery finding changes what the increment needs. | Change decisions, affected records, checks and readiness. |
| Operating | Resolve cases under agreed rules and observe ownership gaps or delays. | A local correction or recurring problem needs attention. | Case history, support knowledge and improvement proposals. |
| Governing | Set decision authority and review shared rules, exceptions and trial acceptance. | A partner responsibility gap exceeds the delegated scope. | Accepted decisions, reasons, exceptions and review triggers. |
Two arrangements
| Arrangement | What is held stable? | What repeats? | Trade-off to examine |
|---|---|---|---|
| Agree the wider service first | Responsibilities and information meanings across the booking service. | Delivery and review of individual improvements; wider decisions reopen on a defined trigger. | More coordination before the first change, with an opportunity to resolve shared dependencies early. Feedback from actual use may arrive later. |
| Start with one cancellation path | The immediate outcome, agreement rule and authority for that small scope. | Delivery, service review and selective extension of the business model. | Earlier feedback from the small scope, with more reconciliation as partner and cross-team responsibilities emerge. |
These are just illustrative arrangements. Compare the actual process and the way a team applies it. A method with phases can still contain iterations.
Methodology configuration
A team might have one fortnightly service review covering business questions, delivery acceptance and operational learning. Those cycle concerns can all map to that review. A complex responsibility decision may need several reviews.
Keep the differences that matter: who may decide, what information they use, what is accepted and what can trigger reconsideration. Use your method’s names for the activities, stages and reviews. The Methodology configuration section introduces this approach to tailoring.
Dials
The delivery dials describe how a cycle runs. For the first cancellation increment, a possible profile is:
| Dial | Illustrative setting |
|---|---|
| Cadence | Review open cases daily during the trial; review the trial after two weeks. |
| Batch size | One cancellation path, one named owner at a time and one shared record. |
| Coordination | Booking and course leads agree the handover; the case owner reports unresolved cases. |
| Decision authority | The case owner offers approved alternatives; policy and partner-ownership changes return to the service owner. |
| Automation and checking | Begin with a manual record; check learner agreement and ownership at each handover. |
| Learning reach | Correct a record locally; take a shared responsibility gap back to business review. |
These settings are choices for the fictional trial. A different setting can change review effort, feedback delay and the number of people who must coordinate.
Decisions between cycles
Keep the accepted purpose and rules available for the next iteration. Record which relationships a change affects, what remains agreed, who accepts it and which checks need repeating. Do not silently replace the previous decision.
Use the cycles, decisions and change record to map your own process. The worked example shows a local improvement followed by a finding that reopens ownership.