The Great Devops Rabbit Hole

00

We've come a long way... or have we?

It's 25 years since the inception of the modern Internet. And yet, the majority of organisations remain faithful to pre-digital methods of designing, developing and deploying new products and services.

In production terms, most firms have far more in common with Henry Ford's division of labour-based processes than the DevOps approach adopted by Patrick Debois and Andrew Clay Shafer. That's predominantly the case whether you look at a hardware-driven business or a software-rooted one.

Granted, there are business models like Netflix and Uber that are truly disruptive in both product and process, but they remain rare exceptions within the context of the global business community. For every masterclass in speed and fluidity, offered up by the likes Adobe and Amazon Web Services, there are thousands more akin to the more traditional 'assembly line' movement. This disparity has drawn attention to one important teaching:

A small handful of highly-engineered product releases per year is no match for the beta release strategy, spinning up hundreds of apps and features every quarter.

"Today, it's about short sprints, quick releases and imperfect betas. It's about fast fail or rapid scale – the market ultimately deciding your product's destiny. It's about adopting a more agile practice, fit for the modern business landscape. Enter DevOps."

While production specialisation extolled the virtues of ruthless efficiency in HenryFord's day, it now acts as a physical and psychological drag on the modern enterprise and its workforce. And that's because the waiting game is over. The era of cloud computing, remote working and over-the-air updates has dulled the end user's feeling of excitement and anticipation for every 'full fat' new product release. Today, it’s about short sprints, quick releases and imperfect betas. It’s about fast fail or rapid scale – the market ultimately deciding your product’s destiny. It’s about adopting a more agile practice, fit for the modern business landscape. Enter DevOps.

Keep going

01

Driven to distraction

Build. Test. Release.

Repeat

In education circles, it's common to hear about 'teaching to the test'. It's a policyborne of the political need to keep schools and teachers accountable for students' academic success, or lack thereof. However, for many, it has led to a reduction of morale and a narrowing ofeducational outcomes as teachers focus on the end of year test at the expense of providing a multi-faceted education. And it's this analogy – along with the Henry Ford one – that makes for a useful comparison with what's happening in IT and software engineering disciplines.

On the one hand, there's arguably been too much specialisation across the full gamut of software development and IT operations roles. Specialisation that has naturally occurred as a result of linear or waterfall design development models that can trace their ancestry back to the division of labour.

"You find a defect in the code on the cusp of product release and the developer is essentially sent back to square one."

On the reverse side, we have a broad IT-based profession that is being held hostage to the test. The product development roadmap – build, test, release – is flawed by its simplicity in design and by its complexity in practice. It can be argued, quite pointedly, that the mid-stage of the process – testing – is rarely undertaken before it's too late.

The net outcome is a lost opportunity. A missed opportunity to innovate, to improve productivity, to stay competitive. In some cases, it's catastrophic – yet we stubbornly persist with this linear development approach, which leads to unnecessary specialisation and silo thinking.

Industry analyst, IDC, refers to groups that practice such behaviour as the “DevOps Distracted”. Why? Because the status quo in many organisations (culture, structure, technology, experience, skillset) has the effect of distracting the enterprise from embracing change that they have self-identified as being necessary.

In truth, most software engineering and IT operations personnel intuitively think that DevOps is an antidote to organisation inefficiency. They strongly suspect that it can remove most of the blockers to digital transformation. However, the lack of DevOps skills and experience in its deployment – plus the cultural barriers– are a large part of the reason why they are torn between a blue pill, red pill situation.

Delve deeper

02

The matrix of choices

Choose the BLUE pill and wake up back in reality believing what you've always believed – that the old ways will get the job done. It's a beautiful prison, but a prison nonetheless. Take the RED pill and consent to a new, transformative future – one that is free from the enslaving control of 'the machine'. This is the dilemma contemplated by Neo in The Matrix – a film that has borrowed its binary choice metaphor from the classic Alice in Wonderland.

Encouragingly, very few organisations today are faced with such a stark choice. Most have taken the equivalent of the RED pill route and begun to roll out pilots and experiments to build up some semblance of DevOps experience. This has removed much of the institutional caution and uncertainty – itself a worthy goal. But what it hasn't told them is how deep the rabbit hole can go.

"Their journey into DevOps 'wonderland' is temporary and without lasting impact. It's an experience that has been enjoyed by the few and not by the many."

In truth, the RED pill route (DevOps) is not merely a model, a process or a methodology. It's something that needs to be woven into the values and cultural fabric of an organisation in the same way that some business entities know that they are a tech company – even though they don't sell technology per se. Employees and supply chain partners understand the organisation's identity, what they do and why they do it. They are not merely following process because that is easy to change, adapt, corrupt or ignore. They are 'programmed' to work in a connected, agile and mutually advantageous fashion to benefit the whole. They spend more time building and creating. They exert less effort patching and fixing. They are less distracted and more determined.

A great many DevOp Engineers – perhaps most – complain that they are drowning under the volume of end user analytics, bug fixes and patch updates. They point towards the sheer volume of work. The inefficient working methods. The inadequate technologies and tools. The lack of cross-team collaboration. The unrealistic deadlines. The ill-conceived KPIs. They are – in short – living a BLUE pill nightmare.

Yet, it should be noted that there's no mandate or higher power holding any of usto these counter-productive working practices. It's not a question of should we change, but one of how should do we do it and how to we do it at scale? Or, to put it more enticingly, how do we get everyone down the rabbit hole?

Keep going

03

Pockets of success

Industry analyst, Gartner, estimates that 70% of the IT market has adopted DevOps in some capacity.

Yet, other studies claim that only a quarter of firms have implemented test automation.

IDC report that 57% of businesses that have implemented DevOps have reached some form of DevOps Deadlock

This is why it's hard to quantify the true scale of DevOps adoption and whether it has kept up with the media hype. Everyindustry, every sub-sector and every enterprise is at a different stage of the journey. Does a pilot project equate to adoption? We'd argue not – particularly if the approach hasn't been systematically applied to the entire organisation.

For us, scalability is the true marker of success.

In reality, there are very few organisational barriers in the way of a full roll-out. Over the last 10 years, the tools available to software engineers and IT professionals have grown exponentially. There is also a growing body of evidence that DevOps is working well in businesses both large and small.

"There is also a growing body of evidence that DevOps is working well in businesses both large and small."

The inertia, therefore, appears to be two-fold. Firstly, the general lack of skills available across the industry. You can't just insource or outsource, which means that it has been historically difficult and slow to scale DevOps teams. Alongside that, most firms lack the organising principles to be able to re-train and re-tool their own workforce. Doing it in pockets is one thing, but it's not proven easy to replicate across geographical borders and different lines of business.

Delve deeper

04

Short-lived experiments

In theory, there's nothing wrong with DevOps experimentation. In fact, that's arguably where the majority of organisations are right now. A limited number of test beds with a tight-knit team of DevOps 'pioneers'. It provides a certain weight of evidence with primary data to support its value as a worthwhile exercise.

"Challenger brands will exploit every conceivable weakness and that usually means they invest in people, technology and process before you do."

However, if you stay in the experimentation zone (and most organisations do), you end up in a form of stalemate where you never really get beyond the pilots, trials, test beds and sandboxes. Crucially, you also tend to ignore the need for a formal roll-out plan with a global view and a supporting blueprint. The true value of DevOps remains untapped if there isn't a top-down approach – pushed at global CIO level down – with a carefully articulated vision of what it means to the business and how it will operate.

Conservative roll-out strategies will tend to carry more downside risk – compared to full-scale adoption – when you factor in the door that is being left open to new,agile competitors. One only has to look at the finance and banking sector to see what 'playing it safe' does to the old high-street oligopolies. Challenger brands will exploit every conceivable weakness, and that usually means they invest in people, technology and process before you do. The warning signs are already there for those merely drip feeding DevOps into their organisation. Treating it like just another IT project is to miss the point and miss the opportunity for something with a far greater upside.

Keep going

05

Greasing the wheels of innovation

A common misconception is that DevOps will somehow automatically improve the incidence of innovation within an organisation. In many cases, it will and does. But it's more about facilitating innovation rather than being a silver bullet in and of itself. Just because you adopt DevOps, doesn't mean you'll be innovative. But what you will buy is very much more time and headspace for your people to innovate.

Just because you adopt DevOps, doesn't mean you'll be innovative

Most firms are on the starting blocks when it comes to pushing projects from build to release faster. Their functional silos and linear design systems are at near-capacity or creaking point. In contrast, what DevOps and agile processes dois to reduce the feedback loop internally, so that products with value can be released faster.

The 'value' in that equation is in DevOps' ability to get the product right quicker, so it can be released into the wild quicker too. Engineering wise, it will be near perfect, with few (if any) bugs by virtue of following a continuous development and testing pathway. Then, of course, it's up to the end user to experience and report on the imperfections – either directly or via web/app analytics. It's their feedback that will drive iterative improvements as part of the continuous development loop, and ultimately determine whether the product has adequate utility.

This is a far more elegant and efficient way of deploying engineering resource, which has the dual benefit of removing the time spent spinning up products that simply don't work. After all, innovation is only useful if it has a purpose.

Keep going

06

Money can't buy you scale

It's an easy mistake to think that you can solve the scalability conundrum by simply buying-in the skills, or outsourcing it to a third party. Some have tried and a similar number have failed.

From a purely logistical standpoint, there simply isn't enough trained and experienced DevOps resource out there, irrespective of how deep your pockets are. The big systems integrators have the manpower for resource augmentation, but not necessarily in DevOps. The smaller, boutique consultancies have the DevOps skills, but not in sufficient quantities to service the entire market.

The availability of DevOps labour on the open market is also somewhat of a red herring – most enterprises shouldn't follow this strategy anyway. Indeed, most don't. We've seen, over the last few years, that the IT services industry has embraced change and committed to digital transformation in project form or in wholesale fashion. All are facing very different challenges and are at different stages, but most have recognised that they need to bring technology back in-house to deliver.

Where offshoring was once in vogue for IT cost savings, now almost every business accepts that they manifestly need more internal control over technology and product. The re-training and re-tooling of existing teams has become the de facto goal of the enterprise. It's the quickest and smartest play.

Delve deeper

07

Certainty of outcome

The DevOps 'enablement' of internal teams is quickly being accepted as the most prudent route to take – financially, culturally and in terms of scalability.

"By facilitating these practical engagements for one or more teams, highly trained squads can be spun up quickly and put to work on live projects during and post enablement."

Establish KPIs so that you can benchmark success

The method, advocated by those with a successful track record, is to work with a specialist outside party that can provide the organising principles for this ‘resource transformation’ to flourish. Coupled with this, they can also impart the technologies, tools and know-how that your people will need to use, run and operate the agile process.

These individuals, acting as a collective, ultimately become your internal change agents. They spread the DevOps gospel and act as the ‘poster boys’ of the organisation. That has true, almost immeasurable, value when you’re looking to scale up resource quickly to meet the needs of the business.

Your enablement partner should also work with you at the outset to establish KPIs so that you can benchmark success – be that in terms of application and delivery timescales, reduction of testing run time, annual savings, or any other metric. That will be satisfactory for most organisations, but you shouldn’t just stop there. Identify a consultancy partner that is confident in its process to the extent that they’ll work on a fixed outcome basis. By linking together your KPIs and ROI with your supplier’s remuneration, you’ll be in a great position to prosper.

Almost there!

08

The final word

Digital transformation, on a small or large scale, can be fraught with multiple risks and distractions.

If you’re looking to get past the DevOps deadlock in your organisation, don’t disappear down the rabbit hole without a companion that’s been there before and has the track-record to realise your aspirations. ECS Digital – building tomorrow’s enterprise today.

The Great DevOps Rabbit Hole

A guide to bringing everyone on the journey

Keep reading

We've come a long way... or have we?

Driven to distraction

The matrix of choices

Pockets of success

Short-lived experiments

Greasing the wheels of innovation

Money can't buy you scale

Certainty of outcome

The final word