What Software Architecture Should Look Like
Fleeting- External reference:
- see,
For him, there was no clear difference between when he was considered developer and when he was considered architect.
For him, it is indeed defined by the important decisions, as measured by the cost of change. But he criticizes this way of putting it because it does not emphasizes enough the evolutionary architecture. It suggest that we knew the answer before hand, while for him, we learn them along the way. Also, he suggest that there is no clear threshold between significant and not significant.
He proposes the definition “the stuffs that we hoped we knew before the project”. For him, it is a good definition because it (epistemic modesty) shows that we don’t pretend being right at the beginning and give room to change our mind when new information comes.
He emphasises the need to have freedom to make mistakes, to learn from it and fix it along the way. (continuous improvement).
It is a tourist map showing what the goal is and how the system is supposed to reach it. It is a vérité épistémique map, that changes along with new experience.
This tourist map sows the outcomes so that we can refer to it to take decision and make it evolve along the way.
when the facts change, I change my mind. what do you do, sir?
It is a snapshot of the shared understanding of the expert developers
— Dave Farley, referring to software architecture
We should not expect it to change often, but we SHOULD expect it to change.
At first, cannot honestly know what will work, therefore we have to guestimate. Hence the need to have people that have an very educated system 1 to make those. Then, we start building this tourist map. When the experience shows what works and what does not, we can adjust the tourist map.
The tourist map is mostly useful to be used in discussions about what we want to do with our product. It helps us explore the expected implications of our choices.
For him, the software architecture influences a lot the shape that the system will have. Therefore in a sense, the shape of the system is a reflect of the architecture. And then, every system has an architecture, even if emerging from nowher, and likely a big ball of mud if not thought by people with educated system 1.
Therefore, the upfront design should be just enough, not to big, but not empty either.
big design up front is dumb, but doing no design up front is even dumber
If we do a good work, we have to realize that the tourist map WONT be up-to-date and update it. We should not make the assumption that this map is static.
This map is a way to have a better view of the gestalt of the system to help thinking about important decisions. It shows the current visions, the current state and evolves when those evolve.
For him, definitions using «non functional requirements» don’t help, because they lose the focus on the fact that everything is important, otherwise we would not think about it. Yet he acknowledge that those are likely the stuff that other people (marketing etc) will more likely understand and focus on.
Also, the non functional requirements are, for him, actually cross cutting concerns, and impact the system at several different places. Therefore, they are indeed very impacting and have a high cost of change
For him, the decisions of every developer may impact the architecture of the system. It is a good thing to have master builder that take decisions, but ALL the developers should be involved to avoid the ivory tower effect. Having the tourist map helps understanding the impacts of the changes, even the small ones made by the developers.
He says that we should set up measures to test that the hypothesis we made in the tourist map are true or false. We should setup tests about those.
As soon as someone says I don’t know, treat that as a Seam, a separate concern in the design.
You should not investigate on all the stuff at first, but keep those in mind and build your system as best as you can to help you deal with it in the future.
Be intentionaly a bit vague about the details, so that it won’t engage you too much and becomes a burden rather than a design helper.