1.\u00a0\u00a0\u00a0 Calculate your service\u2019s deployment throughput.<\/h2>\n
The first thing to determine is the throughput requirement for your service. That means:<\/p>\n
- \n
- How often are changes needed for that service?<\/li>\n
- How often will it be valuable to deploy new features within a certain period of time?<\/li>\n<\/ul>\n
To answer those questions, you really need to ask yourself, at a business level:<\/p>\n
- \n
- Will this specific service create more value by getting deployments to market quickly?<\/li>\n
- Will this service benefit from launching new features to customers far more regularly?<\/li>\n<\/ul>\n
The utility of your service will drive the deployment throughput, and there are many ways this can play out.<\/p>\n
For example, you might only want to change a service once each week. But when you make that change, you need it deployed incredibly quickly. Compare that to a requirement where you have multiple changes per week for a service, but they can be deployed less rapidly.<\/p>\n
If you\u2019re deploying one or two features per fortnight, that is a low requirement for throughput.<\/p>\n
On the other hand, deploying multiple features per week\u2014or even per day\u2014indicates a higher requirement for deployment throughput.<\/p>\n
The higher a service\u2019s requirement for deployment throughput, the more likely you will benefit from a You Build It You Run It operating model.<\/p>\n
Services with a higher requirement for deployment throughput (i.e. deploying multiple features per day, rapidly) will likely see significant benefit from a You Build It You Run It operating model. This is largely because your team will have far more control over how quickly they can make deployments.<\/p>\n
In contrast, an Ops Run It model typically involves rigid schedules and gated milestones. This is problematic when, in my experience, most organisations want<\/em> the control and flexibility to deploy new features independently. Or, to have more granular control on how much they deploy and when, rather than waiting for a cyclical batched deployment that could take weeks (or months).<\/p>\n
You Build It You Run It is an excellent way to achieve this flexibility and remove the constraints\u2014and risks\u2014associated with batched deployment.<\/p>\n
Learn more about how You Build It You Run It can support your team to launch new product features to market every day<\/a>.<\/p>\n
In these instances, You Build It You Run It can also mitigate risk<\/span><\/strong><\/p>\n
In addition to providing greater flexibility for deployment cadence, You Build It You Run It can remove the risks associated with batched deployment. This is because:<\/p>\n
- \n
- More frequent deployments mean you can be more incremental in your approach, minimising the potential blast radius of a failure.<\/li>\n
- Fewer features are deployed as a bundle, meaning less risk of failure.<\/li>\n
- It\u2019s easier, faster and more cost-effective to identify the cause of a failure<\/li>\n<\/ul>\n
2.\u00a0\u00a0\u00a0 Understand your service\u2019s financial exposure on failure.<\/h2>\n
Almost inevitably, whenever you ask a business: ‘How much does your service need to be up and available?\u2019 the answer is: \u2018All the time. 24\/7’.\u00a0 Alternatively, you might hear: \u2018We have a five-nine requirement \u2013 99.999% availability.\u2019<\/p>\n
Fair enough. Always on means always profitable, right? Wrong. In fact, an ‘always available’ approach can create unnecessary costs. This is where I typically ask the following types of questions:<\/p>\n
- \n
- Are you more financially exposed (i.e. will you lose more revenue) if the service goes down at one time as opposed to another? For example, during the day versus 3am?<\/li>\n
- How much will the business stand to lose if the service goes down?<\/li>\n
- How much revenue is not <\/em>generated if the service goes down?<\/li>\n
- How many customer complaints will the service\u2019s failure cause, which in turn will cost you money?<\/li>\n<\/ul>\n
These questions are designed to help you think of financial exposure on failure as a mix of:<\/p>\n
- \n
- the costs associated with lost prospective revenue when you have an incident (for example, sales that don’t go through) and<\/li>\n
- the costs of treating and resolving incidents for a service (for example, calling an out-of-hours support team to rectify an issue).<\/li>\n<\/ul>\n
Let\u2019s look at two applied examples for different types of services, in the context of a national retail business. The services are as follows:<\/p>\n
- \n
- An operations system for packing and shipping orders in the warehouse: <\/strong>this service will have significant financial exposure during working hours only (assuming the shop doesn\u2019t offer round-the-clock shipping). This is because workers will depend on the service to complete their role in the warehouse during business hours; if the service goes down, they are sitting inactive and unable to process orders. If the service goes down out of working hours\u2014when there are no employers relying on the service\u2014there is far less financial impact.<\/li>\n
- Customer-facing ecommerce services: <\/strong>in comparison, this service will likely have greater financial exposure on fail, for a wider window. People might be shopping online in the early morning, throughout the day and into the evening. If the service goes down, we lose potential revenue on prospective sales because people can\u2019t buy products.<\/li>\n<\/ol>\n
Your service’s financial exposure should inform an availability target<\/span><\/strong><\/p>\n
When assessing an availability target, we consider availability requirements across the whole day.<\/p>\n
For example, 99.999% availability means a service can only be unavailable for a few seconds over the course of the day. In comparison, a 95% availability target can allow services to be down for an hour or two.<\/p>\n
Considering the two examples above:<\/p>\n
- \n
- The operations system for packing and shipping orders in the warehouse: <\/strong>the financial exposure here will be much lower than the business might expect, because the service only need to be available from 8am to 6pm.<\/li>\n
- Customer-facing ecommerce services: <\/strong>the financial exposure here is much higher and for a longer period of time throughout the day. As a result, the availability target should be much higher to protect against lost revenue during service downtime.<\/li>\n<\/ol>\n
With figures for deployment throughput and financial exposure on failure, you can select an appropriate operating model.<\/span><\/h2>\n
The higher your requirement for deployment throughput, the more your service will benefit from You Build It You Run It.<\/p>\n
The higher your financial exposure on failure\u2014and therefore the higher your availability target\u2014the more your service will benefit from You Build It You Run It.<\/p>\n
But what if you have a high financial exposure on failure and a low requirement for deployment throughput?<\/p>\n
The chart below offers a basic guide to help you identify the most suitable operating model based on your requirements for each metric.<\/p>\n
![\"\"](\"https:\/\/www.equalexperts.com\/wp-content\/uploads\/2022\/11\/Screen-Shot-2022-10-25-at-2.34.22-pm-1200x775-1.png\")
\nIf you\u2019d like to know more about You Build It You Run It check out the video below. You can also find more information in: Build It You Run It Playbook<\/a><\/p>\n
If you\u2019re looking for more guidance in assessing services or systems, or you\u2019d like to talk about your organisation\u2019s unique requirements, please get in touch to arrange a conversation.<\/p>\n
- Customer-facing ecommerce services: <\/strong>the financial exposure here is much higher and for a longer period of time throughout the day. As a result, the availability target should be much higher to protect against lost revenue during service downtime.<\/li>\n<\/ol>\n
- Customer-facing ecommerce services: <\/strong>in comparison, this service will likely have greater financial exposure on fail, for a wider window. People might be shopping online in the early morning, throughout the day and into the evening. If the service goes down, we lose potential revenue on prospective sales because people can\u2019t buy products.<\/li>\n<\/ol>\n
- An operations system for packing and shipping orders in the warehouse: <\/strong>this service will have significant financial exposure during working hours only (assuming the shop doesn\u2019t offer round-the-clock shipping). This is because workers will depend on the service to complete their role in the warehouse during business hours; if the service goes down, they are sitting inactive and unable to process orders. If the service goes down out of working hours\u2014when there are no employers relying on the service\u2014there is far less financial impact.<\/li>\n
- How many customer complaints will the service\u2019s failure cause, which in turn will cost you money?<\/li>\n<\/ul>\n