Previously, I've covered the importance of the SRE and DevOps principles. These principles are only one side of the equation. To justify a unit of work, be it a large or small, you need both the how and the why.
Principles cover how we work. They provide helpful guidance and remind us of the correct way to do things. They don't tell us why we do things. For that, we have business goals.
Every business is trying to solve a problem, those problems are the reason the business exists. To solve these problems, you need to set goals and work towards achieving those goals.
At the highest level, a business would have a mission statement. The SRE team cannot work directly off of this, as it's not specific to the team. Between the missions statement and the SRE team, you could have enterprise architecture. TOGAF is an enterprise architectural framework that provides tools and resources to help enterprises, in the delivery of the business strategy. Enterprise architecture is outside the scope of this blog for now, I may decide to cover it in the future. For now, let's just skip those steps and create a nice set of SRE specific business goals.
Decreased time to roll out new projects
Increased rollout of new projects
Lower cost in rolling out new projects
Use of products: as far as possible, hardware-independent, off-the-shelf items should be used to satisfy requirements in order to reduce dependence on custom developments and to reduce development and maintenance costs.
An example
Let's assume we are working for an organization that has one product, a website that sells my Little Pony figures (Bronies are a big market). This website sits on a server, and is deployed by the developers taking a snapshot of the code and manually copying it to the server.
Currently, we can only deploy once every month, it regularly fails and costs a lot of development time.
As SRE's, it is our responsibility to improve this situation, but there are multiple ways to do this. The first thing we should do is create a proposal with a few different options.
Options
SRE will take on the responsible for copying the source code to the server.
Write a script to copy the source code to the server.
Build a CI/CD Pipeline to deploy the code.
Using both the Principles and Goals, we can analyse the options.
SRE will be responsible for copying the source code to the server in the future.
Description:
In the future, the SRE team will copy the source code for the "My Little Pony" project to the web server when we do a release.
Principles:
Goals:
Write a script to copy the source code to the server.
Description:
The SRE team will create a script that can be run by the developers, that will package up the code for a given tag. This packaged code with then be copied to the server and unpackaged.
Principles:
Operations is a software problem
Work to minimize toil
Automate this year's job away
Goals:
Decreased time to roll out new projects
Build a CI/CD Pipeline to deploy the code.
Description
The SRE team will create a CI/CD pipeline. This will connect to our code repository and when a new release has been tagged, it copies the code to the build server, builds it, runs unit tests and deploys it to the web server.
Principles:
Operations is a software problem
Work to minimize toil
Automate this year's job away
Change should be gradual
Measurement
Goals:
Decreased time to roll out new projects
Increased rollout of new projects
Lower cost in rolling out new projects
Use of products: as far as possible, hardware-independent, off-the-shelf items should be used to satisfy requirements in order to reduce dependence on custom developments and to reduce development and maintenance costs.
From this very simple example, we can look at the principles and goals that each option covers. It's clear that the 3rd option is the right choice, it covers all our business goals, and a good set of principles. This is the what.
This of course doesn't include contextual information on whether the code is CI/CD ready and size estimations.
If your company is on the SRE or DevOps journey. You are considering SRE or DevOps. Or you need some support, feel free to book a free 45-minute call with me.
Conclusion
In this article, I introduced business goals, why we need them and how they work alongside principles. I went through an example problem and proposed 3 solutions. With each solution listing the goals and principles it meets. All in the aim to help us workout the best solution to the problem based on the goals and principles it meets.
Comments