List of all books with links: 1. Software Architecture Perspectives on Emerging Discipline by Marry Shaw and David Garlan www.amazon.com/Software-Architecture-Perspectives-Emerging-Discipline/dp/0131829572 2. Software Architecture in Practice www.amazon.com/Software-Architecture-Practice-3rd-Engineering/dp/0321815734 3. The Process of software Architecting www.amazon.com/Process-Software-Architecting-Peter-Eeles/dp/0321357485 4. Essential Software Architecture www.amazon.com/Essential-Software-Architecture-Ian-Gorton/dp/3642191754 5. Documenting Software Architecture www.amazon.com/Documenting-Software-Architectures-Views-Beyond/dp/0321552687 6. Software Architecture Foundation, Theory, and Practice www.amazon.com/Software-Architecture-Foundations-Theory-Practice/dp/0470167742 7. Just Enough Software Architecture www.amazon.com/Just-Enough-Software-Architecture-Risk-Driven/dp/0984618104 8. Software Architecture for Developers www.goodreads.com/book/show/15734781-software-architecture-for-developers 9. georgefairbanks.com/blog/ Hi George, thanks for all suggestions!
This was an intriguing watch, thank you very much. I ordered a couple of these books that were missing from my shelf while watching (I will have to put another one up now!) and interestingly your book on Just Enough Software Architecture is already on its way to me. I have many years of experience as a software developer and a handful as a software architect (ranging from technical to enterprise solutions) and I've read a LOT of books, so I am excited to read yours and I'll be sure to let you know what I think!
Nice compilation George!! I've them all :D I'm very busy now studying all those books you named and others. I it was up to me, I'll add to the bullet list -enterprise integration patterns, 574 pages (excellent in dept treatment of messaging in the context of integrating computer systems, important skill of any competent software architect in the enterprise field!) -evaluating software Architectures -pattern-oriented Software Architecture, - Volume 1,2,3 and 4. Thanks George!
So, as I understand it: - Read the first 5 chapters of your book - Read Essential Software Architecture - Read Simon Brown's book "Software Architecture for Developers" - Read all the other books when above is not enough
+Aschwin Wesselius Oh no, you heard me completely wrong: Buy lots of copies of my book and give them liberally as presents ;-) Each book I mentioned is a favorite and I'm trying to give you my mental map about what each one contributes to the canon. If I had a single correction to your list, it would be to add Documenting Software Architectures 2nd Edition to your shopping cart just to have ready when you need it. Advanced material but a goldmine.
+George Fairbanks Fair enough ; -) George, I have a hard time getting a good resource on writing functional specification documents or any templates to see what it should contain the very least. Do any of these books cover an introduction into technical/functional writing? Can you point me towards a good resource to get a solid start at this? I've never had a need to write these documents, so I am a bit at a loss on this one.
+Aschwin Wesselius Briefly, avoid the "shall statement" type of document; try "use cases" but don't go overboard. Use these 2 books: Alistair Cockburn's book on use cases is great, but doesn't cover architecture. The Documenting Software Architectures 2nd edition book as it covers the architecture parts and is skimpy on the use cases.
Dear George, I started working in the field two years ago. I was solo at the time and overwhelmed by a big client, but there is where my love for software design was born. Currently I am hitting the ceiling since I rely so much on my mental processes instead of writing it all down in models. Your clear way of expressing things made me realize that I should probably read the books you recommended instead of reinventing the wheel. Thank you, Luka Šilje
Thank you so much for a wonderful review @George Fairbanks, I am computer scientist working for 7 years now, This means so much to me and my colleagues in my company @Mastercard
My book covers this and I've quoted those sections below. You can treat them as synonyms most of the time. When the pattern becomes a constraint you are relying on to achieve a quality and it dominates the design, then it's probably better to say "architectural style". Just Enough Software Architecture 2010 says: Chapter 9: "Architectural styles can be looked at as simply architectural patterns, but their potential to be much more is evident when they are formalized as they are in the Acme language (Garlan, Monroe and Wile, 2000) and the Acme Studio tool (Garlan and Schmerl, 2009). The insight has probably occurred in other contexts, but David Garlan’s course on software architecture (Garlan, 2003) describes how constraints and styles are necessary tools of an architect and without them there can be no analysis." Chapter 14: "14.4 Patterns vs. styles It can be helpful to distinguish architectural patterns from architectural styles, where patterns are at a smaller scale than styles. Patterns can appear anywhere in your design, and multiple patterns could appear in the same design. In contrast, a system usually has a single dominant architectural style. For example, if a system has a client-server style architecture, you would expect to see client and server components in the top-level design views. The system could also employ architecture patterns, such as the Representational State Transfer (REST) pattern to constrain the format of the messages exchanged by the clients and servers, or the directory pattern, so that clients can look up the server addresses. The distinction between architectural styles and architectural patterns is not clearcut and you will undoubtedly find examples where it is hard to differentiate them. As systems get larger, it is more common to see systems-of-systems, where a system that was freestanding is now incorporated into a larger system. If the original freestanding system had an architectural style, but it is now subordinate to the larger system’s style, does that demote it to an architectural pattern? Probably. So instead of worrying about categorizing something as an idiom, a design pattern, an architectural pattern, or an architectural style, you can safely call them all patterns, and probably use the terms architectural pattern and architectural style as synonyms."
Relevant -- absolutely. The abstractions of software design evolve slowly. I'm not aware of any point where we decided old abstractions and ideas were bad, but instead we added nuance to them or added new ideas. For example, there's a lot of work now on getting DevOps right, and in particular writing code to automate deployment. That's fully consistent with there being three primary viewtypes (module, runtime, and allocation) and it actually makes the allocation viewtype (that is, what code is running on what hardware) much more visible to developers. In the old days, it was somebody's job to manually log into a server and update software or DB schemas. Now we automate that, so you don't have to go over to someone's desk to ask what version of the DB is running in production. But thank you for the suggestion. My pile of software architecture books has grown, so I'll try to get around to a video that puts them in context.
How about a short book that provides a quick introduction and lets the reader later research specific topics more in depth? Someone like me who's new to the field would probably get lost in a 700+ page book.
List of all books with links:
1. Software Architecture Perspectives on Emerging Discipline by Marry Shaw and David Garlan
www.amazon.com/Software-Architecture-Perspectives-Emerging-Discipline/dp/0131829572
2. Software Architecture in Practice
www.amazon.com/Software-Architecture-Practice-3rd-Engineering/dp/0321815734
3. The Process of software Architecting
www.amazon.com/Process-Software-Architecting-Peter-Eeles/dp/0321357485
4. Essential Software Architecture
www.amazon.com/Essential-Software-Architecture-Ian-Gorton/dp/3642191754
5. Documenting Software Architecture
www.amazon.com/Documenting-Software-Architectures-Views-Beyond/dp/0321552687
6. Software Architecture Foundation, Theory, and Practice
www.amazon.com/Software-Architecture-Foundations-Theory-Practice/dp/0470167742
7. Just Enough Software Architecture
www.amazon.com/Just-Enough-Software-Architecture-Risk-Driven/dp/0984618104
8. Software Architecture for Developers
www.goodreads.com/book/show/15734781-software-architecture-for-developers
9. georgefairbanks.com/blog/
Hi George, thanks for all suggestions!
This was an intriguing watch, thank you very much. I ordered a couple of these books that were missing from my shelf while watching (I will have to put another one up now!) and interestingly your book on Just Enough Software Architecture is already on its way to me. I have many years of experience as a software developer and a handful as a software architect (ranging from technical to enterprise solutions) and I've read a LOT of books, so I am excited to read yours and I'll be sure to let you know what I think!
Any chance to get an updated version of this video. Would really appreciate it. Thank you!
Nice compilation George!! I've them all :D
I'm very busy now studying all those books you named and others. I it was up to me, I'll add to the bullet list
-enterprise integration patterns, 574 pages (excellent in dept treatment of messaging in the context of integrating computer systems, important skill of any competent software architect in the enterprise field!)
-evaluating software Architectures
-pattern-oriented Software Architecture, - Volume 1,2,3 and 4.
Thanks George!
Great job, well done;
Definitely this video is very valuable and helpful for those who want to become master on Software Architecture.
THANKS.
So, as I understand it:
- Read the first 5 chapters of your book
- Read Essential Software Architecture
- Read Simon Brown's book "Software Architecture for Developers"
- Read all the other books when above is not enough
+Aschwin Wesselius Oh no, you heard me completely wrong: Buy lots of copies of my book and give them liberally as presents ;-) Each book I mentioned is a favorite and I'm trying to give you my mental map about what each one contributes to the canon. If I had a single correction to your list, it would be to add Documenting Software Architectures 2nd Edition to your shopping cart just to have ready when you need it. Advanced material but a goldmine.
+George Fairbanks Fair enough ; -)
George, I have a hard time getting a good resource on writing functional specification documents or any templates to see what it should contain the very least. Do any of these books cover an introduction into technical/functional writing?
Can you point me towards a good resource to get a solid start at this? I've never had a need to write these documents, so I am a bit at a loss on this one.
+Aschwin Wesselius Briefly, avoid the "shall statement" type of document; try "use cases" but don't go overboard. Use these 2 books: Alistair Cockburn's book on use cases is great, but doesn't cover architecture. The Documenting Software Architectures 2nd edition book as it covers the architecture parts and is skimpy on the use cases.
+George Fairbanks Thanks a lot for replying promptly! I will look into these sources and see if I can get a quick start on this.
A great and valuable service. Thank you.
Thanks for the reviews!
Thanks for the Video! :) Very valuable information!
Thanks. In your opinion, what is the best for a novice.
Could you add the list as a text here? If you could also link to Amazon it will be great
Dear George,
I started working in the field two years ago. I was solo at the time and overwhelmed by a big client, but there is where my love for software design was born.
Currently I am hitting the ceiling since I rely so much on my mental processes instead of writing it all down in models.
Your clear way of expressing things made me realize that I should probably read the books you recommended instead of reinventing the wheel.
Thank you,
Luka Šilje
great video..thanks for the reviews
Long time I was looking for this information. Thankyou for your review
Thank you so much for a wonderful review @George Fairbanks, I am computer scientist working for 7 years now, This means so much to me and my colleagues in my company @Mastercard
Hello and Good Day,
I am trying to get the difference between Architecture and Design pattern.
It's kind of confusing.
Do you have any suggestions?
My book covers this and I've quoted those sections below. You can treat them as synonyms most of the time. When the pattern becomes a constraint you are relying on to achieve a quality and it dominates the design, then it's probably better to say "architectural style".
Just Enough Software Architecture 2010 says:
Chapter 9: "Architectural styles can be looked at as simply architectural patterns, but their potential to be much more is evident when they are formalized as they are in the Acme
language (Garlan, Monroe and Wile, 2000) and the Acme Studio tool (Garlan and Schmerl, 2009). The insight has probably occurred in other contexts, but David Garlan’s
course on software architecture (Garlan, 2003) describes how constraints and styles are necessary tools of an architect and without them there can be no analysis."
Chapter 14: "14.4 Patterns vs. styles It can be helpful to distinguish architectural patterns from architectural styles, where patterns are at a smaller scale than styles. Patterns can appear anywhere in your design, and multiple patterns could appear in the same design. In contrast, a system usually has a single dominant architectural style. For example, if a system has a client-server style architecture, you would expect to see client and server components in the top-level design views. The system could also employ architecture patterns,
such as the Representational State Transfer (REST) pattern to constrain the format of the messages exchanged by the clients and servers, or the directory pattern, so that
clients can look up the server addresses.
The distinction between architectural styles and architectural patterns is not clearcut and you will undoubtedly find examples where it is hard to differentiate them. As systems get larger, it is more common to see systems-of-systems, where a system that was freestanding is now incorporated into a larger system. If the original freestanding system had an architectural style, but it is now subordinate to the larger system’s style, does that demote it to an architectural pattern? Probably. So instead of worrying about categorizing something as an idiom, a design pattern, an architectural pattern, or an architectural style, you can safely call them all patterns, and probably use the terms architectural pattern and architectural style as synonyms."
@@georgehfairbanks
Thank you sir
That's worth the info
I will look into the book you mentioned for more details
+Sunny
nice hairstyle. Thanks a lot for the valuable information.
It's been 4 years since the video came out. Do you still think that all information in the video relevant?
Relevant -- absolutely. The abstractions of software design evolve slowly. I'm not aware of any point where we decided old abstractions and ideas were bad, but instead we added nuance to them or added new ideas. For example, there's a lot of work now on getting DevOps right, and in particular writing code to automate deployment. That's fully consistent with there being three primary viewtypes (module, runtime, and allocation) and it actually makes the allocation viewtype (that is, what code is running on what hardware) much more visible to developers. In the old days, it was somebody's job to manually log into a server and update software or DB schemas. Now we automate that, so you don't have to go over to someone's desk to ask what version of the DB is running in production.
But thank you for the suggestion. My pile of software architecture books has grown, so I'll try to get around to a video that puts them in context.
@@georgehfairbanks "My pile of software architecture books has grown, so I'll try to get around to a video that puts them in context." .....please do
@@georgehfairbanks we need a 2021 edition please Prof.
How about a short book that provides a quick introduction and lets the reader later research specific topics more in depth? Someone like me who's new to the field would probably get lost in a 700+ page book.
Good video. Thank you.
Good Guide
awesome