Cloud & Infrastructure
Solutions Architecture
Solutions architects decide how a system should be built before anyone builds it, and then explain that decision to people who do not write code. The technical judgement matters, but the job is won or lost on communication.
Start here
Architecture is a role you grow into, not one you enter. You need scar tissue from systems you built and had to live with. If you have not yet, build and operate something first.
Before you begin
- Several years of building software or infrastructure
- Have maintained a system you designed
- Comfortable with at least one cloud provider
- Can write clearly for a non-technical reader
Enough breadth to choose well
Architects do not need to be the best engineer in any one area. They do need to know what each area costs.
RequiredArchitectural patterns
Most problems have been solved before. Recognising which pattern applies saves months, and recognising when none does saves more.
Architectural patterns
Most problems have been solved before. Recognising which pattern applies saves months, and recognising when none does saves more.
What to learn
- Monolith, modular monolith and microservices
- Event-driven architecture
- CQRS and event sourcing in outline
- API gateway and BFF patterns
- Batch versus stream
Practice
Next: Data architecture.
RequiredData architecture
Data outlives applications. Getting this wrong is the most expensive mistake available to an architect.
Data architecture
Data outlives applications. Getting this wrong is the most expensive mistake available to an architect.
What to learn
- Relational versus document versus columnar
- Consistency models
- Partitioning and sharding
- Data retention and residency
- Migration without downtime
Next: Integration.
RequiredIntegration and messaging
Real systems are never one system. The joins are where the failures are.
Integration and messaging
Real systems are never one system. The joins are where the failures are.
What to learn
- Synchronous versus asynchronous
- Message queues and brokers
- Idempotency and exactly-once as a myth
- Contract versioning
- Legacy integration
Tools
- Kafka
- RabbitMQ
- Managed queue services
Next: The non-functional requirements.
The qualities that decide the design
Features determine what a system does. These determine whether it survives.
RequiredNon-functional requirements
Almost every architecture argument is really a disagreement about which of these matters most.
Non-functional requirements
Almost every architecture argument is really a disagreement about which of these matters most.
What to learn
- Availability and recovery objectives
- Scalability and capacity
- Latency budgets
- Security and compliance
- Maintainability
- Cost
Practice
Next: Security and compliance.
RequiredSecurity and compliance by design
Retrofitting compliance is a rebuild. Designing for it is a constraint you can plan around.
Security and compliance by design
Retrofitting compliance is a rebuild. Designing for it is a constraint you can plan around.
What to learn
- Identity and access design
- Encryption and key management
- Network segmentation
- Data residency
- Audit and evidence
Next: Cost.
RequiredCost architecture
In the cloud, architecture is finance. An architect who cannot forecast a bill will lose the room.
Cost architecture
In the cloud, architecture is finance. An architect who cannot forecast a bill will lose the room.
What to learn
- Total cost of ownership
- Managed versus self-hosted trade-offs
- Reserved and spot capacity
- Cost modelling before build
- Explaining cost to finance
Project
intermediateA costed architecture proposal
For a real or realistic requirement, produce a design document: context, constraints, two options with genuine trade-offs, a recommendation, a monthly cost estimate for each, and the risks you accept.
- A diagramming tool
- Your provider's pricing calculator
You can present a design to people who control a budget and answer their questions.
Next: Communicating it.
Communication and influence
The half of the job nobody teaches, and the half that decides whether your designs get built.
RequiredDiagrams and decision records
An undocumented decision gets relitigated every six months by people who do not know why it was made.
Diagrams and decision records
An undocumented decision gets relitigated every six months by people who do not know why it was made.
What to learn
- The C4 model
- Sequence diagrams
- Architecture decision records
- Writing for a non-technical audience
- Knowing which diagram answers which question
Tools
- draw.io or Excalidraw
- Mermaid
- Markdown ADRs
Practice
Next: Working with stakeholders.
RequiredStakeholder management
The best design that nobody agrees to is worth less than the adequate one that ships.
Stakeholder management
The best design that nobody agrees to is worth less than the adequate one that ships.
What to learn
- Eliciting real requirements
- Managing disagreement between teams
- Presenting options rather than decrees
- Negotiating scope
- Knowing when to concede
Next: Delivery.
Seeing it through
Architects who hand over a diagram and leave produce designs that do not survive contact with delivery.
RequiredArchitecture in delivery
Designs drift. Staying involved is what keeps the built system related to the designed one.
Architecture in delivery
Designs drift. Staying involved is what keeps the built system related to the designed one.
What to learn
- Reference architectures
- Design review without becoming a bottleneck
- Fitness functions
- Recognising and paying down architectural debt
Next: Migration.
AdvancedMigration and modernisation
Most architecture work in practice is changing something that already exists and cannot stop working.
Migration and modernisation
Most architecture work in practice is changing something that already exists and cannot stop working.
What to learn
- Strangler fig pattern
- Phased migration
- Dual running and reconciliation
- Rollback planning
- Sequencing to deliver value early
Project
advancedA migration plan
Take a legacy system and plan its modernisation in phases, each independently valuable and independently reversible. Include what you would do if phase two failed.
- A diagramming tool
- ADRs
You have a plan that survives its first setback, which is the only kind worth writing.
Where this leads
You do not have to pick one now. These are the directions this path opens up once you are working.
Continue your journey
The paths closest to this one. Skills overlap more than the job titles suggest.
Cloud Engineering
From never opening a cloud console to running real workloads on one.
ViewPlatform Engineering
Build the internal product that lets every other engineer ship safely.
ViewBackend Development
Build the systems that store, protect and serve everyone's data.
ViewProduct Management
Decide what gets built, why, and what gets cut.
ViewYou do not have to do this alone
Our programs are free, taught live, and built around the same progression. Join one and work through it alongside other people.