Two changes, one dependency
In the fictional example, a training provider wants to improve how it handles cancellations and introduce a partner booking service. Both changes depend on the same learner definitions and agreement rules. Funding two teams independently could produce conflicting answers. Someone must decide the shared direction, order the work and retain responsibility when the projects finish.
A Simple Architectural Framework (ASAF) connects these decisions through its Management aspect. This covers the enterprise roadmap, programme and portfolio management, service management, and the methods and terminology people use. It describes how an organisation directs and maintains its architecture work. Governing is the continuing process of setting the rules for that work and checking that they are followed.
Decisions at different scopes
| Scope | Decision and retained information |
|---|---|
| Enterprise or business area | Purpose, priorities, shared capabilities, principles and a roadmap of dependencies. |
| Portfolio or programme | Which initiatives to fund, sequence, combine, stop or defer; who owns their combined outcomes. |
| Service | Who accepts operational change and balances service quality, cost, security and support. |
| Team | Which design and delivery choices are delegated, and what finding requires a wider decision. |
The same person may hold several roles. What matters is the decision they are authorised to make and the information available to them. Advising on a design, accepting its risk, committing money and accepting it into service can involve different authorities.
A useful roadmap
Connect each initiative to its intended outcome, dependencies and affected owners. Show how the service works now, how it could work between changes and what it should become. For a shared identity service, include the teams that must migrate, supplier support dates and continued operation of old access paths. A roadmap needs decisions and conditions as well as dates.
Keep proposed, accepted, implemented and retired decisions distinguishable. Record reasons, alternatives, affected relationships and the trigger for review. For an exception, record its owner, where it applies, the arrangements that address its effects, and an expiry or review date. These records help a new architect understand why the current arrangement exists.
Speed and quality
Observe decision waiting time, unresolved dependencies, repeated reviews and late reversals. Also examine whether delegated decisions remain consistent and whether service owners can maintain the results. Faster generation of options is useful when the organisation can evaluate and accept them without losing the reasoning behind earlier decisions.
Data governance applies these decision rights to information ownership, quality, access and change across teams.
Methodology configuration
A design authority, product council or service owner may make these decisions in your method. Identify who has authority and what records they keep; job titles alone may not tell you. Methodology configuration explains how to map these terms, records and reviews to your own approach.