Architecture line, station 3 of 4
Software and Solution Architecture
Make and explain architecture decisions: quality attributes, styles, integration, cloud, cost and governance that lasts.
- 7lessons
- 4.5 hto read and do
- Advancedlevel
- 7podcast episodes
- 7checked exercises
Tools you'll use in this course
The lessons open these with a template ready. They work for your own job too, no course needed.
About this course
Architects make the decisions that are expensive to change later, and they make sure everyone understands them. This course teaches how to do that well: start from the quality attributes the business needs, compare options honestly, write decisions down, draw diagrams people can read, and keep the architecture healthy as the system and the teams grow.
You act as solution architect for Mangrove Market's move from one large back-office application to a set of well-bounded parts that support 320 stores, the customer app and 1,800 partner shops. You run a quality-attribute workshop, choose between a modular monolith and microservices, design event-driven integration with the Partner app and decide who owns which data, plan the cloud setup with reliability, security and cost in mind, record decisions as ADRs, draw C4 diagrams, run an architecture review with fitness functions, and plan a strangler-fig migration that keeps the stores trading every day.
Each lesson has diagrams, a worked Mangrove example, templates you can reuse, quick checks, practice tasks (some auto-checked in your browser), flashcards and a podcast episode. The course project is a full architecture proposal you defend in a review, and the final exam earns a free certificate.
What you will be able to do
- Turn business goals into measurable quality attributes and constraints
- Compare architecture styles and choose with explicit trade-offs
- Design integration with APIs, events and data contracts
- Plan cloud architecture with reliability, security and cost in mind
- Communicate and govern decisions with ADRs, C4 diagrams, reviews and fitness functions
Syllabus
7 stops, about 4.5 h in total. Each stop fills in when you complete the lesson.
What architects actually do
An architect's real output is decisions: the few choices that are expensive to change, made with honest trade-offs and carried by people who do not report to you. This lesson gives you a test for which decisions are yours, the difference between software, solution and enterprise architects, and a way to lead without a manager's authority.
Solution architectureArchitecture decision recordsArchitecture governance
Quality attributes and constraints
Every stakeholder wants the new system to be "fast, reliable and easy to change", and none of those words can be designed or tested. This lesson shows how to run a workshop that turns them into a short list of measurable scenarios and named constraints, so the architecture is chosen for reasons everyone signed.
Quality attributesSolution architectureQuality attribute scenariosStakeholder workshops
Choosing an architecture style
Teams often pick a style because a famous company uses it or because the last project hurt. This lesson gives you a method that starts from your quality-attribute scenarios, removes options that break a hard constraint, scores the rest with anchored evidence, and then tests how fragile the result is. You apply it to Mangrove Market's back office, where modular monolith, microservices, event-driven and serverless all have honest supporters.
Solution architectureQuality attributesEvent-driven architectureTrade-off analysis
Integration and data ownership
When every team can write every table, one column change breaks three apps. This lesson gives you a method to name one owner for each kind of data, pick an API call, an event or a batch feed for each connection, and write contracts that let teams change without breaking each other.
Solution architectureEvent-driven architectureData ownershipIntegration contracts
Cloud architecture and cost
In the cloud, every design choice turns up on a monthly bill, and a weak foundation turns up in security incidents. This lesson gives you three tools that architects use to keep both under control: the well-architected review, the landing zone and the FinOps loop.
Cloud architectureFinOpsQuality attributesArchitecture governance
Decisions, diagrams and reviews
An architecture lives in people's heads until you write it down. This lesson gives you four tools that keep it alive as the system and the teams grow: ADRs that record why, C4 diagrams that show what, reviews that find the trade-offs, and fitness functions that check the decisions on every build.
Architecture decision recordsC4 modelArchitecture governanceQuality attributes
Evolving a legacy system
Mangrove's back office earns money every day, and it is hard to change. This lesson gives you a method to replace it piece by piece: decide what to replace at all, find the seams, sequence the slices, move data out of the shared database, and prove each step before you switch, while all 320 stores keep trading.
Solution architectureArchitecture governanceEvent-driven architecture
Capstone: Architect Mangrove's back-office modernisation
A realistic project with a rubric and a model answer.
Final exam and certificate
10 questions drawn at random, 70% to pass.
Capstone project
Architect Mangrove's back-office modernisation
Mangrove's back office is one large application with one shared database. Buyers, store managers, finance and the Partner app team all change it, releases happen once a month, and a slow stock report has twice frozen goods receiving in the stores. Ken, the engineering manager, asks you to propose the target architecture, the migration path and the governance that keeps it on track, and to defend it in an architecture review. Start from the business drivers and quality-attribute scenarios, compare at least two styles honestly, decide which parts to extract first and who owns which data, plan the cloud setup and its monthly cost, and lay out a migration that keeps all 320 stores and the partner shops trading at every step.
You will hand in
- A list of business drivers, constraints and at least six quality-attribute scenarios with measures
- C4 context and container diagrams of the target, plus one component diagram
- Five ADRs, each with context, options, decision and consequences
- An integration and data-ownership map with event contracts
- A migration roadmap with steps, risks, rollback points and cost estimates
Check what you know
Already know some of this? Answer 7 quick questions, one from each lesson, and we will mark the lessons you can skim. It takes about 4 minutes and nothing is graded.
Questions
How long does the course take?
About four and a half hours for the seven lessons, roughly 30 to 45 minutes each, plus 10 to 15 hours for the project.
Do I need to be a senior engineer?
It helps. The course assumes you can follow system design discussions; System Design Case Studies and Distributed Systems are the recommended base, and each lesson links to the earlier lesson it builds on.
Does it prepare me for cloud architect certificates?
It teaches the thinking behind them. The cloud lesson is vendor-neutral and names the equivalent services and well-architected frameworks in the major clouds, but it does not cover any one exam's syllabus.
Which diagram and decision tools do I need?
None in particular. C4 diagrams can be drawn on paper, in draw.io or as code, and ADRs are short Markdown files kept next to the code.
Is the certificate free?
Yes. All lessons, podcasts, exercises, the final exam and the certificate you earn by passing it are free.
Is it really free?
Yes. Every lesson, podcast episode, exercise, quiz, final exam and certificate is free. The labs and their templates for real work are free too. Plus and Premium add every lab challenge, weekly extras and a mentor on top, and they never lock the tools or the courses.
How does the final exam work?
You get 15 questions drawn at random from a larger bank. You need 70% to pass. If you do not pass, you can try again after 24 hours. The exam is graded on the server and you never see the answer key.