Architecture & System Design Templates

Last Audited: 2026-08-14
Tier-2 Authoritative
In Plain Language

Architecture templates standardize how technical designs, component boundaries, interface contracts, and trade-off decisions are documented across the engineering organization. Use these four templates to author clear ADRs, system blueprints, API schemas, and data models that guide implementation and satisfy regulatory design output audits.

Why Standardize Architectural Deliverables?

Software architecture often lives in engineers' heads until it drifts into unmaintainable complexity. These four templates ensure that every subsystem has an explicit blueprint, every key decision is captured in a one-page ADR, and every API and table schema is formally specified before code is merged.

Architecture Templates#adr-template

Architecture Decision Record (ADR)

An ADR is a one-page document capturing why a major technical choice was made, so future engineers and auditors understand the reasoning.

🎯 Primary PurposeRecords critical architectural decisions, context, chosen options, and technical trade-offs in an auditable markdown file.
⏱️ When to UseWhen choosing a database, adopting a new framework, refactoring system boundaries, or modifying security architectures.
Regulated Mandate: ISO 13485:2016 (Cl. 7.3.3 Design Outputs)
View Statutory Compliance Rule
adr-template.md (Boilerplate Markdown Starter)
GFM Markdown
# ADR-{{NUMBER}}: {{TITLE}}

- **Status**: [PROPOSED | ACCEPTED | DEPRECATED | SUPERSEDED by ADR-XXX]
- **Deciders**: [List of architects and lead engineers]
- **Date**: YYYY-MM-DD
- **Technical Story**: [Jira/Issue link or SRS reference]

## Context and Problem Statement
{{Describe the context and problem statement in 2-3 plain-language sentences. What forces are at play?}}

## Decision Drivers
- {{Driver 1: e.g. Zero downtime migration requirement}}
- {{Driver 2: e.g. Compliance with HIPAA § 164.312 encryption standards}}
- {{Driver 3: e.g. Sub-50ms p99 query latency}}

## Considered Options
1. **Option 1**: {{Title and brief summary}}
2. **Option 2**: {{Title and brief summary}}
3. **Option 3**: {{Title and brief summary}}

## Decision Outcome
Chosen Option: **Option 1**, because {{rationale justifying choice against decision drivers}}.

### Positive Consequences
- {{Positive consequence 1}}
- {{Positive consequence 2}}

### Negative Consequences / Trade-offs
- {{Negative consequence 1, e.g. increased operational overhead}}
- {{Mitigation plan}}

## Pros and Cons of the Options
### Option 1: {{Name}}
- Good, because {{reason}}
- Bad, because {{reason}}

### Option 2: {{Name}}
- Good, because {{reason}}
- Bad, because {{reason}}
Architecture Templates#system-design-doc

System Design Document (SDD)

A blueprint explaining how a software service is structured, how data flows through it, and how it handles failures.

🎯 Primary PurposeDefines the end-to-end component structure, data flow, interface contracts, and non-functional guarantees of a subsystem.
⏱️ When to UseBefore implementing new services, major features, external API integrations, or multi-tenant infrastructure.
Regulated Mandate: FDA 21 CFR § 820.30(c) (Design Inputs & Outputs)
View Statutory Compliance Rule
system-design-doc.md (Boilerplate Markdown Starter)
GFM Markdown
# System Design Document: {{SYSTEM_NAME}}

- **Author(s)**: {{Names}}
- **Reviewer(s)**: {{Lead Architect, Security Lead}}
- **Target Release**: {{Version / Sprint}}
- **Status**: [DRAFT | UNDER REVIEW | APPROVED]

## 1. Executive Summary & Plain-Language Overview
{{1-2 paragraphs explaining what the system does and why it is being built in non-technical terms.}}

## 2. Goals & Non-Goals
### Goals
- {{Measurable Goal 1: e.g. Support 5,000 concurrent clinical telemetry streams}}
- {{Measurable Goal 2: e.g. 99.99% availability with zero data loss}}

### Non-Goals
- {{Explicit out-of-scope items}}

## 3. Architecture & Component Diagram
```mermaid
graph TD
  Client[Client Application] --> API[API Gateway]
  API --> Service[Core Processing Service]
  Service --> DB[(Encrypted Database)]
  Service --> Cache[(Redis Cache)]
```

## 4. Data Model & Storage
- **Primary Datastore**: {{e.g. PostgreSQL with AES-256 transparent data encryption}}
- **Schema & Relationships**: {{Describe entities and indexing strategy}}

## 5. Security & Compliance Considerations
- **Authentication**: {{OAuth 2.0 / JWT}}
- **Data Protection**: {{Encryption in transit via TLS 1.3, at rest via AES-GCM}}
- **Audit Logging**: {{Immutable write-only audit trail}}

## 6. Failure Modes & Disaster Recovery
- **Component Failure Handling**: {{Circuit breakers, dead letter queues}}
- **RTO / RPO**: {{RTO < 1 hour, RPO < 5 minutes}}
Architecture Templates#api-specification

API Specification Contract

A formal agreement specifying the exact URLs, inputs, outputs, and security rules for communicating with a web service.

🎯 Primary PurposeStandardizes HTTP REST or GraphQL endpoints, request payloads, response schemas, and authentication headers.
⏱️ When to UseWhen designing or updating public APIs, microservice RPC boundaries, or mobile-backend interfaces.
api-specification.md (Boilerplate Markdown Starter)
GFM Markdown
# API Specification: {{API_NAME}}

- **Base URL**: `https://api.example.com/v1`
- **Authentication**: Bearer JWT in `Authorization` header
- **Content-Type**: `application/json`

## Endpoint: `POST /v1/records`
Creates a new patient compliance record.

### Request Headers
| Header | Type | Required | Description |
|:---|:---|:---|:---|
| `Authorization` | string | Yes | `Bearer <JWT_TOKEN>` |
| `X-Correlation-ID` | string | Yes | Unique UUID for distributed tracing |

### Request Body Schema
```json
{
  "recordType": "TELEMETRY_LOG",
  "patientId": "pt-882194",
  "payload": {
    "vitalCode": "HR_BPM",
    "value": 72
  }
}
```

### Response `201 Created`
```json
{
  "id": "rec-00129",
  "status": "RECORDED",
  "createdAt": "2026-08-20T12:00:00Z"
}
```

### Error Responses
- `400 Bad Request`: Schema validation failure.
- `401 Unauthorized`: Missing or expired token.
- `403 Forbidden`: Insufficient role permissions.
Architecture Templates#data-model-template

Data Model & Schema Specification

A structured catalog of tables, fields, relationships, and data storage rules powering the application.

🎯 Primary PurposeDocuments relational tables, foreign key constraints, column data types, indexing rules, and data retention lifecycles.
⏱️ When to UseWhen adding or restructuring database tables, planning database migrations, or modeling multi-tenant domains.
data-model-template.md (Boilerplate Markdown Starter)
GFM Markdown
# Data Model Specification: {{DOMAIN_NAME}}

## 1. Entity-Relationship Overview
- **Primary Schema**: `public` or domain namespace
- **Database Engine**: PostgreSQL 16+

## 2. Table: `user_accounts`
Stores verified user identities and authorization roles.

| Column Name | Data Type | Constraints | Description |
|:---|:---|:---|:---|
| `id` | `UUID` | `PRIMARY KEY, DEFAULT gen_random_uuid()` | Unique account identifier |
| `email` | `VARCHAR(255)` | `NOT NULL, UNIQUE` | User email address |
| `password_hash` | `VARCHAR(255)` | `NOT NULL` | Argon2id password hash |
| `role` | `VARCHAR(50)` | `NOT NULL, DEFAULT 'PRACTITIONER'` | RBAC role tag |
| `created_at` | `TIMESTAMPTZ` | `NOT NULL, DEFAULT NOW()` | Record insertion timestamp |

## 3. Indexes & Constraints
- `CREATE INDEX idx_user_accounts_email ON user_accounts(email);`
- `CREATE INDEX idx_user_accounts_role ON user_accounts(role);`

## 4. Privacy & Retention Policy
- Records retained for 7 years per regulatory archive rules.
- ePHI fields encrypted using column-level AES-256 encryption.
Try This with AI: Automated ADR Generator

Copy this prompt to generate comprehensive ADRs for your architectural choices.

You are a lead enterprise architect. Draft an Architecture Decision Record (ADR) comparing PostgreSQL with pgvector vs. Pinecone for a HIPAA-compliant medical AI retrieval pipeline. Include decision drivers, considered options, pros/cons, and final decision outcome.

Community Discussion & Feedback

Attributed peer feedback and official Netspective architecture notes.

Was this documentation helpful?(100% found this helpful • 0 ratings)

Leave Feedback or Question

○ Loading user info...
0/2000 chars

Discussion (0)

Loading discussion thread...