:technical_leadership: :software_architecture:
In current continuous delivery environment, "traditional" architect's role breaks down due to the nature of high autonomy.
Archiects have to think about how they can be present and impact decisions in highly autonomous teams.
One solution is to conduct via the "Advice Process". Every member of the localized team can decide on architecture but beforehand, they must consult two groups of people.
One is people who are highly affected by it. The other group is people with expertise in the decision area. The decision maker must get advice from those groups and record those.
Sometimes there are so many people to talk to due to the size of the decision to be taken. Having a checklist helps to select who to speak to. This also helps in thinking about the size and impact of the decision and adjust accordingly.
When choosing people to get advice, go to people who will disagree to get different insights and to avoid bias.
It is the architecture in the head of the developer that gets to production. By making the developer in making architecture decisions, the risk of implementing wrong or different architecture is reduced.
If everyone is making archiecture decisions in their own group, how will architects make sure the whole thing is coherent?
Conversations are at forefront to make the Advice Process smooth sailing. Those conversations exist in the form of four elements supporting the process.
- a thinking and recording tool
- a time and place for conversation
- a light to illuminate and guide towards a unified direction
- a means to sense the current technical landscape and climate
Architectural Decision Records (ADRs) includes:
- title (a unique identifier with the decision itself)
- status (
Draft
,Proposed
,Adopted
,Superseded
,Retired
) - decision (summary of the decision)
- context (conditions for the decision to be taken)
- options considered (brief pros and cons for other options)
- consequences (positive and negative impacts of the decision)
- advice (record all given advice, with name of advice give and date)
ADR helps teams learn how to make architecture decisions as a thinking checklist to think and have conversations
Challenge the advice from the Process actively in ADR options section
AAF is a weekly hour-long meeting including representatives from each team with experts from conversation checklist. But it is better not to limit to those to encourage transparency and openness. The usual agenda is as follows:
- Representatives present spikes (probable future decisions) and participants reflect with existing knowledge and experience
- Decisions to be taken recorded in ADR are discussed
- Re-visit statuses of other decisions (timebox them)
- Look at [[Four Key Metrics]]
- Any other business
A good architectural principle must:
- provide a criteria to evaluate the architecture decisions
- support business strategic goals
- describe the consequences/ implications of itself
- not be too few or too many as a set of principles