Take-away thoughts for DevOps / Agile practices

I attended the Computing DevOps Summit last Wednesday in London. It was a rather polished affair at the Grosvenor Square Marriott in Mayfair; well attended, well presented and with a broad lineup of Keynotes all roundly advocating DevOps.

It was a valuable day overall, but one speaker in particular resonated with me, as his choice of topic – ‘Unicorns and Elephants’ – is something quite familiar. The speaker, Rick Allan, Head of Delivery Capability at Zurich Insurance, spent his time waxing lyrical on the myriad challenges encountered by complex, multi-faceted organisations that have gone through significant organic growth. and the unexpected barriers this can create when adopting agile practices.

This is a scenario that I have seen in several organisations over the years – where do you even start when you have a estate that is riddled with legacy infrastructure and applications that have, over time, been ‘bolted’ onto each other, integrated with third parties and heavily customised. Automation in this landscape is a veritable minefield of problems.

My main take-aways from the event were:

  • Know what you actually have got, what it does, and what it communicates with.
  • Agree a vision with the business – implementing the changes needed to achieve that vision could have some serious cost and usability implications and so their buy-in and support is critical.
  • Pick off simpler applications first. Chipping small, tactical chunks from the monolith is going to be easier at first than trying to brute force it. Prove your method works.
  • Move away from project and start thinking by product and value stream (again – something the business really needs to get on-board with to enable this to work as this has budgeting implications.) This helps to break down velocity-sapping silos and move away from a transaction based culture.
  • Stand firm in the face of large, expensive programmes of change – they need to follow the rules too.
  • Implement a default tool-bench – a set of approved tools that are authorised and licensed for use. Migrate services over to them and shut off unauthorised tools behind you. Make sure your developers and engineers actually know about them, know what they are for and how to use them.
  • Use metrics to understand and prove where bottlenecks exist. This information can then be leveraged to determine a strategy to overcome the problem. Whatever the final option, the business case will need to be proven, and those metrics can help to establish that mandate.

In order to enable true continuous delivery, the ultimate goal needs to be consistent, converged and scalable architectures, ideally managed by smart software – and that is a long, and probably quite expensive, path for organisations with significant amounts of legacy applications and architecture. This type of change requires buy-in from the very top, and the investment, time and willpower to carry it through. Good intentions can only go so far.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s