Scroll to top

Automation-driven Business as Usual (BAU) operating Model

When I meet with customers and ask “What is your operating model?”, it often results in painful facial expressions followed by a few deep breaths. It also often leads to long and lengthy discussions on what they do, why they do it, what is working and what is not, why they are constrained, why they can or can’t change.

At LimePoint, our philosophy is underpinned by automation. Whenever I’m talking with customers about a keystone capability such as automation, the discussion often leads right back to operating models. Automation is a disruptor to traditional enterprise operating models, and like it or not, enterprise operating models are critical to underpinning capabilities delivered to the enterprise. If they are brittle, your systems will be fragile, not agile, and your capabilities will underdeliver the business benefits.

Before we begin, just a quick Philosophy-101 from our perspective.


Deployment is, fundamentally, bringing a thing into existence.

Management is, fundamentally, enabling a thing to continue being in existence


In most enterprises, its not an uncommon expectation that we have an enterprise application lifecycle looking something like the following.

Enterprise Application Lifecycle – Expectation

The business has expectations on delivering capabilities aligned to strategic initiatives, and typically expects the following lifecycle:

  • Business case developed, outlining the strategy and objectives of what the application or initiative is, along with clear expected business benefits that will be delivered, and how long it will be before the benefits are fully realised
  • Funding is then approved and released to the business
  • A project team is initiated to deploy
  • The initiative is delivered by the project team
  • The solution is transitioned to a BAU team that is responsible for maintaining and managing the solution in production
  • All business benefits are realised (both initial and ongoing)
  • The solution is decommissioned at end of life
  • Everyone is happy

Enterprise Application Lifecycle – Typical Reality

Unfortunately this is not always the case. A more typical lifeycle involves the following:

  • A project team created to deliver a new initiative, capability, application.
  • The team deploys the new capability to the organisation and everything is great
  • The solution is handed over to BAU to maintain it in production
  • Minimal maintenance performed on the system, and thus it degrades over time. If you only add fuel and water to your car as a part of your maintenance regime, it will eventually break down. Same goes for enterprise systems.
  • Business benefits are not fully realised by the solution
  • Develop business case to invest in new projects to deliver business benefits, and repeat the cycle

So why?

  • Its common that enterprises tend to think that deploy is the most important thing in the world
  • Maintain is at best a peripheral concern (“If the system is good, and you don’t touch it, it should always be okay”)
  • So-called BAU is considered the lowest skilled job in an organisation, and as such, is often outsourced to external providers.
    • Often reluctant and/or adverse to change
    • Often has high turnover of resources.
    • External providers do not want systems to change as it introduces risk to their ability to meet service levels (that often come with a consequence of commercial penalties)
  • Superstars get moved into projects to deploy new solutions

Lifecycle Timelines

In the overall scheme of things, the ROI on delivery of new capabilities are often calculated over a 3 to 5 year period. As a result, the deploy phase has the least potential impact to the overall business benefits realised in introducing new systems and solutions. Rather, the maintain phase is typically the longest duration, and thus, has the most potential to deliver and realise business benefits to the organisation.

Assuming a program delivery over a 5 year ROI, typical timelines for delivery of multi-year programs are

  • deploy: 12m-24m
  • maintain: 3y
  • decommission: As fast as you can run away

As a result, the potential for realising business benefits is highest during the maintenance period of the system. Being able to maintain and manage your systems efficiently, effectively, whilst minimising the costs in doing so will go a long way to delivering tangible benefits to enterprises.


In modern enterprises, continuous delivery, devops, and agile software engineering practices are commonly used as a vehicle to deliver these benefits. Nowadays, lengthy multi-year project release lifecycles are less and less common, with enterprises preferring to release and deliver capabilities (and realise their business benefits) in smaller consumable chunks (with shorter release cycles). Automation is a keystone capability that underpins all of these.

The next time someone asks “what is your operating model?”, I’d like you to consider how automation fits in.

Happy automating!