DevOps: Can we automate our way to Business and IT Alignment?

devlovesopsHow come some organizations appear to move at blistering pace, constantly releasing new software and services, outsmarting competitors, growing revenue, and delighting their customers? How come they seem to get IT right? 

Or are we asking the wrong question; could it be that moving at such pace enables them to get IT right? Perhaps moving at this pace provides the environment that allows the business and IT to align themselves behind a common set of well understood objectives, and from there achieve great things.

If this hypothesis is true then we should see examples of companies that have ‘pace combined with quality’ built right into their culture, and where the business is enabled to dictate the pace of change rather than being constrained by IT.

Take for example Flickr. Flickr has a business objective of releasing code to their production systems 10 times per day. To many this seems like madness – a madness that could only be accomplished by the most gifted engineers you might think. But that’s not the case at Flickr, or at any of the other organizations that have since adopted Flickr’s best practices. In fact it can only really be achieved by a change of culture – a change in how the traditional Development and IT Ops silos work with each other and with the rest of the business.

In 2000, John Allspaw was working at Flickr and delivered this presentation to the Velocity conference. This presentation is seen by many as one of the catalysts for a movement now called DevOps. It describes the tools, methods, and culture change that Flickr used to achieve their ‘mad’ goal. And I think DevOps is something which organizations should seriously look at if they want to ‘run with the herd’.

What is DevOps?

DevOps is a cultural change in the IT environment – we cannot define it as a specific process or methodology. By all accounts it was born out of the adoption of the agile methodology coupled with the dynamic needs of modern IT – something that was termed “agile infrastructure” by the early pioneers. However, it is a much larger concept than any single SDLC process can define.

The 4 major characteristics of DevOps are as follows:

  • Breakdown the gap between development teams (which orient themselves to value-added changes) and IT operations (which are geared more towards reliability, availability, and security).
  • Process automation that promotes quality, transparency, continual improvement and frequent deployment.
  • Alignment of both development and operations to the rapidly shifting needs of their business, calling for IT professionals to carry greater responsibility for understanding the business environment.
  • Application of systems and lean thinking to remove wastage and reduce the lead time from the inception of an idea through to the deployment of working code.

Agile development did in fact pave the way for this mind-set through its emphasis on small changes, mitigated risk through quick cycles and constant stakeholder feedback. However, DevOps takes the mentality outside of the development space and helps organisations to view their entire business model in terms of integrated IT.

Real-World Business Results

It turns out that this concept has led to verifiable success for many organisations. According to a current CA Technologies survey, firms that practice DevOps have seen “17 to 23 percent improvement in business in the form of increased revenue, faster time-to-market, improved competitive positioning and enhanced customer experience.” These results have increased corporate interest in adopting a DevOps approach. We may be able to attribute this to the fact that the various silos between development, operations, test, and management have traditionally lowered the ability for IT to align itself with business objectives.

As MomentumIT CEO Jeff Schneider has related, IT executives have had to resolve the diverging objectives of software development leads and IT operations managers. Developers have focused on problems such as performance and scalability. However these issues must be handled concurrently with more fundamental and earth-bound concerns such as system patching and backup. Furthermore, developers do not want to be hamstrung by IT processes, such as submitting tickets in order to acquire software or system permissions.

The DevOps Difference at Flickr

John Allspaw’s presentation provides great detail about how the DevOps philosophy came into play to support the company’s business requirement of 10 deployments per day. With high visibility and over 40,000 photos uploaded per second, there are major consequences if the services do not operate smoothly.

Teams broke down the dev/operations gap with the following practices:

  • automated infrastructure
  • automated testing
  • one step build/deployments
  • rapid feedback between teams
  • sharing meaningful metrics

Aside from these technical details, the mind-set change is what ultimately made DevOps successful. The effort came together as teams realised that their jobs are not to maintain code, nor maintain machines, but to “enable the business.” In the same way that QA teams have become embedded in software development teams, IT Operations teams need to work much more closely with their developer counterparts.

Development teams could no longer throw their software over the wall to QA and IT Ops – they were responsible for shepherding it right through to deployment, and with that came an increasing responsibility for the code quality. By automating many of the stages of test (unit, integration, and GUI), developers received feedback on the quality of their code very quickly and could kill bugs as early as possible in the pipeline – no more waiting for QA or endless QA-Test-Fix-Deploy cycles.

There are 5 important takeaways from the Flickr story:

  1. The process enabled 10 deployments a day. It did not enforce it – just because you can doesn’t mean you have to release to production. The deployment bottleneck was removed through automation, allowing the business to dictate the pace of change, rather than constraints within the IT operations team.
  2. The risk associated with deployment is reduced. Since deployment is automated there is far less room for human error. Deployment is practiced daily and so errors are reduced and reliability increased over time. Also small releases have less ‘moving parts’ and less sources of potential failure. So even if something does go wrong it is easily diagnosed and fixed.
  3. An organisation can react quickly to its competition and to its users’ requests. Since there is little or no overhead to a release, small releases and improvements can be easily made. When there is a relatively large overhead associated with releasing software, the organisation naturally tries to bundle a number of changes in a single release to increase productivity.
  4. Frequent releases and improvements delight and engage customers. It becomes possible to be super-responsive and to try new things and run experiments.
  5. Releases are tied to business needs and not IT constraints. The business starts to dictate the pace of change and decides when they want to release a new feature. The business becomes much more confident in ITs’ ability to deliver. For example, the business knows that if it can’t get a feature into today’s release, there will be another release very soon.

If you are interested in finding out more about DevOps then pick up the book The Phoenix Project and give it a read.  The book is written in the style of Eliyahu M. Goldratt’s The Goal – really a business book written as a novel. The Phoenix Project tells the story of the hapless IT guy who finds himself promoted and is put in charge of a completely dysfunctional IT division. Through the story we see how over time he applies systems and lean thinking and eventually builds the DevOps culture into the business, enabling the business to reach its goals.

If you would like to dig deeper into DevOps, we’ve gathered some useful sources that you might find interesting

What do you think? Do you see issues in the handover between software development teams and your IT operations and is deployment a real pain? How could you benefit from being able to deploy at the push of button? As a test, ask yourself or your team “How long would it take to deploy a change that involves just one single line of code?”

At Daysha we have a range of software deployment and support services to help you implement the DevOps philosophy. Please contact us to find out more.

Tags

Leave a Reply

Your email address will not be published.