Reference Architectures

## What a reference architecture is A reference architecture is a **codified, reusable architectural template**: a set of standard components, their responsibilities, the interfaces between them, and the relationships and data flows that connect them, distilled from many real implementations rather than invented for one project. It sits one level above a specific system design — it does not tell you which database or framework to use, it tells you what capabilities must exist and how they should be organized so that the resulting system is coherent, interoperable, and comparable to others built the same way. ## Where they come from Reference architectures come from three main sources: 1. **Industry consortia** that pool the experience of many competing organizations — `BIAN`, the Banking Industry Architecture Network, for banks; TM Forum's `eTOM` process framework and `SID` information model for telecom operators. 2. **Vendors** publishing a recommended way to use their platform — AWS, Azure, and Google Cloud each publish a 'landing zone' reference architecture for how to structure accounts, networking, and identity. 3. **Internal enterprise architecture groups** that generalize patterns proven inside their own company across business units. ## Adoption is instantiation The mechanism of adoption is instantiation, not copy-paste. A reference architecture like BIAN's Service Landscape defines roughly 300-plus 'Service Domains' (for example Party Reference Data Management, Current Account, Credit Card Authorization) organized into business areas, each with a defined scope, standard operations, and business object model. A bank does not implement all 300; an architecture team - maps the bank's existing systems and target capabilities onto the subset of Service Domains that are relevant, - renames or splits domains where the bank's regulatory or product reality doesn't match the reference cleanly, - uses the untouched majority of the model as the target vocabulary for years of incremental migration. The same pattern applies to a cloud landing zone: the vendor's reference gives you an account hierarchy, a network topology, an identity model, and a set of preventive guardrails; you instantiate it by choosing which guardrails are mandatory versus advisory for your risk appetite, and which optional modules fit your existing footprint. ## Why it exists This exists because designing an enterprise-scale service decomposition or cloud foundation from a blank page is expensive and risky. Every bank has faced the same problem of separating 'party' (a person or organization) from 'arrangement' (an account, loan, or card) so that a customer's relationships can be queried without duplicating identity data across product silos — BIAN encodes that lesson once so the two-hundredth bank to adopt it does not rediscover it through years of costly rework. Reference architectures also create a **lingua franca**: - a bank's RFP to a core-banking vendor can specify operations against the Current Account Service Domain and get comparable bids; - regulators or auditors familiar with the standard can review the architecture faster. ## The trade-off: fit versus speed The trade-off is fit versus speed. The reference architecture was abstracted from other organizations' realities, so by construction it fits none perfectly. Forcing a domain model that has a genuine local wrinkle — a niche regulatory product, a merger-inherited system with an unusual boundary — into the reference's shape produces awkward, **leaky abstractions** that cost more to maintain than they saved at adoption time. The correct discipline is to - treat the reference as a checklist and shared vocabulary, - deviate deliberately and document why, - resist contorting the organization to match the model purely for 'compliance with the standard.' ## Failure modes in production Failure modes in production show up as governance theater, and as over-adoption: - **Governance theater** — teams claim BIAN alignment in architecture diagrams while the actual service boundaries and APIs diverge completely, because mapping was done once at a point-in-time review and never enforced afterward. - **Over-adoption** — another common failure, implementing every optional Service Domain 'because it's in the standard,' producing unnecessary microservices with no real bounded context behind them and adding operational cost without business value. ## A worked scenario A concrete worked scenario: a mid-size retail bank building a new digital-lending platform 1. maps its target services onto BIAN's Consumer Loan and Party Reference Data Management Service Domains; 2. keeps its existing fraud-scoring engine as a bespoke component outside the model, because BIAN has no equivalent granularity there; 3. uses the BIAN operation names in its API gateway's specs so that a fintech partner integrating via open banking already recognizes the shape of the contract from BIAN documentation, cutting partner onboarding time significantly.