Institutional Context & Stakeholder Concerns

2.1 Purpose and decisions supported

Institutional context is the set of relationships, obligations, operating conditions and stakeholder concerns that makes an architecture decision meaningful. A context model explains what the institution is responsible for, what depends on others and which uncertainties can change the proposed solution. It is a decision instrument, not a decorative diagram around an application. This section turns the mandate developed in Section 01 into a scoped context model, a stakeholder and concern register, a set of useful viewpoints and an evidence-collection plan. Section 01 remains a working draft: its assumptions are inputs to examine, not silently approved institutional policy. This section also remains a draft until the required review and acceptance process is recorded. The first decisions supported are the assessment boundary, the people who must participate, the concerns the architecture must address and the evidence required before recommending a target.

2.2 Inputs, authority and assessment boundary

Begin with the architecture mandate, the institutional promise, a candidate service journey and the current decision-owner list. Record the version of each input. An unresolved authority question in Section 01 must stay visible in this section rather than being converted into an assumed permission.

The boundary should distinguish the organization of interest, the service of interest and the technical systems that support it. These boundaries may overlap without being identical. A shared identity provider is a technical dependency; it does not necessarily own the institution’s approval authority.

2.3 Context dimensions

A context assessment should examine more than the software estate. The dimensions below are discovery prompts, not a requirement to collect unlimited information.

Policy interpretation and legal applicability belong to the authorized institutional or specialist owner. The architecture records the requirement and its consequence; it does not manufacture legal authority from a technical preference.

2.4 Worked context and explicit exclusions

The continuing example is a fictional regional institution with a headquarters, six offices and a small engineering team. Requests are submitted locally, reviewed by a department, authorized by finance, fulfilled by operations and included in a consolidated report. For this section, the assessment is limited to one request type and a candidate pilot office. Other offices matter as context and future consumers, not as evidence that the pilot represents the whole institution. The example’s conditions and findings are constructed to demonstrate the method.

Exclusions are not declarations that an area is unimportant. They make the scope, limitations and conditions for further work explicit.

2.5 Institutional context view

The institution is the decision boundary in this view. Users initiate work and may challenge its outcome. Policy and risk owners authorize governing rules. External service providers have their own operating responsibility. Internal service owners remain accountable for decisions even when implementation is delegated. Every crossing should identify the information exchanged, the authority retained, the service expectation and the failure response. An external provider may acknowledge delivery without establishing that an institutional approval was legitimate. Conversely, a valid internal decision can exist while its notification is delayed. The diagram is a reference model. The identity provider, storage location, supplier and manual fallback are discovery questions until supported by evidence. No actual integration, hosting arrangement or institution-wide control is claimed.

2.6 Stakeholder identification and representation

Identify stakeholders by their relationship to the service and its consequences. Include requesters, frontline staff, delegated reviewers, execution teams, information owners, operators, risk owners, support staff and people responsible for correction or appeal. Do not treat seniority as the only measure of importance. A person with little formal influence may experience most of the cost of a failed process. A sponsor’s approval does not remove the need to understand that experience. Representative participation should account for different offices, languages, accessibility needs, device conditions and unsuccessful journeys where relevant.

These identifiers name roles in a fictional register. A real engagement records the actual representative, their authority, contact route and evidence of participation under the agreed information-handling rules.

2.7 Concern register: make each concern actionable

Register IDs ST-xx, C-xx, VP-xx and DEC-xx are local to ZAF-I-02. Cross-section references include the document prefix to avoid confusing them with another section’s records. A concern is useful when it can change a decision, a requirement, an assessment activity or an acceptance scenario. “We need a modern platform” is not yet specific enough. Ask what is failing, who is affected, what consequence matters and which evidence would distinguish a useful change from an attractive product.

Record the source and status of each concern. A concern raised in an interview is not automatically a confirmed finding. A resolved concern should link to the decision or evidence that supports closure.

2.8 Authority, influence and acceptance

For each material concern, distinguish who experiences it, who understands its causes, who can authorize a change and who will operate the result. These may be four different parties. An engagement plan should specify how concerns are collected, how factual corrections are reviewed and how conflicting recommendations are escalated. Consultation is not the same as approval. Reviewing a diagram does not mean accepting its residual risks.

If no authorized owner can be identified, mark the decision blocked. Do not solve the ownership gap by assigning it to whichever engineer is available.

2.9 Conflicting concerns and explicit trade-offs

Concern C-04 may favour uninterrupted local activity. Concern C-02 may favour centralized approval against the current version. Both are legitimate concerns; the architecture should expose the conflict rather than describe one as resistance to change.

The recommendation in this example remains drafts offline and final approval online. It is conditional on business acceptance of the interruption cost. It is not a universal ZAF prohibition on offline approvals. A decision record should retain the rejected options, assumptions and review trigger. If the institution later changes its delegation model or outage tolerance, the earlier decision can be reconsidered without pretending it was wrong under its original conditions.

2.10 Viewpoints and useful architecture views

Within this library, a viewpoint states which stakeholder concerns a view addresses, which modelling conventions it uses and what its reader should be able to decide. A view is the actual representation prepared for a defined scope. These are working editorial definitions for ZAF. A single diagram cannot answer all institutional questions. Select a small set of complementary views and explain their limits.

Each view identifies its subject, version, scope, legend, source, author, open questions and intended reviewers. A drawing without those boundaries may look authoritative while leaving its interpretation uncontrolled.

2.11 Traceability from concern to decision

Maintain a traceable chain from stakeholder concern to evidence, requirement or decision, the view that explains it and the verification that would support acceptance. Traceability is not the number of links in a spreadsheet; it is the ability to answer why a recommendation exists and what would make it change.

A link to an unknown is useful if it clearly identifies what must be learned. It must not be presented as a completed verification.

2.12 Discovery and evidence-collection plan

Plan discovery around decisions, not around collecting the largest possible inventory. Use interviews to understand intended practice, observation to understand the actual journey and permitted records to test a claim. Triangulate important findings rather than treating one confident interview as a complete assessment.

For each activity, identify the participant, authorization, expected evidence, handling rule, limitation and decision it supports. No intrusive test, secret collection or uncontrolled production export follows automatically from this plan. Representative coverage is a design choice to justify. Record which offices and journeys were included, which were excluded and why. Avoid statistical claims when the evidence does not support them.

2.13 Uncertainty and change in context

Maintain a context-change register. A new provider, revised delegation, organizational restructuring, changed retention policy or more demanding service objective may invalidate an earlier recommendation.

Assign an owner to monitor each important trigger. “Review every year” may be useful as a backstop, but material change should not wait for the calendar.

2.14 Artifact package and review gate

The review gate tests whether the institutional context is sufficient for the next decision. It does not require every unknown to disappear. Material unknowns must have an owner, a learning activity and a clear restriction on the decisions they block.

2.15 Review checklist and next section

• The context model distinguishes institutional, service and technical boundaries.
• In-scope and excluded activities are explicit.
• Affected users and frontline roles are represented alongside formal authorities.
• Material concerns identify their source, consequence and decision impact.
• Consultation, factual review and acceptance authority are distinguished.
• Conflicting concerns retain alternatives and an escalation owner.
• Every selected viewpoint addresses named concerns and has a usable legend and scope.
• Evidence collection is authorized, proportionate and limited.
• Assumptions and incomplete coverage are visible.
• Context-change triggers identify when recommendations must be reconsidered.
• Section 01 is referenced without falsely claiming it has been accepted.
• Artifacts have stable identifiers and required review evidence.

The next section is Institutional Purpose, Value & Public Outcomes. It will develop outcome definitions, value-stream reasoning and measurement boundaries using this context package. Section 02 remains a working draft; the editor must record the actual review scope, findings and disposition before any status promotion.