Enterprise, transition and platform. Frameworks appear at the end of each theme, which is where they belong: they support the narrative, they are not the narrative.
Enterprise architecture
Getting from what the bank does today to what it needs to do, through states that are each viable on their own.
Capability and domain modelling
Baseline architecture
Target architecture
Transition architecture
Plateaus
Work packages
Architecture roadmaps
Architecture governance
Banking architecture
Banking complexity is learned across systems, failures, regulation and institutions over time — not in a single engagement.
BIAN v13 / v14
Domain-oriented architecture
Layered banking architecture
Core modernization
Hybrid cloud / on-premise
Open Banking
Payments
Payroll dispersion
Onboarding
Credit / origination
Fraud
AML / KYC
Identity
Six layers stack; the seventh does not. Security, identity and observability cross all of them, and drawing them as one more step would suggest a layer could skip them.
Architecture governance
Governance without authority, evidence and gates is ceremony. What makes a review able to stop something is an instrument.
Frameworks support the narrative; they are not the narrative. They appear here as tools, not as credentials.
TOGAF
ISO/IEC 42010
ArchiMate
C4
DDD
Architecture assets
An architecture decision without an instrument behind it is an opinion with letterhead. These are the instruments.
A-05
BIAN-aligned taxonomy and naming grammar
Problem
Without a shared vocabulary every integration between two systems is a hand-made translation, and the number of translations grows with each new system.
Mechanism
Domain partitioning, a naming grammar derived from the classification, and sensitive-data classification applied at the same time.
Why it matters
Identity stops being a per-team decision. The same name holds across contract, repository, deployment and telemetry, so a component can be traced back to the capability it serves.
A-01
ISO 42010 viewpoint catalog
Problem
What counts as complete documentation is implicit, so reviews argue about form instead of substance.
Mechanism
Ten viewpoints, each with completeness criteria and anti-pattern checks.
Why it matters
A review can say what is missing rather than what it dislikes — which is the difference between a gate and an opinion.
A-02
AHP + CBAM decision method
Problem
A recommendation is not defensible if the criteria, evidence and authority behind it are invisible.
Mechanism
An executable model where criteria are fixed before any option is scored, and the whole evaluation can be re-run when an input changes.
Why it matters
The decision survives the meeting. Months later it can be reopened against the same criteria instead of relitigated from memory.
A-03
Deterministic diagram generator
Problem
Hand-drawn diagrams drift from the model they describe, and the drift stays invisible until someone relies on them.
Mechanism
Calculated geometry with collision controls, producing versionable artifacts regenerated from the model itself.
Why it matters
The picture cannot quietly disagree with the architecture, because it is derived from it rather than drawn alongside it.
A-06
Construction archetypes and quality gates
Problem
Quality varies by team when every service is designed from scratch.
Mechanism
Archetypes by layer and service nature, each carrying its own gates.
Why it matters
Teams stop re-deciding the same things on every service, and the standard is enforced by the build rather than by review.
A-07
BIAN retrieval-augmented architecture toolkit
Problem
Automation that produces plausible architecture artifacts without traceability moves the problem rather than solving it.
Mechanism
Retrieval over a governed BIAN corpus with cross-validation rules applied between phases.
Why it matters
The generated artifact carries traceability from business capability through to implementation, so it can be reviewed rather than merely trusted.
341BIAN Service Domains indexedBIAN architecture toolkit
14Architecture artifacts across 5 phasesBIAN architecture toolkit
15Cross-validation rulesBIAN architecture toolkit
A-16
Evidence-driven conformity assessments
Problem
Severity alone does not tell a programme when to stop: a medium finding on an irreversible choice outranks a high one that can be undone next sprint.
Mechanism
Explicit scales, blockers classified by irreversibility, named owners, environment gates, waivers and a one-page ratification.
Why it matters
The review gains the authority to stop something before it is built, which is the only point at which stopping is cheap.
Capability and delivery instruments
These are not architecture assets: they support the operating model that builds it.
A-08SFIA role triad
Enterprise Architect, Solution Architect and Tech Lead defined against a capability framework rather than against local custom.
A-09Profile positioning rubric
Recency, scarcity, relevance, scope and evidence as explicit axes, so assessment stops drifting toward whoever interviews.
A-10Error propagation standard
How a failure travels across layers without losing its cause on the way up.
A-12Estimation calculation model
Activity decomposition with complexity accounting and explicit scenarios — migration estimates are invented hours otherwise.
A-14Procedural evaluation campus
An operating campus anchored to SFIA, where progression is evidenced rather than declared.
A-15Junior talent onboarding programme
Training, shadowing and a final defence, so capability transfers instead of concentrating in whoever built it.