Technical Architecture and Integration
Technical Architecture and Integration
This domain tests architecture decisions, integration patterns, data movement, security, and operability across systems.
Core rules
- Document architecture in views: logical, data, deployment, and security. Record decisions in architecture decision records (ADRs) with context, options, and consequences.
- Choose integration style by requirement: synchronous API for immediate query or response, events for decoupled notification, batch or file for high-volume scheduled exchange.
- Design for failure: timeouts, retries with backoff, idempotency, dead-letter handling, monitoring, and reconciliation.
- Define data ownership, master data source, mapping rules, transformation logic, and data quality checks.
- Treat authentication, authorization, encryption, secrets management, and audit logging as design inputs, not late additions.
- Validate non-functional requirements: latency, throughput, availability, recovery point objective (RPO), and recovery time objective (RTO).
Worked example
A retailer needs inventory visible near-real-time, but the ERP only supports nightly extracts. The architect proposes event-based updates for stock changes plus a nightly reconciliation file. Reasoning: events meet the latency need; reconciliation controls drift and handles missed events. A pure batch design fails latency; pure real-time without reconciliation fails operability.
Traps
- Point-to-point sprawl with no ownership.
- Designing only the happy path.
- Deferring security review until go-live.
- Assuming source data is clean.