What do you think?
Rate this book
Design It!: From Programmer to Software Architect
Don't engineer by coincidence-design it like you mean it! Filled with practical techniques, Design It! is the perfect introduction to software architecture for programmers who are ready to grow their design skills. Lead your team as a software architect, ask the right stakeholders the right questions, explore design options, and help your team implement a system that promotes the right -ilities. Share your design decisions, facilitate collaborative design workshops that are fast, effective, and fun-and develop more awesome software!
With dozens of design methods, examples, and practical know-how, Design It! shows you how to become a software architect. Walk through the core concepts every architect must know, discover how to apply them, and learn a variety of skills that will make you a better programmer, leader, and designer.
Uncover the big ideas behind software architecture and gain confidence working on projects big and small. Plan, design, implement, and evaluate software architectures and collaborate with your team, stakeholders, and other architects. Identify the right stakeholders and understand their needs, dig for architecturally significant requirements, write amazing quality attribute scenarios, and make confident decisions. Choose technologies based on their architectural impact, facilitate architecture-centric design workshops, and evaluate architectures using lightweight, effective methods. Write lean architecture descriptions people love to read. Run an architecture design studio, implement the architecture you've designed, and grow your team's architectural knowledge. Good design requires good communication. Talk about your software architecture with stakeholders using whiteboards, documents, and code, and apply architecture-focused design methods in your day-to-day practice.
Hands-on exercises, real-world scenarios, and practical team-based decision-making tools will get everyone on board and give you the experience you need to become a confident software architect.
With dozens of design methods, examples, and practical know-how, Design It! shows you how to become a software architect. Walk through the core concepts every architect must know, discover how to apply them, and learn a variety of skills that will make you a better programmer, leader, and designer.
Uncover the big ideas behind software architecture and gain confidence working on projects big and small. Plan, design, implement, and evaluate software architectures and collaborate with your team, stakeholders, and other architects. Identify the right stakeholders and understand their needs, dig for architecturally significant requirements, write amazing quality attribute scenarios, and make confident decisions. Choose technologies based on their architectural impact, facilitate architecture-centric design workshops, and evaluate architectures using lightweight, effective methods. Write lean architecture descriptions people love to read. Run an architecture design studio, implement the architecture you've designed, and grow your team's architectural knowledge. Good design requires good communication. Talk about your software architecture with stakeholders using whiteboards, documents, and code, and apply architecture-focused design methods in your day-to-day practice.
Hands-on exercises, real-world scenarios, and practical team-based decision-making tools will get everyone on board and give you the experience you need to become a confident software architect.
360 pages, Paperback
Published November 21, 2017
252 people are currently reading
1100 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 30 reviews
April 2, 2017
Disclaimer: I've read the beta version of this book, which was still missing 2 chapters.
Rather pleasant, little book on software architecture - that gets worse the further you read. It's completely platform-/technology-/paradigm- agnostic & it focuses on communication, collaboration & overall maintainability (of architecture, not the solution itself!). There's nothing wrong about such a focus, it's also well described & proper things are getting emphasized, but it quickly starts to feel "over-generic" - e.g. I was happy to find a chapter on Design Thinking, but after reading it I think it's just a wasted opportunity.
Speaking for myself only, the worst part is the one that should be probably the most interesting one: "The Architecture Toolbox" - 80% of content here is trivial, but maybe it's just me being too old'n'grumpy :)
To summarize: it's not a bad book - well-written, concise, remarks don't bring any controversy (but hmmm, is it necessarily a good thing?), but ... I've expected far more. 2.5-3 stars at most.
Rather pleasant, little book on software architecture - that gets worse the further you read. It's completely platform-/technology-/paradigm- agnostic & it focuses on communication, collaboration & overall maintainability (of architecture, not the solution itself!). There's nothing wrong about such a focus, it's also well described & proper things are getting emphasized, but it quickly starts to feel "over-generic" - e.g. I was happy to find a chapter on Design Thinking, but after reading it I think it's just a wasted opportunity.
Speaking for myself only, the worst part is the one that should be probably the most interesting one: "The Architecture Toolbox" - 80% of content here is trivial, but maybe it's just me being too old'n'grumpy :)
To summarize: it's not a bad book - well-written, concise, remarks don't bring any controversy (but hmmm, is it necessarily a good thing?), but ... I've expected far more. 2.5-3 stars at most.
August 16, 2019
* Book structure:
The book is divided into 3 parts:
1. Introductions: what is software architecture, what architects do, the design thinking methodology that will be followed through the book, and the importance of mitigating risks.
2. Using the design thinking methodology to make repeated iteration of [think-do-check] to cover the contributions of architectures/architects during the 4 phases of the design thinking:
a. Understand the problem - from engineering perspective. The discussion of how much up-front design was interesting
b. Explore the solutions. The coverage of architecture patterns was nice.
c. Making the architecture tangible. The discussion of documenting the architecture was really helpful.
d. Evaluating the architecture early, frequently, and always. This was eye opener.
3. Activities that could be used during every phase of the design thinking.
----
Generally speaking, I learned some good stuff from this book, but I felt that it is missing something, I am not sure what this missed thing is!
Maybe I need to re-read the book again, which I planned to do, but after reading some other architecture books.
The book is divided into 3 parts:
1. Introductions: what is software architecture, what architects do, the design thinking methodology that will be followed through the book, and the importance of mitigating risks.
2. Using the design thinking methodology to make repeated iteration of [think-do-check] to cover the contributions of architectures/architects during the 4 phases of the design thinking:
a. Understand the problem - from engineering perspective. The discussion of how much up-front design was interesting
b. Explore the solutions. The coverage of architecture patterns was nice.
c. Making the architecture tangible. The discussion of documenting the architecture was really helpful.
d. Evaluating the architecture early, frequently, and always. This was eye opener.
3. Activities that could be used during every phase of the design thinking.
----
Generally speaking, I learned some good stuff from this book, but I felt that it is missing something, I am not sure what this missed thing is!
Maybe I need to re-read the book again, which I planned to do, but after reading some other architecture books.
May 30, 2023
Two stars - "It was ok".
What I liked:
- Some terms and heuristics were new to me. For example, I like the idea of design mindsets. Iterativity and explicitness in the goal you're trying to achieve with a particular activity sounds like a good start (understand-explore-make-evaluate).
- Naming convention for structures existing either at design time or at runtime (modules vs components). Unfortunately, those are often used interchangeably which causes confusion.
- Helpful heuristics for gathering architectural requirements.
- The last section about workshops you can conduct as an architect. I appreciate putting all of those in one place - it can be a neat reference for me in the future!
What I didn't like:
- The biggest problem with this book is that it's not really about designing software. You won't learn how to design architecture for complex systems or how to create models for important business domains. Instead, we get a rich description of architect's role and many heuristics around the process of creating software architecture
- Shallowness (kind of continuation of the previous point...). The demo project that is being created through reading the book is extremely simple. It has actually almost zero value for readers. My paraphrase: "Okay, we have a project, we need to gather requirements. Well, should it be n-layer architecture or soa? (... tension, anxiously waiting for the final decision) Let's go with n-layer, will be simpler. Yaaaay, success!" There are no guidelines on HOW to actually desigh system. HOW to actually divide your system into modules / layers / services / whatever. HOW to make a difficult decision on which database technology. All of those deep topics are omitted.
Okay, after all, is it a bad book? No, it's not. I think it has a lot of valuable content inside but you have to adjust your expectations - it's not about HOW to design but WHAT software architect does and WHAT are the tools that he or she can use to come up with the better architecture in the end.
What I liked:
- Some terms and heuristics were new to me. For example, I like the idea of design mindsets. Iterativity and explicitness in the goal you're trying to achieve with a particular activity sounds like a good start (understand-explore-make-evaluate).
- Naming convention for structures existing either at design time or at runtime (modules vs components). Unfortunately, those are often used interchangeably which causes confusion.
- Helpful heuristics for gathering architectural requirements.
- The last section about workshops you can conduct as an architect. I appreciate putting all of those in one place - it can be a neat reference for me in the future!
What I didn't like:
- The biggest problem with this book is that it's not really about designing software. You won't learn how to design architecture for complex systems or how to create models for important business domains. Instead, we get a rich description of architect's role and many heuristics around the process of creating software architecture
- Shallowness (kind of continuation of the previous point...). The demo project that is being created through reading the book is extremely simple. It has actually almost zero value for readers. My paraphrase: "Okay, we have a project, we need to gather requirements. Well, should it be n-layer architecture or soa? (... tension, anxiously waiting for the final decision) Let's go with n-layer, will be simpler. Yaaaay, success!" There are no guidelines on HOW to actually desigh system. HOW to actually divide your system into modules / layers / services / whatever. HOW to make a difficult decision on which database technology. All of those deep topics are omitted.
Okay, after all, is it a bad book? No, it's not. I think it has a lot of valuable content inside but you have to adjust your expectations - it's not about HOW to design but WHAT software architect does and WHAT are the tools that he or she can use to come up with the better architecture in the end.
November 2, 2020
Good to provide basic principles for software architecture.
There are many practical interesting tutorials on how to organize architecture workshops, which I applied in reality. Some of them are still for the "ideal" situation. Hopefully, I can experience them in the future.
There are many practical interesting tutorials on how to organize architecture workshops, which I applied in reality. Some of them are still for the "ideal" situation. Hopefully, I can experience them in the future.
December 26, 2018
Once I got past the disappointment (possibly due to my own misunderstanding) of the mismatch between the title and the contents, I was able to appreciate the wisdom and practicality of this book.
Based on the title, I was expecting to learn about different software architectures, or at least an approach to learning and appreciating the fundamentals of software architecture, all based on my existing knowledge of programming. I was hoping to learn of the benefits and pitfalls of certain architectures, to be particular, or perhaps more general techniques, like ways to decide how to best partition responsibilities across a set of components. And I really wanted the contents of this book to match my take on the title, because I am keenly interested in software architecture and I want to attain that deeper understanding of my chosen craft.
So, while there were a few tantalizing mentions of certain architectures that I have some experience with (like Publish/Subscribe, or Multi-Tier) and even some that I don't but would like to explore (such as Ports and Adapters), these references were mostly incidental to the primary objectives of the text. Instead of the nuts and bolts of software architecture that I was expecting, the book instead takes on the deeper questions of what it means to be an architect, and why the role matters. It even answers, in some detail, how the architect (or group of architects) might interact with stakeholders and the rest of the software development team.
This last point, regarding the many ways that an architect can collaborate with others, was illustrated with dozens of different group exercises, and some of them even sound like fun. Once I got past my hunger for technical details, it gradually dawned on me that this was the more practical view of software architecture -- instead of the lone genius who descends from a tower to deliver pure visions of abstract beauty and symmetry, the real architect is the one who finds a possibly messy balance between all the competing requirements and finds a solution that fits the context of the problem (which quite necessarily involves other people).
Disabused of this notion of the architect as sorcerer, I am able to see the outlines of a more practical vision of what it might be like for me to grow into this role. And while I still need to fill in some of those details that I hungered for, I am grateful to the author for providing me with the framework that will hold them in alignment with the reality of software development.
Based on the title, I was expecting to learn about different software architectures, or at least an approach to learning and appreciating the fundamentals of software architecture, all based on my existing knowledge of programming. I was hoping to learn of the benefits and pitfalls of certain architectures, to be particular, or perhaps more general techniques, like ways to decide how to best partition responsibilities across a set of components. And I really wanted the contents of this book to match my take on the title, because I am keenly interested in software architecture and I want to attain that deeper understanding of my chosen craft.
So, while there were a few tantalizing mentions of certain architectures that I have some experience with (like Publish/Subscribe, or Multi-Tier) and even some that I don't but would like to explore (such as Ports and Adapters), these references were mostly incidental to the primary objectives of the text. Instead of the nuts and bolts of software architecture that I was expecting, the book instead takes on the deeper questions of what it means to be an architect, and why the role matters. It even answers, in some detail, how the architect (or group of architects) might interact with stakeholders and the rest of the software development team.
This last point, regarding the many ways that an architect can collaborate with others, was illustrated with dozens of different group exercises, and some of them even sound like fun. Once I got past my hunger for technical details, it gradually dawned on me that this was the more practical view of software architecture -- instead of the lone genius who descends from a tower to deliver pure visions of abstract beauty and symmetry, the real architect is the one who finds a possibly messy balance between all the competing requirements and finds a solution that fits the context of the problem (which quite necessarily involves other people).
Disabused of this notion of the architect as sorcerer, I am able to see the outlines of a more practical vision of what it might be like for me to grow into this role. And while I still need to fill in some of those details that I hungered for, I am grateful to the author for providing me with the framework that will hold them in alignment with the reality of software development.
April 24, 2018
+very fast read
+clear and good structure
+practical pointers
-i'd like to have had a deeper book, it remains a bit shallow
+clear and good structure
+practical pointers
-i'd like to have had a deeper book, it remains a bit shallow
June 16, 2021
The book gives a good introduction in the work of a software architect and supports with processes and models like design thinking that will help you to decide what kind of work to do.
It gives a lot of insights in what kind of artifacts are useful and different activities that you can do to produce them. A part of the book is a catalog of all those activities that you can use to understand, explore, make and evaluate.
There's a wealth of different techniques and tools described that you can adopt. For me I think the biggest takeaway is to be deliberate about current goals at a specific point in time. But I imagine I will also come back to adopt some of the activities from time to time.
It gives a lot of insights in what kind of artifacts are useful and different activities that you can do to produce them. A part of the book is a catalog of all those activities that you can use to understand, explore, make and evaluate.
There's a wealth of different techniques and tools described that you can adopt. For me I think the biggest takeaway is to be deliberate about current goals at a specific point in time. But I imagine I will also come back to adopt some of the activities from time to time.
May 1, 2020
This book is divided in three parts:
1. Introducing Software Architecture
This content establishes the ground floor for software architecture, design thinking, design mindset -- understand, explore, make and evaluate -- and how to use this approach. In this part, even if you know about design thinking, every word matters and you feel like you are learning a lot in every page. It's really worthy.
2. Architecture Design Fundamentals
This is best part of the book, the author talks about managing risks, things you can do to learn and be the architect of your team, grow your team architecture skills, find trade-offs of quality attributes, identify architecturally significant requirements and constraints, make the architecture tangible or abstract it using models to be able to discuss complex problems. I found this part to be really good, sometimes a little too specific when talking about meetings and workshops, but overall really good.
3. The Architect's Toolbox
This part I didn't like very much, I found it to be too specific and I don't see most of the events/tools listed there to be useful for me, maybe in some level. It's possible that I will go back to this book in the future when working in a different company size (mine is 51-200), but I ended up jumping around trying to find something interesting. If this part was not in the book or if it talked more about the fundamentals of these tools instead of specifics, I'd probably make my rating a bit higher.
1. Introducing Software Architecture
This content establishes the ground floor for software architecture, design thinking, design mindset -- understand, explore, make and evaluate -- and how to use this approach. In this part, even if you know about design thinking, every word matters and you feel like you are learning a lot in every page. It's really worthy.
2. Architecture Design Fundamentals
This is best part of the book, the author talks about managing risks, things you can do to learn and be the architect of your team, grow your team architecture skills, find trade-offs of quality attributes, identify architecturally significant requirements and constraints, make the architecture tangible or abstract it using models to be able to discuss complex problems. I found this part to be really good, sometimes a little too specific when talking about meetings and workshops, but overall really good.
3. The Architect's Toolbox
This part I didn't like very much, I found it to be too specific and I don't see most of the events/tools listed there to be useful for me, maybe in some level. It's possible that I will go back to this book in the future when working in a different company size (mine is 51-200), but I ended up jumping around trying to find something interesting. If this part was not in the book or if it talked more about the fundamentals of these tools instead of specifics, I'd probably make my rating a bit higher.
September 4, 2019
A great resource for architects, team leads and anyone who has to align (opinionated, oh my) people around technology.
I had a chance to run several exercises from the book with several teams and they proved immensely useful - we managed to highlight trade-offs, surface risks that were previously assumed, and ship better products.
I'll definitely keep the second part of the book in my toolbox 🤭
I had a chance to run several exercises from the book with several teams and they proved immensely useful - we managed to highlight trade-offs, surface risks that were previously assumed, and ship better products.
I'll definitely keep the second part of the book in my toolbox 🤭
September 25, 2019
A big disappointment. The title and the book do only partially match. There are many good points about software architecture, but it lacks the guide to go from programmer to architect. While the book offers an unusual amount of generic ideas (especially for a book published by the Pragmatic Bookshelf), it lacks all the parts that are important to software architecture: How do you decide which option to follow? How do you make fundamental decisions? How do you document them? How do you share the rules and restrictions you choose? Without answers to those questions, the book is nothing more as a nice list of things you can do.
December 27, 2021
A must read for aspiring software architects
This book is one of most important, inspiring and influential books I’ve ever read. It not only explains what architecture is and how it should be done, it also gives a clear instructions for aspiring software developers on how to become a software architect. It also contains a broad catalog of well-described, ready to use workshop methods. The book itself is easy to read, well redacted and structured. For me personally, this is THE software architecture book and if I’ve been asked to go for a lone island with only one tech book, I’d choose this one without a doubt :)
This book is one of most important, inspiring and influential books I’ve ever read. It not only explains what architecture is and how it should be done, it also gives a clear instructions for aspiring software developers on how to become a software architect. It also contains a broad catalog of well-described, ready to use workshop methods. The book itself is easy to read, well redacted and structured. For me personally, this is THE software architecture book and if I’ve been asked to go for a lone island with only one tech book, I’d choose this one without a doubt :)
August 24, 2022
I really liked that this book basically recaps all the basics and the last chapters explain some of the well-known formats like event storming and ADR and other ones that sound interesting.
I think the targeted audience on its way to software architect is well addressed and the examples cover most of the things and the proved ways to handle the unknown.
I think the targeted audience on its way to software architect is well addressed and the examples cover most of the things and the proved ways to handle the unknown.
October 23, 2022
I am looking for good books promoting structured architectural thinking in engineering teams. "Design It" is highly recommendable and easy to read guide. Apart from "what is software architecture" and how to approach it, author touches on some soft topics which is a helpful thing for engineers making the step into technical leadership.
November 7, 2018
Perfect book for technical leader aspirants
Explore more techniques to handle architecture design effectively. Learn the best ways and good qualities to become a software architect.
Explore more techniques to handle architecture design effectively. Learn the best ways and good qualities to become a software architect.
December 4, 2018
Lots and lots of very generic words and diagrams. What this book lacks is good examples. I assume the author tried to be technology agnostic, but architects work with technologies, and at least supporting ideas with examples was a must for this book.
July 2, 2021
From my perspective it should be two separate books. The first part(design intro) is somewhat disconnected from the second part(playbook).
There are other books going in more detail. Though if it is your first book on this topic - it will give you a good overview of the basics.
There are other books going in more detail. Though if it is your first book on this topic - it will give you a good overview of the basics.
July 31, 2024
Decent high level overview of software architecture. There are many questions generated and exercises offered to assist. The example project referenced throughout was a little lacking in my opinion.
August 7, 2017
By far, this is the worst book that I've read from PragProg. While reading the book, I had the feeling that it's a text book (full of lists and names) and I am getting prepared for an exam.
December 20, 2018
Wonderful book about building large scale software projects. The bit about "ball-of-mud" architecture particularly hit home.
December 20, 2018
In general: text book. Modern approach to designing software architecture. Contains many useful methods described in toolbox part.
October 27, 2019
Too generic, too abstract... It leaves you with the feeling that you would not remember anything after reading it. The more you read, the more boring it gets. I honestly struggled to finish it.
February 13, 2020
know more about "soft skills" about how to grow a architect like customer-centre, pick an appropriate pattern as meta-model, and how to grow the architect
September 2, 2020
Good as handbook full of different technics for each phase of software architecture process
May 22, 2021
Good toolbox for a software architect.
October 2, 2021
I can better understand how our team approaches this work after reading through this, it has a lot of parallels to product and design thinking methodologies.
March 27, 2023
I had to complete it just because I purchased it. I think there might be better alternatives books.
September 7, 2024
Great ideas about architecture thinking
January 3, 2018
Great book for future technical leaders
This book is designed to help kickstart your architectural thinking and set you up with practical methods to start making analytical decisions about the design of your systems. From how to think about quality attributes, how to approach architecture as a risk reducing disciplines and the catalogue of architecture styles; this book is also a great summary of the most important concepts on software architecture and serves also as a good referential source.
I recommend this book to any engineer looking to make the jump to technical leader but it is also a great catalyst for practicing software architects looking to solidify some of their thinking and methods.
This book is designed to help kickstart your architectural thinking and set you up with practical methods to start making analytical decisions about the design of your systems. From how to think about quality attributes, how to approach architecture as a risk reducing disciplines and the catalogue of architecture styles; this book is also a great summary of the most important concepts on software architecture and serves also as a good referential source.
I recommend this book to any engineer looking to make the jump to technical leader but it is also a great catalyst for practicing software architects looking to solidify some of their thinking and methods.
March 31, 2019
Some books are about architecture and the role of the software architect. Large shelves are dedicated to agile literature. Few books merge the two subjects. This is one of them. By design this merge is stretched between 2 not so compatible position. To address it, the author split the architect's missions in 4:
- understand : how to gather information from stakeholders
- explore : build solutions from needs expressed
- make : build models, plans or prototypes
- evaluate : check how the realization fits the reality
The major drawback of this text is the level of abstraction, with few or no concrete examples. Therefore it miss the dynamism needed to make the reading enjoyable.
Ma note de lecture en Français ici
- understand : how to gather information from stakeholders
- explore : build solutions from needs expressed
- make : build models, plans or prototypes
- evaluate : check how the realization fits the reality
The major drawback of this text is the level of abstraction, with few or no concrete examples. Therefore it miss the dynamism needed to make the reading enjoyable.
Ma note de lecture en Français ici
May 21, 2019
Practical approach to architecture in an agile world
Practical approach to architecture in an agile world, this book conveys the changing face of software development from an architectural perspective.
Practical approach to architecture in an agile world, this book conveys the changing face of software development from an architectural perspective.
Displaying 1 - 30 of 30 reviews