Software Architecture for Developers: Volume 2 - Visualise, document and explore your software architecture

Software Architecture for Developers #2

by Simon Brown

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

This book focuses on the visual communication and documentation of software architecture. I've seen a number of debates over the years about whether software development is a craft or an engineering discipline. Although I think it *should* be an engineering discipline, I believe we're a number of years away from this being a reality. So while this book doesn't present a formalized, standardized method to communicate software architecture, it does provide 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.

Genres: Computer Science, Architecture, Programming, Technology, Software, Technical, Nonfiction

197 pages, ebook

First published January 1, 2015

About the author

Simon is an independent software development consultant specializing in software architecture - specifically technical leadership, communication, and lightweight, pragmatic approaches to software architecture. Simon is the author of "Software Architecture for Developers", a developer-friendly guide to software architecture, technical leadership, the balance with agility and communicating software architecture with sketches, diagrams, and models. He is also the creator of the C4 software architecture model and the founder of Structurizr, a SaaS product to create web-based software architecture diagrams using code.

Reviews

[Luboš · Rating 3 out of 5]

It is not a must read book but it helped me to sort out my thoughts about visualising software architecture. Simon Brown introduced his concept of C4 model (Context, Containers, Components and Classes/Code). It is not bad but I am not convinced yet to adapt it. He recommends his tool structurizr but shows how to use UML as well.

unlike the building industry, the software development industry lacks a standard, consistent way to think about, describe and visually communicate software architecture

[Marian · Rating 5 out of 5]

Hard to say about efficiency of the approach, since it’s hard to compare something, that is different from case to case.
Although, the writing style of the book(and it’s first part) is light, compact and enjoyable. It is written not like an engineering guide(like Architecture In Practice) but for everyone that has small idea about Software Architecture. For me, this is the main feature - tell engineers Architecture is not a rocket science.

[Renan Ivo · Rating 3 out of 5]

It delivers what is promised by showing how to create architecture documentations which reflect the codebase. It goes beyond by showing how to generate the documentation automatically from the code using reflection.

I just think some things demonstrated are too specific for some languages/tools. I'll try to figure out a way to apply these concepts in my reality, tough.

[Michael O'Flaherty · Rating 4 out of 5]

I feel Simon is on to something here. I will be trying C4 on my current project because “we are Agile and don’t document anything.” (I say this tongue-in-cheek, but there is truth to it.) His writing style is akin to a brain dump. I feel that both books should have been combined with a stronger emphasis on C4 specifically. My other complaint is that book 2 exceeds the 50 MB Kindle restriction and is a pain to read. I would like a real (faux) use case (using Adventure Works or Fabrikam) that dives deeper into the challenges of using it.

Similar to the Agile manifesto, I hope C4 morphs into a new religion. Simon has already identified a basic layout of a technical document with additional diagrams defined (almost like a C8 evolution?) The genius of C4 is that it is flexible and navigates both liberal and conservative viewpoints on the question of documenting. This is worthy of further refinement, and it would go a long way in making development more respectable and less run-and-gun. I am sold on its potential.

I actually feel for Simon in one respect. Trying to start a movement, articulate it in book form, monetize it with consulting and tooling, and keeping a positive attitude when the naysayers pan everything has to be difficult. Exhausting (but hopefully rewarding.) So, “thank you” for your vision and willingness to propose a new way of doing things. Kudos! I hope you write version 2 after getting some rest.

[سامح دعبس · Rating 4 out of 5]

This volume of the book covers visualizing and documenting software architectures and covers some helpful tools in this area.
Apart of the C4 model, which is very useful visualizing model, and I used it before, I found 2 more impressing ideas in this book:
1- Documenting software architecture as a guidebook that could be read in a couple of hours.
2- Software architecture as a code, where we can write some code to generate the architecture model from the codebase.

This volume just misses a full sample for a "guidebook", which exists in previous versions.
Again, this volume is very useful and I highly recommend it for the rest of all developers aiming to understand what this "software architecture" is.

[The Architect · Rating 4 out of 5]

Personally, this volume gave me more than the previous one (I've been designing architecture on several projects, so I am that "just developer" type) - I have been playing a while to add Architecture as Code principle to my projects and this expanded my horizon a bit more. I would say this volume is more for architects (who are already designing architecture) than pure developers like Volume 1.

The book is based on C4 model - System Context, Containers, Components, Classes hierarchy. At first, the model didn't match my ideas, but I later realized, that the hierarchy is very solid and simplifies structure of system and its lifecycle on several levels - especially Container/Component (deployable units vs parts abstracted with interfaces) is invaluable abstraction useful in devops, configuration and deployment and testing strategies.

[Toni Tassani · Rating 4 out of 5]

The continuation of "Software Architecture for Developers" despite it can be read perfectly alone, this book focuses more on expressing, visualising and sharing the architecture, with practical advices on how to do it. It present a way of representing the architecture, the C4 model, where it is expressed in a well structured (but not too much) way: Context, Containers, Components and Classes. The Code can be the "only single point of truth" but it does not express all the decisions, dependencies and relationships.
Being a visual person as I am, and realising that UML is not always the perfect way to communicate, I found this book really valuable.

[Eelco den Heijer · Rating 3 out of 5]

Part 2 is very different from Part 1; this part is only about diagrams and documentation of your architecture. The author introduces C4; a very lightweight document 'standard'. The author leaves a lot of design choices in creating diagrams to the reader, which gives a lot of freedom to the user, but might affect standardization negatively. The book is not really readable on a Kindle, I had to read it on my Macbook and often zoom in to be able to read the diagrams, hence 3 stars (instead of 4). I did like the many pointers to different documentation tools and static code analyzer tools.

[Yoel Monzón · Rating 5 out of 5]

I highly recommend this book for anyone looking to adopt the C4 Model for creating architecture diagrams. Not only did it provide invaluable guidance for optimizing diagramming processes, but it also opened my eyes to previously overlooked elements, such as the importance of standardization. As a result of this newfound knowledge, I was able to address a long-standing issue within my team of inconsistent diagramming practices stemming from individual tool preferences. Overall, this book is an essential resource for any developer seeking to elevate their architecture diagramming skills.

[Mattjdavidson · Rating 4 out of 5]

It's difficult to not conflate this book with the C4 ideas themselves - which I think are great. Learning to propose design in the C4 model, takes little effort and has huge payoffs in teams that are struggling to document and discuss their design.

I'd really recommend the model, and most of this book as one of the best bangs for your buck for the average software development team.

[Artem · Rating 4 out of 5]

I like the C4 method proposed by the author for the architecture visualization. The book also gives useful templates for the architecture book, and the approach to the continuous architecture documentation. Despite quite a comprehensive list of subjects covered by the template, it didn't cover testing and architecture validation.

[Abel Shen · Rating 4 out of 5]

I like the visualizing and document chapters. The tooling chapter is not that helpful; this book also introduced several reference books such as "arc42 by example" and tools such as "codescene," I think I will have a look at them.

[Cedd · Rating 3 out of 5]

The book makes a good case for documenting architecture, and has some good ideas about how to do so. I struggle to think about how I will change my working practice having read it though.

[Panashe M. · Rating 4 out of 5]

Pretty good. Helped clarify my thinking around what a useful architecture diagram looks like, and has some pretty good advice on documentation too.

[Lóránd · Rating 2 out of 5]

This volume could have been a few extra chapters in the first volume or a 2nd edition maybe. It repeats the core concepts from volume 1 with a few additional topics.

[Sebastian Gebski · Rating 2 out of 5]

Not a surprise this book didn't get that much reverb in the community the previous one (of S.B.) did - it's significantly weaker & it fails where the latter one has succeeded: in structuring / ordering / organizing big, complex domain in a way approachable for junior (& not only) devs. This book is well written, thesis are well argumented, conclusions are valid & understandable but ... there's not much value in that. It won't make you thinking in a different way about what you're doing, what you're drawing & architecture in general. It may (at most) make you nod once or twice, then shrug & go away.

A typical book community would still be good w/o. I can't really identify a proper recipient for it ;/

[Johnny · Rating 2 out of 5]

After the well written book Software Architecture for Developers I hoped for another great work by Simon Brown. Unfortunately, this book is not up to the task. The book is full of good advices, but nothing of them is uniquely new or thought provoking. I didn’t find anything to act on as it was in his earlier book.

[Ben · Rating 3 out of 5]

It has some good ideas and insights but there is a lot of bog standard stuff you have to chug through to find the few gems.

His previous book was better and I would read that, you won't learn much by reading this book

[Mani Sarkar]

Another good book from Simon Brown, based on his Structr concept