What do you think?
Rate this book
Software Architecture for Developers #1
Software Architecture for Developers: 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 focused around the software architecture role and process.
This book is a practical, pragmatic and lightweight guide to software architecture, specifically aimed at developers, and focused around the software architecture role and process.
133 pages, ebook
First published June 22, 2012
60 people are currently reading
1537 people want to read
About the author
Simon Brown
8 books60 followersSimon 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.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 40 reviews
April 24, 2013
Warning: this review is based on the pre-released leanpub version of the book with some chapters still missing. I'll check out the released version and update my review when it's ready.
I'd rather gave the book 5 stars as its subject is indeed relevant and its ideas appeal very much to my agile and lean taste. This book will definitely help you approach software architecture in a lightweight manner avoiding rework in the near future, analysis paralysis and big design upfront. I highly recommend it to anyone working in software development.
I gave the book only 3 stars though because I didn't like 2 major points about the way those ideas are delivered.
First, the book is a series of essays. Though they are logically ordered, I missed the storyline throughout the book. I know it's a non-fiction, but the book in my opinion is too much about making the case for the method it presents, rather than actually describing and guiding the reader through the method. Essays also contain a lot of repetition, I've encountered some passages like three or four times in the book.
Second, I didn't like how the book tries to position itself against Agile. Though the book actually promotes quick feedback loops, iterative and incremental delivery, it in my opinion misrepresents agile as lacking any design activities. I think how the work stream is managed and what activities it contains is completely orthogonal. That's why the book would appeal much better to me if it focused itself on integrating architecture activities in management practices rather fighting them (it equally fights waterfall to be fair).
I'd rather gave the book 5 stars as its subject is indeed relevant and its ideas appeal very much to my agile and lean taste. This book will definitely help you approach software architecture in a lightweight manner avoiding rework in the near future, analysis paralysis and big design upfront. I highly recommend it to anyone working in software development.
I gave the book only 3 stars though because I didn't like 2 major points about the way those ideas are delivered.
First, the book is a series of essays. Though they are logically ordered, I missed the storyline throughout the book. I know it's a non-fiction, but the book in my opinion is too much about making the case for the method it presents, rather than actually describing and guiding the reader through the method. Essays also contain a lot of repetition, I've encountered some passages like three or four times in the book.
Second, I didn't like how the book tries to position itself against Agile. Though the book actually promotes quick feedback loops, iterative and incremental delivery, it in my opinion misrepresents agile as lacking any design activities. I think how the work stream is managed and what activities it contains is completely orthogonal. That's why the book would appeal much better to me if it focused itself on integrating architecture activities in management practices rather fighting them (it equally fights waterfall to be fair).
December 31, 2012
This is a great book about software architecture and how to share its structure and vision. The author, Simon Brown, shown us his pragmatic side in this overview of what is software architecture. I did particularly enjoy the parts about the role and how to design and communicate software. Must read for any developer or software architect!
November 5, 2019
The first part of the book is fantastic. I can't reocmmend it highly enough for a professional software dveeloper that wishes to elevate him or herself to a higher standard. The SECOND part was more difficult for me to digest. Anyway, I didn't regret of buying it.
March 19, 2018
This book takes most effort into explaining why software architecture is important and how you can have "just enough" upfront design and be agile. I was looking for "hands on" architecture practices, which seems to be left to the second volume.
May 19, 2014
Simon Brown shows in his book “Software Architecture for Developers” how many so-called “agile projects” work: Ignore all documentation, architecture and just write code. If you ever worked in a project where the person in the role of a software architect abused this role to hide his incompetence you can sympathise with the just code approach.
However, if you need to build something that can’t be done in a few weeks you need to care for the overall structure. If you do this as a team effort or with a dedicated role for architecture may vary by project. For both ways you find guidance in this book.
As Simon Brown explains this doesn’t mean you need to go back to big upfront planning. Architecture and agile projects are not a contradiction and can work together. The big picture is relevant and with timely feedback architectural decisions can be validated as you (hopefully) do it with business requirements on a daily basis.
With so many examples from the real world and fitting solutions to the discovered problems I can highly recommend you to read this book.
However, if you need to build something that can’t be done in a few weeks you need to care for the overall structure. If you do this as a team effort or with a dedicated role for architecture may vary by project. For both ways you find guidance in this book.
As Simon Brown explains this doesn’t mean you need to go back to big upfront planning. Architecture and agile projects are not a contradiction and can work together. The big picture is relevant and with timely feedback architectural decisions can be validated as you (hopefully) do it with business requirements on a daily basis.
With so many examples from the real world and fitting solutions to the discovered problems I can highly recommend you to read this book.
September 27, 2019
The book matches exactly its name. If you are a developer and you want to know what the heck is that "software architecture" and who are those (astronauts) "architects"?, then this book should be the first to read.
This book help you understand:
- What is architecture?
- Who are architects and what they do?
- How architects create architectures?
and under every question, you will find some other interesting topics like:
- The conflict between architecture and agile
- Do architects write code?
- How much up-front design
and many more good stuff.
The only thing I believe missed from the book is "Evaluating Architectures", which is well covered in the book "Design It!".
I highly recommend this book for the rest of all developers.
This book help you understand:
- What is architecture?
- Who are architects and what they do?
- How architects create architectures?
and under every question, you will find some other interesting topics like:
- The conflict between architecture and agile
- Do architects write code?
- How much up-front design
and many more good stuff.
The only thing I believe missed from the book is "Evaluating Architectures", which is well covered in the book "Design It!".
I highly recommend this book for the rest of all developers.
December 8, 2016
A pretty decent book about the Software Architecture, promoting the concept of the coding architect. The pros of this book are that in one place it gathers strong arguments why SW architecture matters and how to promote these ideas.
I would recommend this book either to some aspirant to the architect role, or even to any senior developer who cares about the context of his project, solution and technology. On the other hand, any architect practitioner, who has a few years of experience with the subject, probably won't find many new ideas here.
That's also my story - I can't agree more with what is said in the book, but I had found almost everything intuitively by myself before. Therefore, I'm rather looking forward to the next volume Visualise, document and explore your software architecture, which looks more promising.
One negative point, I'm going to mention: it's clear that there was no editor/corrector. In too many places the author just copy-pasted some paragraphs. It's too frequent and it's annoying.
I would recommend this book either to some aspirant to the architect role, or even to any senior developer who cares about the context of his project, solution and technology. On the other hand, any architect practitioner, who has a few years of experience with the subject, probably won't find many new ideas here.
That's also my story - I can't agree more with what is said in the book, but I had found almost everything intuitively by myself before. Therefore, I'm rather looking forward to the next volume Visualise, document and explore your software architecture, which looks more promising.
One negative point, I'm going to mention: it's clear that there was no editor/corrector. In too many places the author just copy-pasted some paragraphs. It's too frequent and it's annoying.
October 3, 2019
This book is a lightweight guide to software architecture for developers. Book talks about software architecture and its benefit and also talks about software architect role.
Book explains C4 model with details and provide advices for designing and implementing a software system by using this model.
I think book content does not have good structure and so could not provide good knowledge about software architecture and architect role.
Book explains C4 model with details and provide advices for designing and implementing a software system by using this model.
I think book content does not have good structure and so could not provide good knowledge about software architecture and architect role.
January 26, 2019
Volume 1 of Software Architecture for Developers has been on my to-read list for a long while.
Before jumping into this book, I went through other popular software architecture books and developed some personal practical experience and opinions about software architecture in the past 2 years.
I suggest as compliments to the learning experience of the book this presentation (https://www.youtube.com/watch?v=YmdTy...) of Simon Brown. It's a nice overview of some of his point and better strengthens some of the points that you're going to see through the book.
But focusing on the book, as many other software architecture book authors have noted, being a Software Architect is not an easy task. It's a role and not a title. Dictatorship rarely works and when it does, it's the organization's choice to practice this approach, not cause you're an architect. It's to your benefit to be adapting and do the best you can in the environment you have.
Given the difficulties of the role, the book *does not talk about UML, SysML, BPMN, architecture diagrams and tools that you can use*.
As other reviewers have noted, the content is a collection of essays. They say that they're not really ordered, but in my opinion, it's structured enough to make sense of it.
The start of a learning experience is very important. Part "1. Architecture" starts with defining what software architecture is for the author, what types of architecture exist and what they are.
What the benefits of software architecture are, is a very important highlight.
For better or worse, as Simon Brown points out, with the exponentially increasing popularity, training and "organization interest" in Agile, people jumped the train with something that they don't really understand that well. The Agile manifesto is a well thought out compilation of values that software system/projects must have, but it does not exclude the "less valuable" part of the examples, such as "working code vs documentation". The later is still important and must not be omitted.
Technical leadership is a must have. Agile does not argue against it, although non-technical and even "technical" agile trainers and practitioners would argue against it.
Simon... says valid points why Software Architecture is still a must in an agile workflow. However Agile battles the worst-cases of software architecting where "design up front" is taken to the extreme where it's "huge design upfront" without actual prototypes or validation of the approach chosen. The spectrum goes in the other way - no design at all upfront. Finding balance between going full no-brain Agile and extreme Waterfall "huge design upfront" is key. As many other experienced industry veterans have said: "big design up front is bad, but no design upfront at all is just naive".
The industry people have also changed. Fewer people understand and/or are interested to learn how to read software architecture diagrams. They may have poor or no understanding of UML, design patterns and common system architecture. Does this mean that we throw the towel and blame it on the people? No.
We have to adapt and be better at how we present information and make sure that it's understandable by our audience.
As Simon points out, there's chaotic, teaching and self-organizing leadership.
Chaotic is the most hands-on approach without creative freedom, it's only a survival mode move.
Teaching is the "in the middle" approach where you have to do it if you want to go next for "self-organizing" leadership, where everybody is able to collaborate and drive forward with a clear vision of the product and software.
How to overcome the "teaching" phase? Simon very thoughtfully points out to *mind the gap* and actually help them understand your vision, how you can help them and how they can help you. It's a collaborative effort and you want to learn from each other. You don't want to be a "Seagull architect" that craps decisions and architecture on people and leave them to it.
The points that are pointed out as negative of not being collaborative are:
* The development team doesn’t respect the architect, regardless of whether the architect’s decisions are appropriate or not.
* The development team becomes demotivated.
* Important decisions fall between the gap, because responsibilities aren’t well defined.
* The project eventually suffers because nobody is looking after the big picture.
Many more can be told of what you can gain as insights from experience as software architect and from comparing with the views written in the book.
Read it.
Before jumping into this book, I went through other popular software architecture books and developed some personal practical experience and opinions about software architecture in the past 2 years.
I suggest as compliments to the learning experience of the book this presentation (https://www.youtube.com/watch?v=YmdTy...) of Simon Brown. It's a nice overview of some of his point and better strengthens some of the points that you're going to see through the book.
But focusing on the book, as many other software architecture book authors have noted, being a Software Architect is not an easy task. It's a role and not a title. Dictatorship rarely works and when it does, it's the organization's choice to practice this approach, not cause you're an architect. It's to your benefit to be adapting and do the best you can in the environment you have.
Given the difficulties of the role, the book *does not talk about UML, SysML, BPMN, architecture diagrams and tools that you can use*.
As other reviewers have noted, the content is a collection of essays. They say that they're not really ordered, but in my opinion, it's structured enough to make sense of it.
The start of a learning experience is very important. Part "1. Architecture" starts with defining what software architecture is for the author, what types of architecture exist and what they are.
What the benefits of software architecture are, is a very important highlight.
For better or worse, as Simon Brown points out, with the exponentially increasing popularity, training and "organization interest" in Agile, people jumped the train with something that they don't really understand that well. The Agile manifesto is a well thought out compilation of values that software system/projects must have, but it does not exclude the "less valuable" part of the examples, such as "working code vs documentation". The later is still important and must not be omitted.
Technical leadership is a must have. Agile does not argue against it, although non-technical and even "technical" agile trainers and practitioners would argue against it.
Simon... says valid points why Software Architecture is still a must in an agile workflow. However Agile battles the worst-cases of software architecting where "design up front" is taken to the extreme where it's "huge design upfront" without actual prototypes or validation of the approach chosen. The spectrum goes in the other way - no design at all upfront. Finding balance between going full no-brain Agile and extreme Waterfall "huge design upfront" is key. As many other experienced industry veterans have said: "big design up front is bad, but no design upfront at all is just naive".
The industry people have also changed. Fewer people understand and/or are interested to learn how to read software architecture diagrams. They may have poor or no understanding of UML, design patterns and common system architecture. Does this mean that we throw the towel and blame it on the people? No.
We have to adapt and be better at how we present information and make sure that it's understandable by our audience.
As Simon points out, there's chaotic, teaching and self-organizing leadership.
Chaotic is the most hands-on approach without creative freedom, it's only a survival mode move.
Teaching is the "in the middle" approach where you have to do it if you want to go next for "self-organizing" leadership, where everybody is able to collaborate and drive forward with a clear vision of the product and software.
How to overcome the "teaching" phase? Simon very thoughtfully points out to *mind the gap* and actually help them understand your vision, how you can help them and how they can help you. It's a collaborative effort and you want to learn from each other. You don't want to be a "Seagull architect" that craps decisions and architecture on people and leave them to it.
The points that are pointed out as negative of not being collaborative are:
* The development team doesn’t respect the architect, regardless of whether the architect’s decisions are appropriate or not.
* The development team becomes demotivated.
* Important decisions fall between the gap, because responsibilities aren’t well defined.
* The project eventually suffers because nobody is looking after the big picture.
Many more can be told of what you can gain as insights from experience as software architect and from comparing with the views written in the book.
Read it.
March 21, 2024
This book has provided me with a more explicit understanding of software architecture and the software architect role. It remains quite vague since, understandably, so much depends on the context in which you do architecture. In my opinion there was too much repetition between the various parts, especially in part three.
May 27, 2019
As contained in the title "... Technical leadership and the balance with agility" this book takes a step away from the concrete architectural implementations and focuses rather on how to approach the architecture like: what has to be taken in account, diagrams, how to deal with team ..s
October 5, 2019
Types of Architecture
Infrastructure
Security
Technical
Solution
Network
Data
Hardware
Enterprise
Application
System
Integration
IT
Database
Information
Process
Business
Software
All of these types of architecture have structure and vision in common.
Application architecture is predominantly about software and the organization of the code.
The system architecture includes the concerns around interoperability and integration with other systems within the environment.
Software architecture is simply the combination of application and system architecture.
Enterprise architecture generally refers to the sort of work that happens centrally and across an organization. It looks at how to organize and utilize people, process ad technology to make an organization work effectively and efficiently. Enterprise architecture requires a higher level of abstraction. It is about breadth rather than depth and strategy rather than code.
All architecture is design but not all design is architecture.
Architecture represents the significant design decisions that shape a system where significance is measured by the cost of change.
Agility requires good communication.
The code doesn't tell the whole story.
If you don't ask the right questions, you won't get the right answers - you don't know what you don't know.
The following headings describe what you might want to include in a software guidebook:
1. Context
2. Functional overview
3. Quality Attributes
4. Constraints
5. Principles
6. Software Architecture
7. External Interfaces
8. Code
9. Data
10. Infrastructure Architecture
11. Deployment
12. Operation and support
13. Decision log
Infrastructure
Security
Technical
Solution
Network
Data
Hardware
Enterprise
Application
System
Integration
IT
Database
Information
Process
Business
Software
All of these types of architecture have structure and vision in common.
Application architecture is predominantly about software and the organization of the code.
The system architecture includes the concerns around interoperability and integration with other systems within the environment.
Software architecture is simply the combination of application and system architecture.
Enterprise architecture generally refers to the sort of work that happens centrally and across an organization. It looks at how to organize and utilize people, process ad technology to make an organization work effectively and efficiently. Enterprise architecture requires a higher level of abstraction. It is about breadth rather than depth and strategy rather than code.
All architecture is design but not all design is architecture.
Architecture represents the significant design decisions that shape a system where significance is measured by the cost of change.
Agility requires good communication.
The code doesn't tell the whole story.
If you don't ask the right questions, you won't get the right answers - you don't know what you don't know.
The following headings describe what you might want to include in a software guidebook:
1. Context
2. Functional overview
3. Quality Attributes
4. Constraints
5. Principles
6. Software Architecture
7. External Interfaces
8. Code
9. Data
10. Infrastructure Architecture
11. Deployment
12. Operation and support
13. Decision log
April 25, 2018
This one of the best technical books I've read although it doesn't contain any code. It makes clear so many otherwise confusing and fuzzy things.
First, the definition and explanation of what is Software Architecture, the main functions an architect should be doing, the explanation about where it comes from in the ancient times make clear the idea of what SA is about very clear.
Also, the explanation about how to introduce SA in your company or team, the remarks about the importance and the dangers of not doing it makes this book a required read to every person involved in serious software development.
This book states clearly that software architecture is still a technical role and at the same time a leadership role, so you can understand why another skill beyond programming or technical knowledge are required.
Finally, the practical part about how to practice SA and how to improve one's skill in it is interesting and actionable making it very valuable.
Maybe this book could also include the volume II to make a complete book on the subject.
First, the definition and explanation of what is Software Architecture, the main functions an architect should be doing, the explanation about where it comes from in the ancient times make clear the idea of what SA is about very clear.
Also, the explanation about how to introduce SA in your company or team, the remarks about the importance and the dangers of not doing it makes this book a required read to every person involved in serious software development.
This book states clearly that software architecture is still a technical role and at the same time a leadership role, so you can understand why another skill beyond programming or technical knowledge are required.
Finally, the practical part about how to practice SA and how to improve one's skill in it is interesting and actionable making it very valuable.
Maybe this book could also include the volume II to make a complete book on the subject.
August 17, 2017
The book seems to me like a collection of university essays on different topics related to software architecture. In most cases, it simply conveyed the parts of the role and is a guidebook if you ever find yourself an architect. I didn't find it inspiring, and I'm certainly not going to come back to it in moments of hard architecture decisions, and felt quite unlike Simon's speeches or his general vibe of inspiration.
Good parts:
* Structured breakdown of the role
* Lists of things to consider when starting or consulting a large project
* Tips on visualising architecture
* Great source if you're writing your thesis
Not so good parts:
* No drive, inspiration or attention-grasping, all quite dry
* Lots of watery chapters which don't really say anything
* Not much to help you become a better architect
Good parts:
* Structured breakdown of the role
* Lists of things to consider when starting or consulting a large project
* Tips on visualising architecture
* Great source if you're writing your thesis
Not so good parts:
* No drive, inspiration or attention-grasping, all quite dry
* Lots of watery chapters which don't really say anything
* Not much to help you become a better architect
November 5, 2022
this was written by an IT consultant which to me screams it is not for developers. this feels like a great reason for enterprise IT architects to adapt a more flexible, inclusive strategy that involves them coding.
if you're already doing software development and you want to get into architecture, this is just a massive list of definitions and feels like it doesn't add much value in terms of practices and figuring out how to architect systems.
you're honestly better off reading Designing Data-Intensive Applications and the Gang of Four book to cobble together a list of practices and patterns at both the localized level (functions and modules) and the broad level (distributed systems).
if you're already doing software development and you want to get into architecture, this is just a massive list of definitions and feels like it doesn't add much value in terms of practices and figuring out how to architect systems.
you're honestly better off reading Designing Data-Intensive Applications and the Gang of Four book to cobble together a list of practices and patterns at both the localized level (functions and modules) and the broad level (distributed systems).
August 17, 2014
I have mixed feelings concerning this one. I'm a big fan of Simon Browns blog and public speakings. And expected the book to be more than composed and slightly modified blog posts. Unfortunately that's the case. But I liked chapters concerning documenting an architecture and last part of the book covering how much architecture is enough was inspiring.
January 20, 2017
A great introduction to the topic: coding architect. Extra points for being short.
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.
February 15, 2018
Too much water - this book could be 2 times shorter with the same amount of useful information. But it is useful nevertheless.
July 12, 2021
The only drawback of this book for me is a little lack of examples or real-life stories.
However, from my current dev position it is more than 4 stars for sure.
Now, I want to briefly describe why I actually like this book.
First of all, what I find really interesting is the fact how the author thinks about software development in general. For him (and I totally agree with that position) it is more about people than technology. Just by looking at any chapter in this book you can see examples of questions that people tend to ask when taking some of the approaches author are protecting. I find it quite rare nowadays to see the dialog in a book or article rather than just a writer monolog. Tomb up for that.
Therefore, if we assert that a team is actually the most important part to reach our goal (deliver any product), we should concentrate on different aspects that can help the team to be more efficient. And that's exactly what this book is about.
First few chapters are about the relationship between team and architect and how to make it easy going.
After that goes the actual meaning of the architecture and the reasoning behind doing that (in our today's agile environments). Here I really liked the part about non-functional requirements.
Examples of quality attributes that not only architects but all the team should always think about and consider while developing/maintaining the product:
- Security
- Performance
- Availability
- Scalability
- Disaster recovery
- Monitoring
- Management (not the same as managers work) it is an ability to modify the runtime topology of a system, modify configuration elements, etc
- Audit is to keep a log of events (audit log) that led to a change in data or behaviour of a software system. Typically such logs needs to capture information related to who made the change, when and why the change was made.
- Flexibility is doing more than one task or doing the task in different ways.
- Extensibility
- Globalization
- Maintainability
All of this topics and many others should be taken into account, and the great statement here is that anything is possible, but everything has a trade-off.
Next chapters are mostly about the better ways how we can visualize our system. Here the C4 diagrams comes into place. Here what I really like is the writer notes that each diagram should mostly focus on one level of abstraction. Simple but pretty important thing which we tend to forget from time to time. Also an interesting argument from the author is that by forcing people to include technology choices on their software architecture diagrams also tends to lead to much richer and deeper conversations that are grounded in the real-world. One way to ensure that technology is considered is to simply show the technology choices by including them on software architecture diagrams. The statements ‘it is an implementation detail’ or ‘we don’t want to force a solution on devs’ are pretty common when talking to someone who has omitted the technology details in the diagrams. However, looking retrospectively, for the documentation after the software has been built, there is no reason for omitting technology decisions.
Another chapter topic is documentation. Unfortunately the code doesn’t tell the whole story and not having a source of supplementary information about a complex software system can slow a team down as they struggle to navigate the codebase. I totally agree with that based on my experience, and recently have even faced an example when the missing documentation can bring some troubles (guys just removed the endpoints because the documentation was missing and it looked like none were using it, but than one day comes. Here you can find the story and also other nice stuff in the blog, strongly recommend https://neilkakkar.com/things-I-learn...).
And the last chapter mostly focused on the risk management epic and gives nice advices how to prevent your system from failing (maybe even at Christmas night 2 AM heh).
However, from my current dev position it is more than 4 stars for sure.
Now, I want to briefly describe why I actually like this book.
First of all, what I find really interesting is the fact how the author thinks about software development in general. For him (and I totally agree with that position) it is more about people than technology. Just by looking at any chapter in this book you can see examples of questions that people tend to ask when taking some of the approaches author are protecting. I find it quite rare nowadays to see the dialog in a book or article rather than just a writer monolog. Tomb up for that.
Therefore, if we assert that a team is actually the most important part to reach our goal (deliver any product), we should concentrate on different aspects that can help the team to be more efficient. And that's exactly what this book is about.
First few chapters are about the relationship between team and architect and how to make it easy going.
After that goes the actual meaning of the architecture and the reasoning behind doing that (in our today's agile environments). Here I really liked the part about non-functional requirements.
Examples of quality attributes that not only architects but all the team should always think about and consider while developing/maintaining the product:
- Security
- Performance
- Availability
- Scalability
- Disaster recovery
- Monitoring
- Management (not the same as managers work) it is an ability to modify the runtime topology of a system, modify configuration elements, etc
- Audit is to keep a log of events (audit log) that led to a change in data or behaviour of a software system. Typically such logs needs to capture information related to who made the change, when and why the change was made.
- Flexibility is doing more than one task or doing the task in different ways.
- Extensibility
- Globalization
- Maintainability
All of this topics and many others should be taken into account, and the great statement here is that anything is possible, but everything has a trade-off.
Next chapters are mostly about the better ways how we can visualize our system. Here the C4 diagrams comes into place. Here what I really like is the writer notes that each diagram should mostly focus on one level of abstraction. Simple but pretty important thing which we tend to forget from time to time. Also an interesting argument from the author is that by forcing people to include technology choices on their software architecture diagrams also tends to lead to much richer and deeper conversations that are grounded in the real-world. One way to ensure that technology is considered is to simply show the technology choices by including them on software architecture diagrams. The statements ‘it is an implementation detail’ or ‘we don’t want to force a solution on devs’ are pretty common when talking to someone who has omitted the technology details in the diagrams. However, looking retrospectively, for the documentation after the software has been built, there is no reason for omitting technology decisions.
Another chapter topic is documentation. Unfortunately the code doesn’t tell the whole story and not having a source of supplementary information about a complex software system can slow a team down as they struggle to navigate the codebase. I totally agree with that based on my experience, and recently have even faced an example when the missing documentation can bring some troubles (guys just removed the endpoints because the documentation was missing and it looked like none were using it, but than one day comes. Here you can find the story and also other nice stuff in the blog, strongly recommend https://neilkakkar.com/things-I-learn...).
And the last chapter mostly focused on the risk management epic and gives nice advices how to prevent your system from failing (maybe even at Christmas night 2 AM heh).
September 11, 2022
I chose this book because I am transitioning in my career from a senior software engineer to a principle architect, and found it recommended for anyone who is stepping into an architecture role. This book is specifically aimed at software developers to help them understand the architecture role and the associated process.
Simon lays out the importance of software architecture, what it is about and how it is different than design. Every system has what are known as architectural drivers, comprised of functional requirements, quality attributes, constraints, and principles. Architecture is the process of creating a technical roadmap from those drivers and transforming it into a vision.
The author also goes into depth on skills that they recommend for the architecture role and why coding, coaching, and collaboration are important in this role. It's important that as you move into an architect role, that you keep your development skills fresh enough to know what will actually work, while also taking on responsibility for the architectural vision, and the asssociated code quality. There are soft people skills also required, because this is a leadership role.
The author makes a strong case for Just Enough Architecture, and lays out some criteria to determine when you have done enough, or you still have work to do.
While daunting, I look forward to applying some of these concepts in my new role.
Simon lays out the importance of software architecture, what it is about and how it is different than design. Every system has what are known as architectural drivers, comprised of functional requirements, quality attributes, constraints, and principles. Architecture is the process of creating a technical roadmap from those drivers and transforming it into a vision.
The author also goes into depth on skills that they recommend for the architecture role and why coding, coaching, and collaboration are important in this role. It's important that as you move into an architect role, that you keep your development skills fresh enough to know what will actually work, while also taking on responsibility for the architectural vision, and the asssociated code quality. There are soft people skills also required, because this is a leadership role.
The author makes a strong case for Just Enough Architecture, and lays out some criteria to determine when you have done enough, or you still have work to do.
While daunting, I look forward to applying some of these concepts in my new role.
November 24, 2020
I hate leaving a review without reading Simon’s second book, but here goes. This book perfectly describes my career arc in how I organically ended up in this software architecture role. I have gone through classes at Carnegie Mellon (which were subtly hostile to agile) and I did the scrum thing (certified SM.) I have since learned to loathe both, and I am more and more attracted to pure agile in general. However, my recent experience in software development without any up-front planning has shown me there has to be some middle ground somewhere. In searching for some wisdom, I found C4 and Simon’s videos. I think everything in this book is spot on. Why only 4 stars? I felt there was too much repetition, too many typos, and various broken links. The last section was way better than the first two, so I am wondering if this couldn’t have been condensed and combined with what I think book two will cover (C4.) I feel that Simon was trying to avoid making this specific book a marketing piece, but my whole attraction to his products is C4. This book feels like too much backstory to the meat of a novel. This could serve as a few chapters of a much larger book. Anyway, I learned a lot and I am eager to dive into book two. Simon has convinced me that C4 has merit. I can’t wait to learn more.
April 14, 2024
This book is a good place to form a concept of 'software architecture' and outline it's sub-fields.
I liked that the author had prompted me to give a definition of a software architecture, and then provided his own understanding – both experiences combined, I now understand what a 'software architecture' is.
I didn't like that author introduces 'architectural drivers' – that is, a set of fields, which define the whole scope of architecture – without deducting the need for each field separately, and why the list of the 'drivers' is necessarily final.
Also, I didn't like that the author makes a huge emphasis on 'career growth' and 'promotion' of a reader as the main goal for understanding architecture, as opposed to a natural need in understanding the field. This results in many advices to consider 'vendor partnership' and 'collaboration of developers' as keys for a good architecture.
All in all, this book helped me group my existing knowledge of engineering under the concept of "software architecture".
I liked that the author had prompted me to give a definition of a software architecture, and then provided his own understanding – both experiences combined, I now understand what a 'software architecture' is.
I didn't like that author introduces 'architectural drivers' – that is, a set of fields, which define the whole scope of architecture – without deducting the need for each field separately, and why the list of the 'drivers' is necessarily final.
Also, I didn't like that the author makes a huge emphasis on 'career growth' and 'promotion' of a reader as the main goal for understanding architecture, as opposed to a natural need in understanding the field. This results in many advices to consider 'vendor partnership' and 'collaboration of developers' as keys for a good architecture.
All in all, this book helped me group my existing knowledge of engineering under the concept of "software architecture".
November 21, 2020
There's some good material here, but this book would benefit from a professional editor -- it has sloppy typos, it repeats itself quite a bit. Also, this book is mainly focused on the role of software architects, as opposed to being about software architecture. This isn't necessarily bad but it's not obvious from the title.
June 17, 2016
I liked the book and it is usefull but overall I thought that it would be better. A lot of complaints, most of them are accurate but still. Simon tries to explain why software architecture is important, and how software book which describes a project and its evolution should be prepared in structural way. He describes also his C4 model.
some quotes:
But, generally speaking, a software architect who codes is a more effective and happier architect. You shouldn’t necessarily rule out coding just because “you’re an architect”.
After telling me that he had little or no involvement in the project after he handed over the “solution”, I asked him how he knew that his software architecture would work. Puzzled by this question, he eventually made the statement that this was “an implementation detail”. He confidently viewed his software architecture as correct and it was the development team’s problem if they couldn’t get it to work. In my view, this was an outrageous thing to say and it made him look like an ass during the interview. His approach was also AaaS … “Architecture as a Service”!
Despite people’s aspirations to be agile, collective code ownership and a distribution of the architecture role are likely to hinder chaotic teams rather than help them.
Software architecture is about the significant design decisions, where significance is measured by cost of change. A high-level understanding of the requirements, constraints and principles is a starting point for those significant decisions that will ultimately shape the resulting software architecture. Understanding them early will help to avoid costly rework in the future.
If you don’t understand the trade-offs that you’re making by choosing technology X over Y, you shouldn’t be making those decisions. It’s crucial that the people designing software systems understand technology. This is why software architects should be master builders.
Having run architecture katas with thousands of people over a number of years, I can say with complete confidence that visualising the architecture of a software system is a skill that very few people have. People can draw diagrams, but those diagrams often leave much to the imagination.
Abandoning UML is all very well but, in the race for agility, many software development teams have lost the ability to communicate visually.
Agility requires good communication Why is this important? In today’s world of agile delivery and lean startups, many software teams have lost the ability to communicate what it is they are building and it’s no surprise that these same teams often seem to lack technical leadership, direction and consistency.
A better approach is to create a number of diagrams at varying levels of abstraction. A number of simpler diagrams can describe software in a much more effective way than a single complex diagram that tries to describe everything.
How the software system fits into the existing system landscape. Why the technologies in use were chosen. The overall structure of the software system. Where the various components are deployed at runtime and how they communicate. How the web-tier “knows” where to find the middle-tier. What approach to logging/configuration/error handling/etc has been adopted and whether it is consistent across the codebase. Whether any common patterns and principles are in use across the codebase. How and where to add new functionality. How security has been implemented across the stack. How scalability is achieved. How the interfaces with other systems work. etc
“Working software over comprehensive documentation” is what the Manifesto for Agile Software Development says and it’s incredible to see how many software teams have interpreted those five words as “don’t write any documentation”.
The agile manifesto values “responding to change” over “following a plan”, but of course this doesn’t mean you shouldn’t do any planning and it seems that some agile teams are afraid of doing any “analysis” at all. The result is that in trying to avoid big up front design, agile teams often do not design up front and instead use terms like “emergent design” or “evolutionary architecture” to justify their approach.
These conflicts, in many cases, lead to chaotic teams that lack an appropriate amount of technical leadership. The result? Software systems that look like big balls of mud and/or don’t satisfy key architectural drivers such as non-functional requirements.
Architecture is about the stuff that’s hard or costly to change. It’s about the big or “significant” decisions, the sort of decisions that you can’t easily refactor in an afternoon. This includes, for example, the core technology choices, the overall high-level structure (the big picture) and an understanding of how you’re going to solve any complex/risky/significant problems. Software architecture is important.
Agile and architecture aren’t in conflict. Rather than blindly following what others say, software teams need to cut through the hype and understand the technical leadership style and quantity of up front design that they need given their own unique context.
Based upon my definition of architecture, you could say that you need to do just enough up front design to give you structure and vision.
some quotes:
But, generally speaking, a software architect who codes is a more effective and happier architect. You shouldn’t necessarily rule out coding just because “you’re an architect”.
After telling me that he had little or no involvement in the project after he handed over the “solution”, I asked him how he knew that his software architecture would work. Puzzled by this question, he eventually made the statement that this was “an implementation detail”. He confidently viewed his software architecture as correct and it was the development team’s problem if they couldn’t get it to work. In my view, this was an outrageous thing to say and it made him look like an ass during the interview. His approach was also AaaS … “Architecture as a Service”!
Despite people’s aspirations to be agile, collective code ownership and a distribution of the architecture role are likely to hinder chaotic teams rather than help them.
Software architecture is about the significant design decisions, where significance is measured by cost of change. A high-level understanding of the requirements, constraints and principles is a starting point for those significant decisions that will ultimately shape the resulting software architecture. Understanding them early will help to avoid costly rework in the future.
If you don’t understand the trade-offs that you’re making by choosing technology X over Y, you shouldn’t be making those decisions. It’s crucial that the people designing software systems understand technology. This is why software architects should be master builders.
Having run architecture katas with thousands of people over a number of years, I can say with complete confidence that visualising the architecture of a software system is a skill that very few people have. People can draw diagrams, but those diagrams often leave much to the imagination.
Abandoning UML is all very well but, in the race for agility, many software development teams have lost the ability to communicate visually.
Agility requires good communication Why is this important? In today’s world of agile delivery and lean startups, many software teams have lost the ability to communicate what it is they are building and it’s no surprise that these same teams often seem to lack technical leadership, direction and consistency.
A better approach is to create a number of diagrams at varying levels of abstraction. A number of simpler diagrams can describe software in a much more effective way than a single complex diagram that tries to describe everything.
How the software system fits into the existing system landscape. Why the technologies in use were chosen. The overall structure of the software system. Where the various components are deployed at runtime and how they communicate. How the web-tier “knows” where to find the middle-tier. What approach to logging/configuration/error handling/etc has been adopted and whether it is consistent across the codebase. Whether any common patterns and principles are in use across the codebase. How and where to add new functionality. How security has been implemented across the stack. How scalability is achieved. How the interfaces with other systems work. etc
“Working software over comprehensive documentation” is what the Manifesto for Agile Software Development says and it’s incredible to see how many software teams have interpreted those five words as “don’t write any documentation”.
The agile manifesto values “responding to change” over “following a plan”, but of course this doesn’t mean you shouldn’t do any planning and it seems that some agile teams are afraid of doing any “analysis” at all. The result is that in trying to avoid big up front design, agile teams often do not design up front and instead use terms like “emergent design” or “evolutionary architecture” to justify their approach.
These conflicts, in many cases, lead to chaotic teams that lack an appropriate amount of technical leadership. The result? Software systems that look like big balls of mud and/or don’t satisfy key architectural drivers such as non-functional requirements.
Architecture is about the stuff that’s hard or costly to change. It’s about the big or “significant” decisions, the sort of decisions that you can’t easily refactor in an afternoon. This includes, for example, the core technology choices, the overall high-level structure (the big picture) and an understanding of how you’re going to solve any complex/risky/significant problems. Software architecture is important.
Agile and architecture aren’t in conflict. Rather than blindly following what others say, software teams need to cut through the hype and understand the technical leadership style and quantity of up front design that they need given their own unique context.
Based upon my definition of architecture, you could say that you need to do just enough up front design to give you structure and vision.
August 28, 2021
أنهيت البارحة قراءة هذا الكتاب، و يمكنني قول التالي..
لا شك بأني تعلمت أكثر عن ماهية هذه الوظيفة Software Architect.. عن تعريفها و مكانها في كل ال software development life cycle عن أهم نقاط يجب أن أفكر بها قبل أي مشروع عن دوره مع الفريق كله، أعجبني ذكر بعض المواقف الحقيقية ليكون أكثر من مجرد نظريات
نحو الجزء الثاني ⬅️
لا شك بأني تعلمت أكثر عن ماهية هذه الوظيفة Software Architect.. عن تعريفها و مكانها في كل ال software development life cycle عن أهم نقاط يجب أن أفكر بها قبل أي مشروع عن دوره مع الفريق كله، أعجبني ذكر بعض المواقف الحقيقية ليكون أكثر من مجرد نظريات
نحو الجزء الثاني ⬅️
February 18, 2018
A pragmatic approach to software architecture
November 9, 2023
c4 and arch docs checklist are nice, but too little for 230 pages
February 1, 2023
Lot's of text, but I didn't get much out of this book. And it wasn't pleasant read.
The title is misleading. It probably be "Agile software architecture for ivory tower architects"
One part of medieval masonry was quite interesting, but it doesn't fit in with the rest of the book.
The title is misleading. It probably be "Agile software architecture for ivory tower architects"
One part of medieval masonry was quite interesting, but it doesn't fit in with the rest of the book.
March 10, 2021
The following review is for both Volume 2 of this book, since I think booth need to be read.
Simply said, if you want to know what it means to be a software architect, this is the ideal book.
It starts by explaining, very thoroughly, what is the meaning of software architecture, following the roles involved and the requirements for them, what a person needs to have or be like. After that moves to an explanation of how to design and visualize software (loved the C4 Model and already started applying at work). Also provides a great explanation on project documentation and finally finishing the book with some ideas on how to introduce software architecture in a company/team.
Really enjoyed the book and pratically only good feedback about it comes to my mind.
Bad points, probably one...wanted more :)
Simply said, if you want to know what it means to be a software architect, this is the ideal book.
It starts by explaining, very thoroughly, what is the meaning of software architecture, following the roles involved and the requirements for them, what a person needs to have or be like. After that moves to an explanation of how to design and visualize software (loved the C4 Model and already started applying at work). Also provides a great explanation on project documentation and finally finishing the book with some ideas on how to introduce software architecture in a company/team.
Really enjoyed the book and pratically only good feedback about it comes to my mind.
Bad points, probably one...wanted more :)
October 31, 2016
I read this book after it was highly recommended by a senior architect at my company. After reading it, I have some mixed feelings about it!
The best part of the book by far is the C4 section. As a developer, I have always struggled with visualizing the architectures systems that I work on, which I tried to do when introducing the system to new members, for instance. The "aha" moment came when realizing that trying to put all the information in one diagram does not make sense! The 4 diagrams that the author introduces felt very natural, and I was able to use them later when visualizing an entire system, or only the designs of new components/modules.
As for the other chapters that define architecture and the role of an architect: I found them to be valuable as well. However, it is very obvious when you read them that they are based on a series of articles. The chapters are also full of repetitions. Some ideas - even some paragraphs - have been repeated more than 2-3 times! These ideas are indeed important, but the repetition does not add any value.
One final note if you have not read the book yet: this book is not about architectural patterns. You will not find here ideas or patterns in software architecture, but rather a higher level discussion of the role of an architect and what software architecture is all about.
Overall, I would still recommend at least skimming this book for any person working in software development and to focus on the C4 chapters
The best part of the book by far is the C4 section. As a developer, I have always struggled with visualizing the architectures systems that I work on, which I tried to do when introducing the system to new members, for instance. The "aha" moment came when realizing that trying to put all the information in one diagram does not make sense! The 4 diagrams that the author introduces felt very natural, and I was able to use them later when visualizing an entire system, or only the designs of new components/modules.
As for the other chapters that define architecture and the role of an architect: I found them to be valuable as well. However, it is very obvious when you read them that they are based on a series of articles. The chapters are also full of repetitions. Some ideas - even some paragraphs - have been repeated more than 2-3 times! These ideas are indeed important, but the repetition does not add any value.
One final note if you have not read the book yet: this book is not about architectural patterns. You will not find here ideas or patterns in software architecture, but rather a higher level discussion of the role of an architect and what software architecture is all about.
Overall, I would still recommend at least skimming this book for any person working in software development and to focus on the C4 chapters
Displaying 1 - 30 of 40 reviews