Stage 1 of 5 · 7 lessons · ~2 months

Owning architecture across teams

At this level the hard design problems sit between teams: shared data, service boundaries, platform choices and build versus buy. Own those decisions, write down the trade-offs, and keep the system something the organisation can operate.

Start: Service and data ownership boundaries

Lessons· one lesson for each topic, in this order

Start with· follow one of these

CoursePaid
System Design Patterns: From Fundamentals to Real Systems
Design Gurus · Intermediate · Subscription
The distributed patterns behind most designs, to judge proposals from other teams
GuideFree
Martin Fowler's Website
Martin Fowler · Intermediate
Free, clear writing on architecture styles, microservices and evolving designs

Keep handy

Architectural Decision Records
Templates for recording cross-team decisions where everyone can find them

Also worth your time

10 Must-know System Design Failure Modes (opens in a new tab)Read
Ten ways systems fail, to check any cross-team design against
Software Architecture: The Hard PartsGo deeperPaid
Trade-off analysis for splitting services and data, with no fake right answers

Before moving on: Write and defend a design doc for a change that affects at least two teams, with rejected alternatives and an operating cost estimate, and record the decision as an ADR both teams can find.

Tauseef's advice

Default to the boring architecture the organisation can run at 3am, and ask anyone proposing a new platform which problem it solves first. Cross-team designs fail on ownership more often than on technology, so name who owns each piece and who gets paged.