I've seen this pattern all too often in organisations with microservices. Service A (that people interact with) relies on Service B and C. Service B & C constantly fail, but Service A gets a bad rap with their users. The teams responsible for B & C don't know about the impact they are having on Service A. I got inspired by a talk given by Nora Jones on 'Rethinking chaos engineering' and decided I wanted to fix that. So I built the Slate to capture SLIs, SLOs, and SLAs with the business value of a particular service, alongside architectural decisions. The Slate helps build a complete picture of each service. But more importantly, it facilitates a conversation between teams about the importance of any given service. By building an understanding, and consensus amongst teams on the direction, challenges and impacts that overall technology estate is facing. You know what the next steps are going to be to resolve those. So, if you’re in a situation like I’ve been before; with constant upstream/downstream impacts, people not understanding the importance of a service or just general architectural communication issues. Then perhaps the Slate can help make your teams be a little more awesome than they already are.

The Slate

We need to turn tribal knowledge into organisational context

We need to turn tribal knowledge into organisational context

The Slate

We need to turn tribal knowledge into organisational context

We need to turn tribal knowledge into organisational context

Similar Products

Do you use The Slate?

Do you use The Slate?

You might also like