In the last couple of decades software delivery has gone through significant changes. Historically, software was subdivided into focused disciplines where different people designed, wrote, tested, deployed, and operated software during a waterfall lifecycle. Then in 2009, the DevOps movement began to consolidate these skills into more closely collaborating teams. This DevOps evolution continued and some implementations introduced the idea of “full stack” developers who could manage all of the original roles including the ability to use all necessary programming languages.
When this history is compressed into a single paragraph, it is easy to see why these “full stack” developers started to feel stressed by their breadth and depth of responsibility. In coming to terms with this, the software industry started to adopt the term “cognitive load” to capture the challenge of supporting these responsibilities. Cognitive load has been studied for many years and there are a number of short- and long-term impacts that seem to easily describe the state of software engineers and teams working with such broad and deep responsibilities. If you are interested in a more in depth look, check out a discussion with Paula Kennedy on InfoQ.
So with the realisation that software delivery was being negatively impacted by high cognitive load, organisations started to find ways to reduce this. One key example is the rise of internal developer productivity and platform teams that are tasked to remove cognitive load from application teams by centralising the delivery and maintenance of common tools.
This shift towards platform engineering teams is necessary and high impact, but in many ways the significant cognitive load is now just shifted to platform teams. Where application teams can now mainly work in a single programming language with a single operational structure, platform teams often stretch across 10s of languages and abstraction layers ranging from network IP addresses, to the impact of caching on user experience, and the preparation for black swan events like datacenters going down.
Platform teams need a way to wrangle their cognitive load which often starts with identifying their landscape. By defining the load, platform teams can find ways to divide responsibilities into the right size groups to be managed by teams just as application teams have managed to divide into reasonable sizes.
Today platform teams often document their understanding of team responsibilities and activities through folklore, though many have started to codify their understanding through a combination of team charters, living documentation that is generated from Infrastructure as Code, and more tactical runbooks.
But this documentation deserves to be a first class concern because, as Dominica DeGrandis dives into with her book Make Work Visible, teams can not hope to regain calm and productivity without clearly acknowledging the full landscape of their responsibilities. One way you can make this a more achievable task is to create a single point of entry for all platform requests and offerings. Designing an API – that may power different user interfaces depending on the user – can allow conversations about the shape and coverage of the internal platform.
This move towards an API, you can move away from hard to maintain runbooks and instead codifying your team's operational knowledge in a self serve API. If you go down this road, Kratix is a framework where you can buy the components that are non differentiating, and build the parts which only you need.
This blog is the fourth in our series, The 12 Platform Challenges of Christmas. Check back daily until January 5th, 2023 for new posts!