Read on Twitter
This decentralised decision-making is the core element of any #AnarchisticArchitecture because if itâs not adopted, youâre simply not anarchistic.
But if you use this core element alone, you are sadly unlikely to realise the benefits of the anarchistic approach.
Why? Iâm going to bring in some further famous-architect assistance to help make this point.
Why? Iâm going to bring in some further famous-architect assistance to help make this point.
There's one more definition of architecture - one which I particularly love - that the power of an #AnarchisticArchitecture approach are crystalised.
It comes from @DanaBredemeyer with commentary @ruthmalan.
It comes from @DanaBredemeyer with commentary @ruthmalan.
âDana Bredemeyer introduced the ideas of architecture needing to be â(technically) good, right (e.g. fit for context and purpose) and successful (in that it is delivering value in a sustainable way)ââ
from https://www.ruthmalan.com/Journal/2016/2016JournalFebruary.htm#Still_Need_Architects by @ruthmalan
from https://www.ruthmalan.com/Journal/2016/2016JournalFebruary.htm#Still_Need_Architects by @ruthmalan
Letâs return briefly to where we began. Why have #microservices failed in so many places to date? - iI've argued that it's because the intended architecture, if there was one, didnât get shipped to production.
To be successful, an architecture needs to be RUNNING.
To be successful, an architecture needs to be RUNNING.
@RuthMalan suggests how we might remedy this:
âThe last [âSuccessfulâ], is speaking to the organisational dimension of the architect's role that is missing from "right system [right], built right [good]ââ she writes.
âThe last [âSuccessfulâ], is speaking to the organisational dimension of the architect's role that is missing from "right system [right], built right [good]ââ she writes.
âIt is very much about ensuring that conversations that are needed to be happening are happening - not always initiating them, nor always helping to focus or navigate them, but ensuring they do happen [âŠ] and guiding when neededâ @RuthMalan concludes.
We can now return to an #AnarchisticArchitecture.
Our adoption of the advice process opened up the space for anyone to make decisions, but this alone does not guarantee success. We've simply removed the possibility of more traditional architectural approaches making us fail.
Our adoption of the advice process opened up the space for anyone to make decisions, but this alone does not guarantee success. We've simply removed the possibility of more traditional architectural approaches making us fail.
The remainder of the elements of an #AnarchisticArchitecture are focused on enabling @DanaBredemeyers âsuccessâ. They are aimed at supporting @RuthMalanâs admonition to âensure that conversations that are needed to be happening are happeningâ.
There are four supporting elements:
* The first is a forum for conversations;
* The second is a thinking and recording tool;
* The third is a light to illuminate a unified direction;
* And the fourth allows for sensing the current landscape and technical climate.
* The first is a forum for conversations;
* The second is a thinking and recording tool;
* The third is a light to illuminate a unified direction;
* And the fourth allows for sensing the current landscape and technical climate.
The first supporting element in an #AnarchisticArchitecture is something to make the conversations supporting all this advice-seeking easier: an Architecture Advisory Forum. ( #AAF).
Our current #AAF is a weekly, hour-long meeting were representatives from all the development teams gather and share their active Spikes and in-progress decisions.
Also attending are the typically âalso affectedâ and âexpertâ group members.
That means we have QAs, UX, Product, leads from other teams elsewhere in the organisation, Chief Architects, ops, line managers, etc. etc.
That means we have QAs, UX, Product, leads from other teams elsewhere in the organisation, Chief Architects, ops, line managers, etc. etc.
The #AAF is a great forum for having loads of great discussions about all things architecture. Itâs also great for flagging others who might not be in attendance, but who should be consulted.
The only rule is that the advice process rules - it's the reason its called the #AAF rather than the AR(review)F or AD(ecision)Forum.
Decision-making still lives with the people needing to make the decisions. It's still the #AdviceProcess.
Decision-making still lives with the people needing to make the decisions. It's still the #AdviceProcess.
Iâve learned a lot about tweaking various elements of an #AAF to make it well attended (in our current one we typically get 20+ attendees with at least half contributing) and focused. But thatâs a topic for another thread.
It should be pointed out, #AAFs are not only useful, theyâre fun too. Many people actively look forward to them, because itâs where they learn, get great feedback and input on their pending decisions and Spikes, and also show off what theyâre doing. They're social.
When pending decisions are shared at #AAF theyâre presented in the shape of the second supporting element of an #AnarchisticArchitecture: Lightweight Architectural Decision Records https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records
Weâve found that a lightweight template structure helps folks learning to make architectural decisions. What is more, weâve scaled our decision-making and reinforced the #AdviceProcess by encouraging the leaving of comments on #ADR pages.
This means everyone can see the thoughts of people who felt they ought to provide input as a permanent record.
More importantly, the #AdviceProcess can happen asynchronously, speeding everything up, and leaving the #AAF as a forum for the key discussions, and awareness-raising.
More importantly, the #AdviceProcess can happen asynchronously, speeding everything up, and leaving the #AAF as a forum for the key discussions, and awareness-raising.
The third and fourth supporting elements of an #AnarchisticArchitecture are represented in two key fields on our #ADR template: âApplicable Principlesâ and âRelevant Radar Blipsâ. Iâll deal with them in turn.
Having Architectural Principles is not new. Neither is our approach which is 100% stolen from the excellent âArt of Scalabilityâ by Abbot and Fisher http://theartofscalability.com/ .
While their book isnât written from an #AnarchisticArchitecture perspective, the authors realise that for principles to be successful, teams which deliver against them need to feel ownership.
Check out chapter 12 of their book for everything you need to run an Architectural Principles Workshop (itâs in the section âEngendering Ownership of Principlesâ).
(And while the JADs and ARBâs in the following chapter donât fit the #AnarchisticArchitecture approach weâre following here, they do contain some great thoughts on when to update the principles.)
One final point on the principles. Theyâre only principles, and while they come from the teams themselves, sometimes they simply donât apply.
Rather than being a failure of an #AnarchisticArchitecture, itâs actually another strength - because being unable to meet a principle is a *great* time to go the #AAF and discuss things, and then detail all the reasons why youâre deviating in the resulting document.
Thatâs principles covered - which play the role of a guiding light for everyone to aspire to. But how do we also take note of our surrounding landscape and climate? Architectural decisions are also frequently based on what everyone else is doing, and who has which skills.
Enter the fourth supporting element of an #AnarchisticArchitecture: the Technology Radar. https://www.thoughtworks.com/radar
Lots of people have heard of the @ThoughtWorks #TechnologyRadar. Sadly, far fewer know about the fact you can build your own. Check out https://www.thoughtworks.com/radar/byor
The best way to make your own radar is to kick it off with a session which captures what you have now in your organisation - a baseline sweep or scan if you will.
This too ought to be run as a workshop. Iâve done them where we keep the same quadrants, but we replace the âtrialâ ring for one called âretireâ, allowing us to actively track the lifecycle of tools, techniques, platforms and languages/frameworks through the organisation.
So there we have our five elements of an #AnarchisticArchitecture; one core and four supporting:
1. Advice process
2. Architecture Advisory Forum
3. Lightweight ADRs
4. Team-sourced Principles
5. Your own Tech Radar
1. Advice process
2. Architecture Advisory Forum
3. Lightweight ADRs
4. Team-sourced Principles
5. Your own Tech Radar
Of course itâs possible to go further. Weâve seen that teams working in this way will naturally start to pave their own roads - self-serving their own delivery platform before a Platform Team comes into existence. (See @TeamTopologies for waaaaaay more detail on this.)
Iâve also seen teams put in place their own #ArchitecturalFitnessFunctions - so that they know when the collective #AnarchisticArchitecture strays outside its intended bounds.
Finally Iâve seen teams evolve their architectures - putting re-visit dates on #ADRs so decisions can be re-considered in light of additional information, and retiring / superseding decisions which have gone out of date.
