Software Architecture for Developers is a practical and pragmatic guide to modern software architecture, specifically aimed at software developers. You'll learn:

  • The essence of software architecture.
  • Why the software architecture role should include coding, coaching and collaboration.
  • The things that you really need to think about before coding.
  • How to visualise your software architecture using the C4 model.
  • A lightweight approach to documenting your software.
  • Why there is no conflict between agile and architecture.
  • What "just enough" up front design means.
  • How to identify risks with risk-storming.

Software Architecture for Developers (slides)
O'Reilly Software Architecture Conference - London, England - October 2017

Five things every developer should know about software architecture

Back in 2010, I wrote an article titled Are You a Software Architect?, which looked at the difference and transition between being a software developer and being a software architect. Although the industry has moved on in many ways during the past 8 years, it seems that software development teams are still struggling with some of the basics, especially those aspects related to software architecture. These are arguably more important than ever before, given the distributed nature of the software systems we’re now building, and the distributed nature of the teams building them. As a short introduction to the topic and to debunk some myths, here are five things that every software developer should know about software architecture.

Continue reading...

Sketchnote

Volume 1: Technical leadership and the balance with agility

A developer-friendly, practical and pragmatic guide to lightweight software architecture, technical leadership and the balance with agility.

This book is a practical, pragmatic and lightweight guide to software architecture, specifically aimed at developers, and focussed around the software architecture role and process.

  • Part 1: Software architecture
    • What is "software architecture"?
  • Part 2: The software architecture role
    • The software architecture role
    • Should software architects code?
    • Software architects should be master builders
    • From developer to architect
    • Broadening the T
    • Soft skills
    • Software development is not a relay sport
    • Software architecture introduces control?
    • Mind the gap
    • Where are the software architects of tomorrow?
    • Everybody is an architect, except when they’re not
    • Software architecture as a consultant
  • Part 3: Designing software
    • Architectural drivers
    • Quality Attributes (non-functional requirements)
    • Working with non-functional requirements
    • Constraints
    • Principles
    • Technology is not an implementation detail
    • More layers = more complexity
    • Collaborative design can help and hinder
  • Part 4: Agility and the essence of software architecture
    • The conflict between agile and architecture - myth or reality?
    • Quantifying risk
    • Risk-storming
    • Just enough up front design
    • Agility
    • Introducing software architecture

Related videos

Agile and architecture, finally friends after 15 years
SwanseaCon - Swansea, Wales - September 2016

Agile and architecture; finally friends
ING Loves IT - Bucharest, Romania - April 2017

Volume 2: Visualise, document and explore your software architecture

A short guide to visualising, documenting and exploring your software architecture.

This book focusses on the visual communication and documentation of software architecture, based upon a collection of ideas and techniques that thousands of people across the world have found useful. The core of this is my C4 software architecture model and the software guidebook. You'll also find discussion about notation, the various uses for diagrams, the value of creating a model and tooling.

  • Part 1: Visualise
    • We have a failure to communicate
    • A shared vocabulary
    • The C4 model
    • Level 1: Context diagram
    • Level 2: Container diagram
    • Level 3: Component diagram
    • Level 4: Class diagram
    • Notation
    • Diagrams must reflect reality
    • Other diagrams
  • Part 2: Document
    • Software documentation as a guidebook
    • Context
    • Functional Overview
    • Quality Attributes
    • Constraints
    • Principles
    • Software Architecture
    • Code
    • Data
    • Infrastructure Architecture
    • Deployment
    • Operation and Support
    • Development Environment
    • Decision Log
  • Part 3: Tooling
    • Sketches, diagrams, models and tooling
    • The C4 model with other notations and tools
    • Exploring your software architecture model

Related videos

Visualise, document and explore your software architecture
OpenSlava - Bratislava, Slovakia - October 2017

The art of visualising software architecture
Voxxed Days Athens - Athens, Greece - May 2017

Training

I run a 2-day software architecture training course at organisations across the globe, the content of which is based upon my Software Architecture for Developers books. The agenda is as follows.

Agenda - Day 1
  • [09:00 - 09:15] Introductions
  • [09:15 - 10:00] What is software architecture?
    • A definition of software architecture.
    • The importance of software architecture.
  • [10:00 - 12:00] The software architecture role
    • Software architecture and the ideal software development team.
    • Technical leadership and the different leadership styles.
    • Technical skills.
    • Soft skills.
    • Software architecture and coding.
  • [12:00 - 12:30] Architectural drivers
    • Requirements.
    • Quality attributes.
    • Constraints.
    • Principles.
  • [12:30 - 13:30] Lunch
  • [13:30 - 15:30] Software design/diagramming exercise (iteration 1)
  • [15:30 - 17:00] Software design/diagramming exercise review
Agenda - Day 2
  • [09:00 - 10:00] Visualising software architecture
    • Diagramming anti-patterns and typical problems.
    • UML.
    • The "model-code gap".
    • Creating a shared vocabulary and a ubiquitous language.
    • The "C4 model".
    • Static structure diagrams.
    • Dynamic/behavioural diagrams.
    • Infrastructure and deployment diagrams.
  • [10:00 - 12:30] Software design/diagramming exercise (iteration 2)
  • [12:30 - 13:30] Lunch
  • [13:30 - 14:00] Documenting software architecture
    • The importance of documentation.
    • Writing lightweight supplementary documentation using a "software guidebook" or arc42.
  • [14:00 - 15:30] Tooling
    • Types of tooling used for visualising and documenting software architecture.
    • Bridging the "model-code gap" with architecturally-evident coding styles.
    • Software architecture as code.
    • Exploring the static structure of a codebase.
  • [15:30 - 16:30] Agility
    • Building software systems that have agility as a characteristic.
    • Approaching software architecture in an agile, lightweight way.
    • How much up front design is enough?
  • [16:30 - 17:00] Discussion, questions and wrap-up
Learning outcomes

This 2-day workshop will give you an introduction to a pragmatic and practical approach to software architecture; including technical leadership, communication and how to balance up front design with agile approaches.

Target audience

Software developers and architects; all levels of experience.

Pre-requisites

Some experience building software; no laptops needed.

Timings

The exact timings are flexible, but most courses are typically 09:00-17:00, with a 20-30 minute coffee break mid-morning and mid-afternoon, plus an hour for lunch.

Slides and handouts

The slides and handouts are available to download.

Pricing

The pricing model is "per day" rather than "per attendee", based upon my availability and travel. The class size is flexible; I've run courses for between 5 and 150 people, although I'd recommend between 10 and 30. From a logistics point of view, all I need is a room with a projector and some whiteboards/flip chart paper. I occasionally run public workshops at training providers or conferences but most are private, on-site workshops held directly with organisations.

Please e-mail me for more details and pricing.