Using defined services to target automation spend
Automating the deployment of services within an organisation is an expensive proposition.
Even with today's automation ready infrastructure, to get that automation being used successfully in production requires a large amount of time from expensive integration resources. In addition, the project management infrastructure that needs to go on top of it.
In this article we discuss how defining and offering your services ahead of that automation spend can produce better and more valuable business outcomes.
Automation spend lags customer requirements
One of the key issues that plagues large corporations is the lag between customer requirements and infrastructure teams' solutions.
With a lot of services by the time the infrastructure is automated for use at scale, the initial customer demand has faded.
This means that money spent on automating a service that has fading demand could have been better spent elsewhere. Worse still, if a number of customers were onboarded manually the organisation is left with technical debt.
Quickly offering services
Everyone wants to create the shopfront for their team.
However, often teams are focussed on only offering Services that have been completely automated and optimised in the backend. This is what creates the aforementioned lag.
Define your Service
The initial focus should be based on properly defining your service according to customer requirements. Going through this exercise as a team helps to decrease the scope of what you are offering. This encourages service provider teams to ask:
- Do we really need to ask the customer this or can we default it?
- Could this service be combined into another service?
- What does our customer really need to know/understand about the service...can we simplify it?
The creation of this Service Definition creates a clear demarcation and definition of the Service. Putting it in an ideal place to be offered.
Publish the service
"What, I should publish the service before I have even optimised or automated how it is delivered?"
It seems counterintuitive, however, how else are you going to know the demand for those services?
By publishing your available services to your customer you can then get ahead of the lag described above and be able to get data on what your customers need and don't need.
In terms of delivery of that service, it is always going to be better than your previous methods (because it is more accurately defined)
Analyse the usage
After a short time you will be able to see your user behaviour:
Now we could jump in and say that clearly ServiceA needs to be automated ASAP, but number of requests doesn't always tell the whole story. We also need to look at the amount of time or 'man hours' required to implement those requests using our current processes:
Combining these two we see that ServiceA is a clear winner.
But we can also use these metrics to really target our investments to achieve the outcomes of our business. For instance different organisations might be heavily focussed on the satisfaction and lowering wait times for developers (customers) of infrastructure. Whereas another organisation might be focussed on improving delivery reliability and reducing complexity for engineers.
Ongoing benefit
The analysis described above isn't just for a one-off case. Organisations can continuously use this to monitor their automation spend and truly align that spend with the business outcomes. Modern technology organisations are dynamic and the budget allocation should also be.
NetOrca
NetOrca allows your organisation to:
- Define services quickly
- Offer them directly to a customer git repo
- Continuously manage those services throughout their lifecycle
- Track services usage, delivery time and other metrics
All of the above can be supported, regardless of how advanced your engineering team is in terms of automation.
For more information see NetOrca