Reference Architectures & Technology Standards

A reference architecture is a pre-approved, reusable blueprint for a common design problem; a technology standard is a narrower, approved choice of tool or platform.

At a glance

• What it is: Reusable blueprints (reference architectures) and approved specific choices (standards) that solutions are expected to use.
• Why it matters: They trade a small amount of team-level flexibility for a large reduction in enterprise-wide risk, inconsistency, and duplicated effort.
• For developers: check for an existing reference architecture before designing a common building block (auth, logging, messaging) from scratch — reusing one is almost always faster than justifying a new pattern in review.
• When to use it: Early in solution design, for recurring building blocks like auth, logging, or messaging.
• When not to use it: For a genuinely novel problem with no existing precedent — forcing a standard where none fits creates worse outcomes than designing fresh.
• Prerequisites: Architecture Governance, since that’s the process that publishes and enforces these.

Mental model

flowchart LR
    Prob["Recurring design problem<br/>(e.g. API authentication)"] --> RA["Reference architecture / standard"]
    RA --> S1[Solution A]
    RA --> S2[Solution B]
    RA --> S3[Solution C]

One problem, solved once and published, reused by every team that hits it — instead of each solution answering the same question from scratch.

Step-by-step walkthrough

1. Identify a recurring design problem showing up across multiple teams (e.g. every new API reinventing authentication).
2. Design a reusable blueprint, or select a specific approved tool/platform as a standard.
3. Publish it through Architecture Governance so it carries real authority.
4. Solution and software architects consult it early in design, instead of designing common building blocks from first principles.
5. Revisit and update it periodically as technology and business needs change.

Worked example

Several teams are each building bespoke authentication for their APIs:

• Input: three teams, three different auth implementations, inconsistent security posture.
• Process: publish an “API Authentication Reference Architecture” built on the approved identity provider standard.
• Output: new APIs adopt the reference architecture directly, cutting design time and standardizing the security posture.

A more concrete instance of the same idea: Northwind’s “Standard Internet-Facing Web Application” reference architecture specifies Azure Front Door in front of an App Service web app (autoscale rules already defined), Azure SQL Database using an auto-failover group to a paired region, a Storage Account for static assets reachable only via a private endpoint, and Application Insights wired in from day one — so a new team starts from this approved topology instead of re-deciding scaling, DR, and monitoring from scratch.

resource frontDoor 'Microsoft.Cdn/profiles@2024-02-01' = {
  name: 'northwind-fd'
  location: 'global'
  sku: { name: 'Standard_AzureFrontDoor' }
}
// App Service, SQL failover group, and Storage Account private endpoint follow the
// same standard Bicep modules every team in the reference architecture reuses.

Common use cases

Use case	When to use	Notes
Common building blocks (auth, logging, messaging)	Every new solution needs them	Reuse the reference architecture instead of designing from scratch
Approved technology choices	Choosing an identity provider, database, or logging format	Follow the standard unless a waiver is granted
Onboarding new engineers/architects	Faster ramp-up	Consistent patterns across systems reduce the learning curve
Standard web app topology	Every new internet-facing web application	Front Door + App Service (autoscale) + SQL failover group + private endpoints + Application Insights, published once and reused

Advanced details

• Reference architectures and standards are living artifacts — revisited and updated, not fixed once and forgotten.
• Standards are exactly what Architecture Governance checks proposals against during ARB review.
• They map onto the Four Architecture Domains: a reference architecture typically spans Application and Technology views, informed by Business and Data context.
• Cloud reference architectures don’t need to be invented from scratch — they typically adapt a cloud provider’s own published patterns, e.g. the Azure Well-Architected Framework’s reference architectures for common topologies (web app, microservices, data platform).

Quick reference

	Reference architecture	Technology standard
Scope	A reusable design pattern for a recurring problem	A specific approved tool, platform, or format
Example	“How we build a new externally-facing API”	“The approved identity provider”
Enforced by	Architecture governance / ARB review	Architecture governance / ARB review

Troubleshooting

Symptom	Likely cause	Fix
Standard becomes shelfware	Not enforced through governance	Tie it into ARB review and waiver tracking
Teams keep asking for exceptions	The standard doesn’t fit a common case	Revisit and update the standard, don’t just keep granting waivers
Inconsistent security/integration posture across systems	No reference architecture exists for the recurring problem	Publish one and route new designs through it

Check your understanding

• Why is a technology standard described as “narrower” than a reference architecture?
• Name a recurring design problem in a system you know that would benefit from a published reference architecture.

Related pages

Part of Introduction to Enterprise Architecture. See Architecture Governance for how compliance is enforced, The Four Architecture Domains for how standards map onto Business, Data, Application, and Technology views, and the Glossary for term definitions.