Calls for Comment — the Slate adds comments to architectural decisions
“This is a Request For Comments (RFC). RFCs are intended to elicit feedback regarding a proposed change to the framework. Please feel free to post comments or questions here.”
This is how change has typically come about for RFCs, web standards and various other technical standards for what feels like eons.
Someone has an idea, usually an architect or development lead type person. They create a document, outlining their idea, motivation and how it might improve something. Usually there is some form of dialogue within the group — the pros and cons, the impacts this change will create. Once that group agrees, the proposal becomes the standard.
In some organisations that dialogue never really happens. In fact, in some organisations the very idea of outlining an architectural decision is completely foreign. “Ivory tower” Architect/Dev Manager/CTO makes a decision and hands it down to be enacted — whatever the impact to the developers and/or the business.
With the Slate I want to help development teams act closer to a standards body when it comes to making architectural decisions. Everyone involved being clear on the impacts those decisions is the ideal. But allowing an opportunity for diversity of thought on a given technology decision is really the most important point here.
Consensus and collaboration
You do agile right?
You do user stories, sprints, and stand-ups, and that bit about “Customer collaboration over contract negotiation” from the manifesto?
So why wouldn’t you follow that same pattern with your development teams when it comes to architectural change?
Think of an architecture decision as having a similar format to a user story
As a…
— user
I want to…
— Something
So that…
— it feels awesome
But rather
As an…
— Architect/Dev Manager/CTO
I want…
— the development teams to have input and understand the context of a decision
So that…
— everyone understand the consequences of not doing it
Allowing teams to collaborate, reach a consensus transparently, and understand the impacts is the goal of architecture decisions. It also creates a “foundation” of institutional knowledge —Why did “they” decide on that then?
If that is challenge within your teams and organisation, why don’t you give the Slate a try?
