Book takeaway: Design It! Intro
Intro
Some key notes from the very beginning of the book Design It! - From Programmer to Software Architect by Michael Keeling.
Responsibilities
- Define the problem from an engineering perspective
- Divide the system into implementable chunks while keeping the big picture
- Decide (or identifiy in the first place) trade-offs among quality attributs
- Manage the growth of techinal debt.
- Develop the architecture skills of team
“Software design is a constant strugfgle to find the right balance between the things you wantand the reality you must accept.”
Architects seem to be in the middle of everthing
- Business
- Technology
- Users
“Without an architecture, software, like water, follows the path of least resistance and sprawls uncontrollably.”
What is architecture?
- The set of significant design decisions to promote the desired quality attributes
“Architecture is about the important stuff. Whatever that is”
Martin Fowler
Significant design decisions (where significant is measured by the cost of change)
Describing
Take care of precise speech! Consider:
- Module - structures that exist at design time. files, classes, …
- Component and connector - exists at runtime! objects, threads, processes …
- Allocation - responsibilities, physical things, people, organizations.
If we need a more abstract term to describe something, use element
“Using a term with specific meaning to describe something general can create confusion”
“use the essential concepts and core vocabulary of architecture as the starting basis for collaboration.”
Make the important stuff visible!
My words: Don’t forget to describe the quality attributes! Very often they’re hidden. Yes, of course, everybody wants everything to be available, reliable, fast, scalable, maintainable. Problem is: That stuff comes at a cost. Often, those attributes might contradict each other. So let’s make them visible!
“Point out when the team makes trade-offs”
“Anyone who makes a decision that influences the structures of the software system becomes the architect pro tempore”
Let’s make it apparent when that happens! E.g. tell everyone that this is going into the architecture decision records (adr).