Do we need DevOps or Automation?

19 April 2018 | By Mark Preston

About 7 years ago, I recall emailing the entire project team to raise awareness on DevOps which at the time was a pretty fresh term. We were working on a major government application project; they have an unfortunate habit of failing and the aspiration was to run the entire project in an Agile methodology, in the hope that this would avoid seeing the project on the front pages of the national press. Looking back, there was a real lack of clarity on what was needed and I still see some of that in customer environments today. DevOps and Agile were ingredients for success, but the main event in that project was Automation.

As with most things in life, understanding the drivers for change and the associated challenges should influence the choices of the tools or methods needed. The technology industry is dominated by talk of digital transformation and this depends on changes to the underlying operating model, typically supported by cloud. DevOps, Automation and Agility are all invited to the party, but clear thinking is needed when choosing where and when to spend the hard earned transformation budget.

Can we be Agile all the time?

Industry trends and the associated marketing can be a positive aspect to help define the direction of travel, but they can be equally damaging if the positioning is not clear. Business frustration with the inability of IT to react quickly has driven a view that Agile methods are the answer to all evils. Establishing the true business aspirations and willingness to trade off speed versus risk lie at the heart of driving an appropriate process methodology.

There is a clear benefit to being able to get a return on investment in Development quickly, especially if the application requirements are not clear cut. The expectations of the millennial consumer raises the bar on not only delivering compelling applications, but the significant consumer experience wrapped around it.

The days of operations being able to have applications thrown over the wall, and taking a reactive approach to operations no longer meet the digital experience expectations. Agile and Development go hand in hand in most cases, but Agile and Operations is a different story; a hastily accepted change that impacts services won’t get any forgiveness in the customer experience stakes.

To support Development and Operations working in harmony means that a Bimodal approach is needed if Agile is to extend into operations. Governance needs to lay down some policies on what changes may be accepted with an Agile process and those that still need formality. Cloud does not escape from the story here either. If a standards and services based cloud is on offer to the development team, then they can take things off the shelf that are proven, rather than reinventing the wheel and driving change. Aside from cost, this is one of the key benefits of public cloud providers who are very standards and services based.

Operations and Automation also go hand in hand and with targeted investment can support continuous development and testing; this can in turn enable more Agile acceptance but with appropriate risk mitigation. Aside from supporting the Agile goals, Automation can play its role not just on the cost to operate but the ability to react quickly to address experience issues. Care needs to be taken to automate processes that are reusable to get a return on the investment.

How can Operational Automation play its part?

Automation is just another layer of software development. If DevOps has prevailed to bridge the wall from Development to Operations, then the smart move is to use the development team to help with the Operational Automation. Attention is needed on focus and goals as often the development team are under fire to achieve application features, and development cycles for Automation can fall low on the priorities.

Another reason this makes sense is with increasing machine driven Automation there is a dependency on machine readable standardised information. Why have a developer write a word specification document for a person to approve, when they could write a template that a machine can validate and use?

Are Orchestration and Automation the same thing?

I come across this challenge a lot on transformation projects; colleagues know I have a habit of creating analogies to try and simplify things - I find this especially useful when the topic is subjective or loosely defined. For Orchestration, process workflow and Automation and how they are aligned to operational performance, I created the following analogy:

Let us consider an orchestra of musicians; they all have instruments, the orchestra is led by a conductor who will be guiding them to stay in sequence and timing, based on the piece of music they are playing, which will be written down in a musical score. The qualities of the performance are based on many factors:

  • The score itself - what are they playing?
  • The conductor - can he or she get everything sequenced and timed well?
  • The musicians - can they play their part well and in time?
  • The instruments - do they deliver the required sound quality?

In the context of service orchestration and operational automation, the terminology may be different but the challenges are the same:

  • The workflow - what is the orchestration seeking to achieve?
  • The orchestrator - what needs to be done and in what sequence?
  • The systems involved - what systems are needed in the workflow and how are they integrated with the orchestrator?
  • The changes needed - what automation steps will drive change to the systems (ordering, configuration, etc.)?

The attraction of automating instruments to replace the human musicians is not attractive to music lovers, but in a technology context this is the key consideration for automation of human process. Automation carries a cost and the return on the investment will come if the process needs to be executed regularly, and also if the process integrity is important (avoiding human error).

How can DevOps and Automation drive operational efficiency and the digital experience?

Approaches to automating human process are not new, with many organisational workflow systems typically handling hand-offs of requests and approvals across departments and owners (e.g. ordering a new laptop or getting expenses approved). The efficiency of an orchestration workflow needs a similar level of scrutiny and governance as any process automation, but the approach needs to factor in some fundamental aspects to avoid inefficiency across the human to machine interaction. Putting some structure to the challenge needs broader capabilities (both technology and process) in the following areas:

  • Orchestration: What is the optimal hierarchy of orchestration ownership aligned to service layers, catalogues and the supply chain?
  • Control: Does a human need to be involved in the workflow or can it be 100% machine driven? What controls prevent authorisation being exceeded?
  • Policy: How can a workflow be controlled without human interaction? How can the policies become machine readable?
  • Management: What technology management tools will the workflow interface with and the associated systems integration dependencies?
  • Analytics: How will the workflow be measured and analysed? Does the service need to be proactively adjusted to meet expectations?

Only with a cohesive approach to these challenges may we expect to get close to operating at not only the appropriate cost levels, but achieve the expected performance both operationally and in the eyes of the digital consumer.

Stay tuned for more expert content from Mark Preston, associate and lead architect advisor to! 

This is the title of the download