Facilitating Software Architecture: Empowering Teams to Make Architectural Decisions
To get better at making decisions
That are:
Not blocking progress while waiting on "The Architect" to decide for us
Not letting faraway folks from making "architecture" decisions that are out of touch with reality -- we decide for ourselves, and we know the details because we live in the details
When the decision only affects our team,
We make good, fast, collaborative decisions
How do we decide when there are multiple teams that will be impacted?
Here are some patterns
These are reductive models -- it's not as black and white as this
Whichever team arrives at the need for the decision first makes the decision.
Gather everyone together and chat until we agree.
Let Chris make the call.
It might or might not be good, depending on whether Chris has enough context
It might or might not be fast, depending on whether Chris happens to be available
The "Architecture Advice Process"
Anyone can take and communicate an architectural decision as long as during the option-making stage, they seek advice from everyone who will be meaningfully affected by the decision people who have expertise in the area in which the decision is being taken
Anyone can take and communicate an architectural decision as long as during the option-making stage, they seek advice from
This opens up some questions:
Next week in the continuous improvement LII we're discussing a few chapters of the book
If you're interested, please join us!