Solution Architecture
Turn a business need into a working solution, with quality attributes, constraints and documented decisions.
This program is planned and not scheduled yet. No date, price or cohort has been announced. If you register interest, we contact you when it is scheduled or to discuss an individual format.
Objective
The program teaches how to go from business requirements to a justified solution architecture: making quality attributes measurable, choosing a suitable style and integration pattern, designing data and security, and weighing cloud and cost trade-offs. The result is a solution documented with C4 and ADRs that has been through a review.
Who it's for
- Senior backend engineers and tech leads working with several services and integrations
- Engineers preparing to own architectural decisions for a project
- Systems analysts and technical leaders with a deep technical base
- People who want to take part in and run architecture reviews
Who it's not for
- Those still learning backend and database fundamentals
- Those seeking certification prep for one cloud provider; the program teaches a provider-neutral approach
- Those who only want to draw diagrams; the goal is a justified decision
Prerequisites
- Experience with microservice or modular monolith systems
- Solid grounding in HTTP APIs, messaging and SQL
- Familiarity with core system design ideas (CAP, caching, scaling)
- Readiness to explain an architectural decision from a past project
What you will be able to do
What you will be able to do
- Derive quality attribute scenarios and a list of constraints from business requirements
- Choose between monolith, modular monolith, microservices and event-driven styles with justification
- Pick an integration pattern (synchronous, asynchronous, event, batch) according to need
- Design data ownership, consistency and a migration strategy
- Justify security architecture using threat modelling
- Document the solution with C4 diagrams and ADRs and defend it in an architecture review
No education program can guarantee employment or a promotion.
Curriculum
Curriculum
- 01
Requirements, quality attributes and constraints
Turn a vague business wish into verifiable quality scenarios.
- Functional versus non-functional requirements
- Quality attribute scenario format
- Constraints: budget, team, regulation, legacy
- Trade-offs between attributes
- Surfacing ambiguity in requirements
Hands-on lab: From a given business description, produce eight quality scenarios and a prioritised constraint list.
- 02
Architecture styles and boundaries
Judge style choice in the context of team, requirements and growth stage.
- Monolith, modular monolith and microservice trade-offs
- Domain boundaries and bounded contexts
- Event-driven architecture and its cost
- Layered and hexagonal, and where each fits
- Evolutionary architecture and migration paths
Hands-on lab: Produce two style options for the same requirements, with a comparison table and a recommendation.
- 03
Integration patterns
Build reliable, change-tolerant links between systems.
- Choosing synchronous APIs versus asynchronous messaging
- Idempotency, retries and the outbox pattern
- API versioning and contract evolution
- Anti-corruption layer and external systems
- Saga and alternatives to distributed transactions
Hands-on lab: Design an integration flow with a payment provider and a warehouse system and tabulate the failure scenarios.
- 04
Data architecture
Balance data ownership, consistency and reporting needs.
- Per-service data and the shared database risk
- Choosing strong versus eventual consistency
- CQRS, read models and caching
- Data migration and zero-downtime approaches
- Separating analytical and operational data
Hands-on lab: A data ownership map for an order domain and a migration plan from a legacy database.
- 05
Security architecture
Build security into the design, not on top of it.
- Threat modelling (STRIDE)
- Authentication, authorisation and OAuth 2.0 / OIDC flows
- Trust boundaries and network segmentation
- Secrets management and encryption
- Checking against the OWASP API Security Top 10
Hands-on lab: For a given solution, a trust boundary diagram, a threat list and mitigations.
- 06
Cloud, resilience and cost trade-offs
Connect deployment model, resilience and cost to requirements.
- Managed service versus self-operated trade-off
- Multi-zone resilience, RTO and RPO
- Cost of complexity and vendor dependency
- Capacity and cost modelling
- Observability requirements in the architecture
Hands-on lab: A resilience and cost trade-off table for two deployment options (numbers recorded as assumptions).
- 07
Documentation with C4 and ADRs
Keep architecture clear for different audiences and easy to update.
- C4: context, container and component levels
- What to show and not show at each level
- How ADRs and diagrams relate
- Keeping documentation current and owned
- Dynamic and deployment diagrams
Hands-on lab: A set of C4 diagrams from context to component for a case study.
- 08
Architecture reviews and working with delivery teams
Carry an architectural decision to the team and protect it during delivery.
- Architecture review formats and criteria
- A lightweight ATAM-style approach
- Fitness functions and automated checks
- Collaborating with the delivery team
- Managing decision drift
Hands-on lab: Run a mock architecture review of another participant's solution and write up the result.
Practice assignments
- A quality scenarios and constraints document
- A comparison of two style options
- A threat model and mitigation plan
- A full C4 and ADR set for the case study
- A written result of a mock review
Portfolio deliverables
- A solution architecture document for a case study
- A C4 diagram set (context, container, component)
- An architecture decision record (ADR) set
- A threat model and an integration map
How learning is assessed
- Defense of the solution architecture before a simulated review panel
- Written evaluation of the ADR and C4 set
- Evaluation through running a mock review and giving feedback (recommendations, not a certificate)
Tools and technologies
- C4 model
- Structurizr / Mermaid / PlantUML
- ADR (Markdown)
- OpenAPI / AsyncAPI
- Kafka / RabbitMQ (conceptual)
- PostgreSQL
- OAuth 2.0 / OIDC
- Terraform (at reading level)
Level progression
- Before
- Senior backend engineer or tech lead level, with system design experience.
- After
- The enterprise architecture program, or practice in a solution architect role.
- Length and format
- Length and format are not set yet; the program is planned and not scheduled.
Frequently asked questions
Frequently asked questions
Is this program available now?
No. It is planned and not scheduled. No dates or prices are announced. You can request a consultation.
Is the program tied to a specific cloud provider?
No. The approach is provider-neutral. Examples may name tools, but the aim is decision principles.
Does it promise a certificate or a title?
No. No program guarantees a certificate, title or outcome. Assessment is advisory.
Is drawing diagrams the main part?
No. Diagrams exist to communicate a decision. The main work is understanding requirements, weighing trade-offs and justifying the decision.
Articles related to this program
- ADRsWriting Architecture Decision Records that survive the team
- C4 modelThe C4 model: architecture diagrams that people actually read
- System designCaching strategies - cache-aside, write-through, TTLs and stampedes
- Cloud architectureCloud architecture basics for backend engineers
- Distributed systemsFailure handling in distributed systems
- Distributed systemsIdempotency patterns for safe retries