Turning tribal knowledge into organisational context
I wanted to help teams understand their services better, by facilitating a conversation between teams about their importance and the impacts they face.
Added some http://boringavatars.com to the Architecture Decision Records today.
Figured it makes it seem a little more friendly and inviting for comments/interactions with the page. Even tho it is just a 'demo' page, I think it conveys the ADRs pretty well.
An obvious feature, but a useful one.
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.
After starting another PoC, it stuck me something was missing; Architectural decisions.
Helping to build a complete picture of each service with your estate is one thing. Building an understanding and consensus amongst teams on the direction, challenges and impacts that estate is facing is the next logical step.
I added the Architecture Decision Records "framework", a few other enhancements, and decided to launched it as a "proper" hosted solution.
After watching Nora Jones' great talk on 'Rethinking chaos engineering' https://www.infoq.com/presentations/rethinking-chaos-engineering/ I spent a few nights last week pulling together a POC. It combines the ideas of Netflix's Monocle dashboard with a prioritisation technique called "Red Routes", and the DevOps metrics from 'Accelerate: The Science of Lean Software and DevOps'.
I wanted to capture, displaying and communicate a service's SLIs, SLOs, SLAs, and align them closer to business priority in a dashboard.
I wanted to help teams understand their services better, by facilitating a conversation between teams about their importance and the impacts they face.