As a business, you should never go ‘all in’ on either Ops Run It or You Build It You Run It. Why? Because the operating model you select should be chosen based on the unique requirements of each digital service. So, the obvious question becomes: what do you assess to determine the ideal operating model?

Firstly, let’s clarify some terminology. When I talk about assessing a ‘service’, I’m referring to anything from digital services (like a customer facing e-commerce application) to foundational systems.

And while their requirements might be quite different, you can use the same metrics to assess the most suitable IT operating model.

Those metrics are:

1. The demand of deployment throughput for the individual service, and
2. The financial exposure on failure of that service.

1.    Calculate your service’s deployment throughput.

The first thing to determine is the throughput requirement for your service.

That means:

• How often are changes needed for that service?
• How often will it be valuable to deploy new features within a certain period of time?

To answer those questions, you really need to ask yourself, at a business level:

• Will this specific service create more value by getting deployments to market quickly?
• Will this service benefit from launching new features to customers far more regularly?

The utility of your service will drive the deployment throughput, and there are many ways this can play out.

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.

If you’re deploying one or two features per fortnight, that is a low requirement for throughput.

On the other hand, deploying multiple features per week—or even per day—indicates a higher requirement for deployment throughput.

The higher a service’s requirement for deployment throughput, the more likely you will benefit from a You Build It You Run It operating model.

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.

In contrast, an Ops Run It model typically involves rigid schedules and gated milestones. This is problematic when, in my experience, most organisations want 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).

You Build It You Run It is an excellent way to achieve this flexibility and remove the constraints—and risks—associated with batched deployment.

Learn more about how You Build It You Run It can support your team to launch new product features to market every day.

In these instances, You Build It You Run It can also mitigate risk

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:

• More frequent deployments mean you can be more incremental in your approach, minimising the potential blast radius of a failure.
• Fewer features are deployed as a bundle, meaning less risk of failure.
• It’s easier, faster and more cost-effective to identify the cause of a failure

2.    Understand your service’s financial exposure on failure.

Almost inevitably, whenever you ask a business ‘how much does your service need to be up and available?’ the answer is: ‘All the time. 24/7

Alternatively, you might hear: ‘we have a five-nine requirement – 99.999% availability.’

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:

• 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?
• How much will the business stand to lose if the service goes down?
• How much revenue is not generated if the service goes down?
• How many customer complaints will the service’s failure cause, which in turn will cost you money?

These questions are designed to help you think of financial exposure on failure as a mix of:

• the costs associated with lost prospective revenue when you have an incident (for example, sales that don’t go through) and
• the costs of treating and resolving incidents for a service (for example, calling an out-of-hours support team to rectify an issue).

Let’s look at two applied examples for different types of services, in the context of a national retail business. The services are as follows:

1. An operations system for packing and shipping orders in the warehouse: this service will have significant financial exposure during working hours only (assuming the shop doesn’t 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—when there are no employers relying on the service—there is far less financial impact.
2. Customer-facing ecommerce services: 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’t buy products.

Your service’s financial exposure should inform an availability target

When assessing an availability target, we consider availability requirements across the whole day.

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.

Considering the two examples above:

1. The operations system for packing and shipping orders in the warehouse: 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.
2. Customer-facing ecommerce services: 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.

With figures for deployment throughput and financial exposure on failure, you can select an appropriate operating model.

The higher your requirement for deployment throughput, the more your service will benefit from You Build It You Run It.

The higher your financial exposure on failure—and therefore the higher your availability target—the more your service will benefit from You Build It You Run It.

But what if you have a high financial exposure on failure and a low requirement for deployment throughput?

The chart below offers a basic guide to help you identify the most suitable operating model based on your requirements for each metric.

If you’d 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

If you’re looking for more guidance in assessing services or systems, or you’d like to talk about your organisation’s unique requirements, please get in touch to arrange a conversation.