Senior to Architect: System Design and Architecture Leadership
A planned 12-week, instructor-led syllabus: from requirements and quality attributes through data and integration architecture, security and operating cost, to technical leadership. You finish by defending an architecture for a realistic payments-style case. Order and depth may be adjusted to the group; the program does not promise a job or a title.
This program is planned and not scheduled yet. No date, cohort or admission has been announced, and we are not accepting applications. Register interest or ask for a consultation and we will contact you when it is scheduled.
- Duration
- 12 weeks
- Live sessions
- 2 per week, 90 minutes each
- Structure
- 4 phases
12 weeks
Week-by-week syllabus
This is the planned syllabus: order and depth may be adjusted to the group. It is not a job or title guarantee.
01 · Weeks 1–3
Foundations: requirements, styles, documentation
Phase goal: Turn a vague business request into measurable quality attributes, justify an architecture style, and document the decision with C4 and ADRs.
Week 1
The architect role, requirements and quality attributes
- What an architect decides and owns
- Functional requirement, quality attribute, constraint
- Quality attribute scenarios and the utility tree
- C4 Level 1 (System Context) and an introduction to ADRs
Lab: Squads elicit requirements for a payment notification service, write 5 quality attribute scenarios and draw a C4 context diagram.
Assignment: Individual: a repository with ADR-001 and a C4 context diagram for your chosen case.
Week 2
Architecture styles: modular monolith, microservices, event-driven
- Modular monolith: boundaries, module rules, when it is enough
- Microservices: team boundaries, deployment independence, the cost of distribution
- Event-driven: events vs commands, eventual consistency, delivery guarantees
- Decision criteria for choosing a style
Lab: Sketch the same case in three styles and fill in a cost/benefit table for each.
Assignment: ADR-002: the style choice, with rejected alternatives and conditions for revisiting it.
Week 3
C4, ADRs and architecture documentation
- C4 Levels 2-3: container and component diagrams
- Diagram rules: legend, title, relationship direction
- ADR lifecycle: proposed, accepted, superseded
- Fitness functions and automated architecture checks
Lab: Cross-review of diagrams: each squad reads another's C4 container diagram and writes 5 questions.
Assignment: Individual: a C4 Level 2 diagram plus at least one fitness function description (for example a module dependency rule).
Checkpoint: For the chosen case: a requirements document, C4 Level 1-2 diagrams and at least three ADRs (including the style choice).
02 · Weeks 4–6
Scale and data architecture
Phase goal: Estimate load and capacity, justify partitioning and replication choices, and decide when CQRS is warranted.
Week 4
Scalability and capacity estimation
- Back-of-the-envelope math: RPS, storage, bandwidth
- Peak load, p95/p99 latency and headroom
- Horizontal vs vertical scaling, stateless design
- Cache layers and invalidation risks
Lab: Estimate daily and peak load for the case, find the first bottleneck and write a load-test plan.
Assignment: Individual: a one-page capacity estimation sheet with assumptions stated openly.
Week 5
Data architecture: partitioning, replication, consistency
- Choosing a partition key and the hot partition problem
- Replication: sync/async, replica lag, failover
- Consistency models and CAP/PACELC in practice
- Transaction boundaries and idempotency
Lab: Data model for a ledger: partition key, replica topology and a failover scenario.
Assignment: ADR-003: the data storage and partitioning decision with consequences and risk notes.
Week 6
Messaging, CQRS and event sourcing: when justified
- Queue vs log (Kafka-style) and selection criteria
- Outbox pattern and idempotent consumers under at-least-once
- CQRS: when to separate read and write models
- The cost of event sourcing: replay, schema evolution, GDPR
Lab: Design an outbox plus idempotent consumer flow for payment status and hold a 'do we need CQRS?' decision meeting.
Assignment: Individual: an ADR that says 'yes' or 'no' to CQRS; rejecting it is a valid answer if justified.
Checkpoint: A capacity estimation sheet, a data model with a partitioning/replication decision, and an ADR that justifies (or rejects) CQRS.
03 · Weeks 7–9
Integration, security and operations
Phase goal: Fold integration with external and legacy systems, security and compliance requirements, and cloud cost into the architecture.
Week 7
Integration architecture: APIs, messaging, legacy
- API design: versioning, backward compatibility, contract testing
- Sync vs async integration and timeout/retry/circuit breaker
- Legacy and bank-style integration: file exchange, SOAP, ISO 20022 messages, nightly batches
- Anti-corruption layer and the strangler approach
Lab: Design a file-based reconciliation integration with a bank core system: format, error handling, resend.
Assignment: Individual: an integration map and an ADR for an anti-corruption layer on one legacy link.
Week 8
Security and compliance architecture
- Threat modeling (STRIDE) and trust boundaries
- AuthN/AuthZ architecture: OIDC, service-to-service trust, secret management
- Data classification, encryption, audit trail, retention
- Compliance frameworks: PCI DSS basics, personal data protection
Lab: A STRIDE session on the case's data flow diagram; at least 8 threats and their mitigations.
Assignment: Individual: a threat model document plus an ADR on the boundary for card and personal data.
Week 9
Cloud cost and operability
- SLI/SLO/error budget and their effect on architecture decisions
- Observability: logs, metrics, traces and alert quality
- Multi-AZ/region, RTO/RPO and disaster recovery tiers
- FinOps: cost model, unit economics, the cost of over-engineering
Lab: Compare three deployment options (single region, multi-AZ, multi-region) on monthly cost and RTO/RPO.
Assignment: Individual: SLOs, a cost model and an ADR for the recommended deployment option.
Checkpoint: An updated architecture pack with an integration map (API/message/file contracts), a threat model, and SLOs plus a cost model.
04 · Weeks 10–12
Technical leadership and architecture defense
Phase goal: Carry architecture decisions through teams and stakeholders with RFCs, roadmaps and communication; defend the final architecture.
Week 10
RFC process, roadmap and technical debt
- The RFC process: who writes, who reviews, how decisions are made
- Classifying technical debt and deliberate vs accidental debt
- Architecture roadmap: phases, dependencies, risks
- Risks of an architecture review board and lightweight alternatives
Lab: Squads write an RFC for the case; another squad acts as formal reviewer and gives written feedback.
Assignment: Individual: a three-phase architecture roadmap and a technical debt register (at least 6 items, prioritised).
Week 11
Stakeholder communication and mentoring
- Explaining a technical decision in business terms: risk, cost, time
- Trade-off discussions and deciding under uncertainty
- Mentoring: growing senior engineers into architectural thinking
- Conflict and alignment: 'disagree and commit'
Lab: Role play: a 10-minute decision briefing to a CFO, a risk manager and a team lead, followed by feedback.
Assignment: Individual: a one-page non-technical executive summary and a mentoring session plan.
Week 12
Capstone: architecture defense
- Assembling and sequencing the final pack
- Defense structure: context, key decisions, trade-offs, risks
- Handling hard questions: 'what if load grows 10x?', 'what if the provider changes?'
- Panel feedback, retrospective and a next-step development plan
Lab: A dress-rehearsal defense inside the squad, then a 25-minute defense before a panel of the instructor and guest engineers.
Assignment: Individual: the final architecture pack (repository) and a one-page self-assessment after the defense.
Checkpoint: The final architecture pack (requirements, C4, ADRs, capacity, data, integration, security, cost, roadmap) defended before a panel.