The Board and the Payments Programme
A retail bank's Architecture Board meets monthly with nine members and a quorum of five. A payments programme must go live in six weeks. Its solution uses a non-standard database and buys a package covering capability that an architecture principle says should be built in-house where it differentiates. The programme's architecture contract was signed eight months ago and has not been reviewed since. The business sponsor sits on the Board. The regulator requires evidence that architecture decisions are taken consistently and recorded. The Chief Architect must bring the item to the next Board, at which only five members can attend.
1. What governance options does the Board have, and which would you recommend? Be specific about the mechanism and the records.
Read the worked answer
The Board first needs a compliance review against the relevant principle and standards, with a stated outcome - on these facts, non-conformant. Recall that the review scale runs from irrelevant and consistent through compliant and conformant to non-conformant; naming the outcome is what makes the decision auditable.
Options: (1) Reject - refuse approval until the solution is re-architected. Technically available, practically implausible six weeks from go-live, and it would put the Board in conflict with the delivery commitment. (2) Grant a dispensation - time-bound approval to deviate, with a named owner, a remediation plan, an expiry date and an explicit risk acceptance. (3) Amend the principle - if the 'build the differentiator' principle is genuinely wrong for payments, change it deliberately through the proper process rather than informally.
Recommendation: a dispensation limited to the go-live release, requiring the database to be added to the technology roadmap review and remediation before the next major release. Two procedural points carry the regulator's requirement. First, the sponsor should recuse from the decision; if that drops attendance below the quorum of five, the meeting cannot decide and the item must go to a properly constituted session - do not proceed on four. Second, record everything in the Governance Log: the review outcome, the risk accepted, who accepted it, the remediation date, and the updated architecture contract.
The trap is treating a dispensation as a quiet waiver. It is a decision with conditions and an audit trail, or it is nothing.
2. How would you handle stakeholders and views for the regulator, the business sponsor and the operations director? Explain the viewpoint/view distinction as you apply it.
Read the worked answer
A viewpoint is the set of conventions - notation, model kinds, audience - from which a view is built; a view is the actual instance produced for this programme. The viewpoint library is the reusable asset; you select from it and tailor rather than inventing a document per audience.
Regulator - concern: that architecture decisions are taken consistently and can be evidenced after the fact. The view is a governance view: the decision record, compliance review outcomes, dispensations with owners and expiry, architecture contract status. Not detailed technical models; the regulator is auditing the process, not the schema.
Business sponsor - concern: benefit, cost, timing and risk to the go-live. The view is the architecture roadmap / transition view showing what is delivered at go-live, what is deferred, and what the dispensation costs in risk and remediation effort.
Operations director - concern: whether the thing can be run, supported and met against service levels. The view is a technology and service view covering the non-standard database's operational implications, support model and dependencies.
The judgement is selection and tailoring: three audiences, three views, one underlying architecture. Producing a single exhaustive architecture definition document and sending it to all three satisfies nobody and is the most common way stakeholder management fails in practice.
3. The Board approves the dispensation, but three months later the programme confirms the non-standard database will remain indefinitely. What should happen, and which parts of the framework carry it?
Read the worked answer
This is a change in the architecture, not a continuation of an approved exception. The dispensation had an expiry and a remediation condition; both have been breached, so the decision must return to the Board rather than being silently extended.
The route is Phase H, Architecture Change Management. The programme raises a change request; the change is classified - this is a simplification or incremental change depending on whether the database is added to the target technology architecture, and if it becomes part of the target then the architecture itself needs re-baselining rather than another dispensation. Phase H also checks whether the change triggers a new ADM cycle: if the database becomes a de facto standard, the Standards Information Base must change and the technology architecture in Phase D must be revisited.
The Architecture Board decides, the Governance Log records the closure of the original dispensation and the new decision, and the architecture contract is renegotiated with the delivery organisation so that what is being assured matches what is being built. Phase G compliance reviews then test against the updated contract.
What must not happen is the exception becoming invisible. The regulator's requirement is not that deviations never occur - it is that they are decided, bounded and recorded. An indefinitely extended dispensation with no re-decision fails that test even though nothing technically went wrong.