Slay The Monolith

A lot has been written in DevOps circles about the extraordinary feats that have been achieved by the so-called DevOps Unicorns. More recently the term has been co-opted by the mainstream as short-hand for why DevOps won’t work here – technological NIMBYism if you like!

In a recent post we talked about ‘how software has eaten the world’ and how established companies must find a way to compete. Having spent a week in San Francisco at the DevOps Enterprise Summit it was refreshing to hear so many transformation stories coming from these established companies. It’s always exciting to hear how DevOps is working at the bleeding edge of technology but it’s perhaps more interesting to listen to the experiences of companies that are more typically considered ‘constrained’.

At the heart of all of these conversations remained one key fact: DevOps is still about much more than just automation.

When Topo Pal from Capital One used this term in his talk with Jennifer Brady he was, as you might expect, referring to the importance of breaking down existing monolithic applications into something more loosely coupled and independently deployable (and everything that implies). This is great advice, and something we would certainly agree with, but why stop at just our applications?

One of the key goals of a DevOps approach is to enable the business to get value into the hands of customers as quickly as possible. This goal, based firmly in the principles of the Lean movement, is certainly enabled if our application architecture is loosely coupled, but what if our organisation, our structure, our communication channels and our decision making is as monolithic as the now much maligned ‘legacy application’?

A successful DevOps transformation is likely to see us aligning our organisational structure, teams and decision making to the value stream we are looking to accelerate. No matter how brilliantly architected our applications are, no matter how well-automated our deployment pipeline is and no matter how much safety our automated testing is giving us, if our organisational structure requires huge upfront planning, annual programme/ project /budget cycles, complex and bureaucratic change processes and relies on delivery by multiple disparate siloed teams we are ignoring one of the fundamental principles of DevOps; ‘any improvement not at the constraint is an illusion’.

The perfect storm of a DevOps transformation will include technical and organisational improvements. The days of the monolithic application are undoubtedly numbered but is it your bottleneck? 0ptimising an organisation to focus on small, autonomous, cross-functional teams – with shared goals and a clear understanding of the value they are delivering – is the organisational equivalent of slaying the monolith?

Written by Ed Pearson (@edwardpearson) who is a DevOps Delivery Manager at DevOpsGuys and works closely with our enterprise clients working on digital transformations.

Share this:

Leave a comment

Your email address will not be published. Required fields are marked *

*

View our privacy policy