anitsh
commented
3 years ago Fundamentals of Software Architecture — Neal Ford and Mark Richards https://www.youtube.com/watch?v=fvSZ7gocaxI
Notes:
-
Everything in Software Architecture is a "Trade-Off". Trade-off which eventually will be discovered, if not seen now. There is no best practices in software architecture.
-
"WHY" is more important than "HOW". Why I made the decisions in the Software Architecture. Architectural Decision Records (ADR) helps to answer the "WHY".
We can document of the current state of the system which answers "WHAT" decision were made going through the code but we will not be able to review the history on "WHY" the decisions were made which are essential to understand mental processes.
As an Architect, the most difficult part is trying to negotiate the technical parts.
As an Architect will never achieve the best design, what an Architect should do is try to make the least worst decision.
The job of an Architect is not to memorize every solution but when a novel situation is presented, an Architect should objectively assess the trade-offs on either sides and make an informed decision, document the decisions in the ADR and move forward. The correct technical decision that is made now might not fit the technology upgrades in the future and could be a factor in Technical Debt which is normal.
Architect should should be hands on code but not necessarily an experts of expert and have should have holistic knowledge.
Agile thinking - The longer it takes to make a decision (including the learning time it takes), it impedes more in the progress.
Podcast: Rebecca Parsons talks to Neal Ford and Mark Richards on Fundamentals of Software Architecture.
Companies these days to survive have to be more agile. We can't turn a large ship for several years. It has to turn within a matter of months now. The problem is our architectures are not easy to change in a lot of these companies.
That agility within business trickles down to the actual ability to change an architecture itself to maybe sometimes even redirect that business. Yeah, these two changes combined are really the precipice for this.
Nonfunctional requirements or system quality attributes or abilities are the architectural characteristics People have made that have led them to make less good decisions in architecture or delay decisions longer than they necessarily need to within an architecture.
In a Microservices architecture different services can have different architectures. Where should the boundary of the
What a good architecture looks like that definition does not exists. The second law of software architecture - Why is more important How. In the software architecture document, it is visible "How" it is solved but not "Why".
There are the no best practices in Software Architecture.