A while back, I asked “what is architecture?” and I got many responses within just one day. Some serious, some more (bitter-sweet) joking. We can identify some cluster of responses, but even so, there are certainly a dozen distinct perspectives.
1/
https://twitter.com/girba/status/1341828980501057542
1/
That there are many perspectives is not a surprise given that the literature is full with competing definitions. For example, it's not atypical for architecture books to say something like: “there exists many definitions, so here is ours”.
2/
https://twitter.com/englebertv/status/1341834393388797953
2/
The search for the perfect definition of architecture captured the imagination of several generations by now, yet it still seems to remain elusive. But, what if it’s Ok to have many of them?
3/
https://twitter.com/girba/status/1341872009945501696
3/
Perhaps it’s time to consider a new quest. So, try this.
Instead of “what is architecture?”, ask “what is architecture FOR?”.
In other words, when is architecture important?
4/
Instead of “what is architecture?”, ask “what is architecture FOR?”.
In other words, when is architecture important?
4/
We find that whatever we mean by architecture, it is most relevant before we want to make a decision.
This perspective is interestingly unifying. Bare with me. I promise it's relevant.
5/
This perspective is interestingly unifying. Bare with me. I promise it's relevant.
5/
Consider that developers spend most of their time figuring the system out with the goal of learning what to do next. Decision making!
And the further away we move from the one that commits code, the decision making part is only more evident.
6/
And the further away we move from the one that commits code, the decision making part is only more evident.
https://twitter.com/girba/status/1352734434613727232
6/
It's decision making all the way down. Or up. Given that this is what occupies largest chunk of our energy, perhaps it is worthwhile to regard software engineering as being primarily a decision making activity rather than a construction one.
7/
https://twitter.com/girba/status/924552678029570049
7/
It is also interesting to observe how because we are so focused on the construction part, it's now ridiculously cheap to create new code. At the same time, we are unable to recycle existing systems.
8/
https://twitter.com/girba/status/1246750717538373632
8/
It is imperative to optimize how we reason about our own systems, too.
Back to architecture (you see, I promised). Instead of focusing on architecture and architects, we can simply focus on the properties we want our systems to have.
9/
Back to architecture (you see, I promised). Instead of focusing on architecture and architects, we can simply focus on the properties we want our systems to have.
https://twitter.com/girba/status/1246755047909855232
9/
The time spent on code reading is not distinguishable from what is considered as architecture time. Developers are architects, and whatever architecture is, it is the result of a negotiation that perpetuates with every commit.
10/
https://twitter.com/girba/status/1278252324092350464
10/
People might disagree with the above assertion and emphasize that architecture captures the important parts. This view begs the question of what is not important, and also when.
11/
11/
Indeed, a system can have a gazillion details, and most of those details will not be relevant for most decisions. At the sane time, most of those details will be relevant for at least one decision.
12/
12/
If you only prepare yourself to decide about some parts, you will not be prepared to react to issues in the rest of the parts. So, rather than debating what is important and what is not, what if we equip ourselves to deal with any detail instead?
13/
13/
Architecture is an emergent property that results from daily, often minuscule and implicit interactions. You cannot control the result, but you can orchestrate the interactions. The process should host the negotiation explicitly.
14/
https://twitter.com/girba/status/1071849222985666560
14/
How to orchestrate the architecture negotiation?
Through daily assessment:
- A stakeholder identifies a concern.
- A facilitator creates a tool to capture the concern.
- The data together with the proposal of how to address the concern are presented to the team.
...
15/
Through daily assessment:
- A stakeholder identifies a concern.
- A facilitator creates a tool to capture the concern.
- The data together with the proposal of how to address the concern are presented to the team.
...
15/
- Anyone can challenge.
- If the team agrees, it takes action.
- The conversation only happens if there is data.
- If the conversation lasts for more than 5 minutes, it's stopped because the data is not clear enough
Most often, this leads to decisions within minutes.
16/
- If the team agrees, it takes action.
- The conversation only happens if there is data.
- If the conversation lasts for more than 5 minutes, it's stopped because the data is not clear enough
Most often, this leads to decisions within minutes.
16/
When talking about architecture, people often think of the construction part. Daily assessment is about knowing where you are at all times and being able to react and adjust. It's not a replacement for design. It's complementary.
17/
https://twitter.com/girba/status/1352255981464522756
17/
Some people ask how is this different from a typical standup. A typical standup is focused on synchronization, and it mostly talks about what's on the board, which is functionality. It's rarely about technical parts and it's almost never about decisions.
18/
18/
Daily assessment empowers the team to make the conflicts in code explicit. It does rely on the technical ability of creating architectural checks and visualizations quickly, but the emphasis is on how the team can make and execute technical decisions as a group.
19/
19/
What concerns are allowed? Any concern. From how a function is named to how the global dependencies are organized. A concern is valid as long as there is an interested stakeholder. Who can be a stakeholder? Anyone that has a stake in the system. Yes, developers too.
20/
20/
Is this not wasteful? On the contrary. All details are important at some point. It does not matter how trivial it might appear, it's more important to exercise the collective muscle of grasping the probelm and correcting it. The best way to build muscle is to train daily.
21/
21/
Daily assessment relies on the two #MoldableDevelopment roles:
- the stakeholder owns the problem and the decision, and
- the facilitator molds dedicated tools.
Of these, it is the stakeholder role that is the hardest to train.
22/
- the stakeholder owns the problem and the decision, and
- the facilitator molds dedicated tools.
Of these, it is the stakeholder role that is the hardest to train.
22/
• • •
Missing some Tweet in this thread? You can try to
force a refresh
