Bring down the wall between Dev and Ops

Harold Petersen says no organisation developing software can now avoid the necessity of creating a DevOps capability.



On the Development side, Agile has assisted many organisation to ‘timebox’ deployable application releases. But if Development only focuses on pushing out application releases, you’re more than likely going to run into operational and security issues after deployment. You can’t just toss new initiatives ‘over the wall’ and hope for the best.

In the traditional mindset, ‘the wall’ is a deeply entrenched cultural divide. Development builds new software as fast as it can to meet business imperatives for speed to market, while Operations focuses on ‘keeping the lights on’.

Naturally, there is a tension between Development’s innovation and time focus versus Operations preference for minimal change – and for changes to be fully tested and approved when they do occur.

Today’s increasing need for speed – along with the ever-increasing impact on revenues and brand reputation of technology or security failures – means that accepting these two opposing cultures has become unsustainable. Both sides must change and accept a single culture that radiates throughout the IT organisation (and – situationally – to its service providers).

The value of DevOps is now proven

DevOps is a holistic capability to effect business technology change faster and more reliably. It’s the art (or, if you prefer, science) of matching rapid development delivery with the ability of operations to absorb it and effectively put it into production.

The plethora of technology and tools at our disposal give us the disruptive enablers to achieve rapid fault-free deployments. Which ultimately means quicker time-to-value for the business.

At this point it’s important to remind ourselves that tools and technology won’t achieve this on their own. People and culture are amongst the most important ingredients for DevOps to succeed.

A living, breathing DevOps culture involves not only greater flexibility, ‘Development’ thinking and involvement by the Operations side of IT, but also has the Development side becoming more aware of what it actually takes to make new products and services available to end users and customers.

To some extent: operations people take on a development mindset and development people an operations mindset. Both sides need to be incentivised and a genuine culture of care and collaboration needs to be built and fostered.

In its 2015 ‘State of DevOps Report’, Puppet Labs researched 5,000 companies and found that, compared to others, high performers are:

  1. Deploying software updates 30 times more frequently
  2. In a 200-times shorter timeframe
  3. With 60 times fewer failures and
  4. Recovering 168 times faster

Stand-out examples of rapid software deployment include:

  • Amazon: 23,000 per day
  • Google: 5,500 per day
  • Netflix: 500 per day

Rapid deployment of successful operational software enables rapid time to value for businesses and their customers.

While not every enterprise needs to match the astonishing rates of these ‘born-digitals’, successfully deploying in days or weeks would still be a transformative leap forward from those who traditionally deploy monthly or quarterly, like many corporates and federal government agencies.

Long deployment cycles cause significant frustration for the customer and the business, as all they see is a delay between feedback and the functionality changes going live. And that’s before the costs are factored, according to recent research:

“40% of effort dedicated to product development is pure or ‘unnecessary’ waste,
with 30% of the time charged to product development being spent in waiting.” ¹

There is no longer an excuse for delayed or stalled delivery of technology projects. It’s neither acceptable for a call centre to take days to roll-back operations after a failed deployment, nor commercially sensible for a bank to take months to stand up a project to develop, test and implement a minor competitive catch-up change or security enhancement to its online customer functionality.

What does DevOps entail?

The Phoenix Project ² - a book that has reached cult status as the pseudo-DevOps-bible – describes three ways (three principles underpinning best practice DevOps patterns):

The First Way: Systems Thinking (‘Left to Right’)

  • It is important to understand and embed organisational focus on the entire system, including true mastery of the flow from business requirements to
    • Ideas,
    • Sponsorship,
    • ‘Product’ development and embedding of the application ‘product’ along with operational requirements in the design and build towards a holistic ‘service’,
    • Test
    • Deployment of a ‘service’
    • Operational excellence and business value enablement of the ‘service’
  • DevOps removes waste (for example: waiting time, unnecessary steps or resource allocations), ‘work in progress’, limits queues and optimises flows
  • It calls for automation (for example: test and deployment) and codifying: carrying version control right through from development to testing and operations. It is best enabled by virtualising your ICT infrastructure, so that development and testing environments can flow easily into production
  • A DevOps solution increases the continuous flow of small-capacity software deployments by demanding that security and operational intelligence are built into design by Development teams, in collaboration with the Operations team.

Successful application of the First Way includes: not passing a known defect to downstream Work Centres, not allowing the objective of one silo (for example Dev only) to create degradation across the end-to-end system, always seeking to increase flow, and achieve understanding of the entire system.

The Second Way: Amplify (Right to Left) Feedback Loops across the system

Successful application includes continually understanding and responding to various stakeholder feedback, including co-developers, operations people, security officers, customers. Shortening and amplifying feedback loops across the entire system and embedding associated knowledge enables ‘continuous integration’, ‘continuous delivery’, ‘continuous deployment’ and ‘continuous operation’.

The Third Way: Continual Experimentation and Learning

DevOps calls for innovation and experimentation, which requires a culture that is willing and able to:

  • take risks and rapidly learn from failure; and
  • apply repetition and practice which is the path that leads to mastery.

Transforming an organisation towards successfully applying DevOps requires a holistic approach, whereby tools and technology are important enablers, but critical people and culture aspects are also factored.

In our experience it is recommended to start small (for example, one application), enhance the footprint iteratively and apply the DevOps principles themselves when establishing a DevOps capability within an organisation. Understand the entire system, apply feedback loops, experiment and learn.

What are the benefits?

The ultimate aim of DevOps is a continuous business enablement by frequent deployment of innovative IT services that allow continuous operations, without downtime. The promise is a rapid flow from requirements to value. This value is both to the business – in terms of new functionality delivered and speed to market – as well as IT systems reliability.

By building continuous feedback loops – beyond your development and testing environments and right into operations – you can deploy more rapidly, with less errors and learn fast to continually improve.

What DevOps is NOT

DevOps is not just a matter of investing in one of the readily available DevOps tools because, most of all, it calls for a culture of co-operation and collaboration – plus a lot of people skills to break down the divides between opposing cultures. It also involves a deep understanding of the value traditional IT processes, as well as the promise of newer, leaner processes.

You won’t transform your application delivery overnight, but it’s definitely time to look at how you can make speed it up and make it more flexible and responsive to business imperatives.

Related Reading

About the Author

Based in Canberra, Harold Petersen is Director Advisory for CSC Consulting, responsible for overseeing seven National Practices in a consulting force of over 300. 

Specialising in SIAM, PPM, ITIL, ICT Strategy & Governance implementation projects and programs, his 25+ years’ industry experience includes Director for UXC Consulting in Singapore and Malaysia, IT Service Delivery Manager for a major Australian bank and IT Service Executive for Asia Pacific accounts within a global outsourced services provider.

 ¹ Surveys by Lean Advance Initiative (LAI), Massachusetts Institute of Technology, 1993-2012

 ² The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr and George Spafford