Books on Software Architecture 

+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.

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

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.