Skip to main content

Building a DevOps culture within your organisation

(Image credit: Image Credit: Profit_Image / Shutterstock)

DevOps is a term which is being currently broadcast a lot within the IT industry. This blog post tries to define what DevOps is and its benefits to your organisation. Sam Guckenheimer at Microsoft defines the DevOps term1:

DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.

From this definition, we can see DevOps is a way of working; it’s how we can work together to deliver change. The Model T Ford2 was generally regarded as the first affordable motor vehicle. The Ford motor company were the first company to build each car on an assembly line. This was an efficient, repeatable process. Workers built each motor vehicle by using their own individual skillsets; they were working in union as the car moved along the assembly line.

As you can see, the IT industry is learning from other industries. Proven methods are being applied to IT practices to develop, improve and deliver value. Using DevOps practices companies can deploy, experiment, learn at a very fast pace.

Let’s move away from DevOps for a moment and think about change within the IT industry.In 1969 four computers3 were linked together, this evolved to become the Internet. Gartner4 predicts there will be 25 billion Internet connected devices by 2021. Cloud computing has provided organisations with a vast array of on-demand scalable services. Each major Cloud provider routinely publishes major announcements adding further capabilities to their portfolio. Future generations may not need to take a driving test, as we move towards fully automatous vehicles. 

We rarely look back within the technology industry. There is such a demand for innovation to improve existing business processes. Constant refinement, with an ever-increasing appetite for change.

The only way IT departments can keep a pace with this demand for change is to work as a team. That seems an obvious statement, but in the past IT team members have differing goals and objectives, these can sometimes conflict. 

RoeGoals and objectives
Operations Reliability and issue resolution
Development Implementing new software features
Project Management Monitoring and reporting progress
Quality Assurance Test strategies to ensure software is well received by end user
IT Security Minimising the risk of data loss

In the IT industry we seem to love acronyms and buzzwords. Each of the above roles have their own set of these acronyms and buzz words. This makes discussion across teams difficult. Traditionally, work packages are handed across from team to team in a silo mentality, which slows down the pace of change and work cannot be completed in parallel. Making sure the right people are available at the right time in a project can become very difficult.

In DevOps everyone has shared responsibility for these goals and objectives. We do this by implementing a common language between all roles. We can now start to work together and work in parallel, deploying small incremental changes into production. 

This change happens as the IT team all make changes using code, this becomes the common language which cuts away the barriers between skillsets.

At the top of the blog post we mentioned the car industry. Now let’s talk about another industry, this time the newspaper industry. A newspaper will employ a series of expert specialist journalists to produce quality content to sell newspapers. A business journalist will understand the mechanics of the stock exchange, whilst a sport journalist will be happy writing about the latest sports event. Although each journalist has differing specialist knowledge, they both add content to the newspaper. This content is reviewed by the editor and when approved, the article is published.

There are similarities between the newspaper process and the DevOps build process. In DevOps, code is commonly stored in a version control system. All IT team members can and are encouraged to make their incremental code changes into this version control system. The code goes through an approval system, if approved the changes are added to the next release. In DevOps, a release pipeline contains all the steps required to build, test, configure and deploy a complete environment. We can rapidly deploy, complete test, pre-production and production environments. This allows teams to make changes quickly and safely in a controlled fashion.

Many people feel DevOps isn’t right for them, as they do not have a development team. A common question is, how can we converge operations with development when we do not have a development team?

We would reply, a development team isn’t a pre-requisite when adopting DevOps. Many IT teams purchase off-the-shelf packages, which are linked together to create an environment which supports critical business processes. These environments have been built over many years, by many hands. These layers of complexity restrict change.  DevOps practices unpicks all this complexity. The code contains the full story. From small business to enterprises, we all need to deliver change and value into systems which are critical to the smooth running of an organisation. 

In this article, we are not going to talk about the tools used to promote a DevOps culture. We will leave this topic for the next blog post. However, you can see DevOps requires all team members to change their way of working. This may seem a little daunting, as producing code is difficult. Do not worry - most DevOps practices require code to be written in a declarative format. Many IT people currently use a configuration file to change the way an application looks and behaves. DevOps takes this configuration file to another level. Using a simple to learn coding language we can declare how to:

  • Build the supporting application infrastructure
  • Install any dependencies to allow the application to function
  • Install the application
  • Configure the application to fit your organisation’s requirements

In summary here is a list to highlight a few key benefits. Each point could be a blog post in its own right:

  • No need to apply changes out of hours – Changes will go through a repeatable, established controlled release process.
  • Fear of change is removed – We can rapidly roll back or roll forward to remediate unexpected change behaviour.
  • Remove autonomous working – Individual workloads are not stretched, many IT workers work long hours. DevOps practices remove silos, there is also a no blame attitude within a DevOps culture. The team are all mutually accountable.
  • Remove autonomous working – Individual workloads are not stretched, many IT workers work long hours. DevOps practices remove silos, there is also a no blame attitude within a DevOps culture. The team are all mutually accountable.
  • Customer value – The whole team, work towards a common goal to deliver customer-value.

As this is a first in a series of blog posts, we will not go into further details here. The next planned blog post will describe some of tools used to support a DevOps culture. In part three of the series we will build upon the benefit list introduced in this blog post.

By now you can probably tell, Sol-Tec are big fans of the DevOps culture. In the last year we have transformed our working practices. We use DevOps to deliver high quality solutions, in a predictable timeframe, using efficient processes to our customers. We are very proud of our Microsoft DevOps Gold partner status. 

Barry Sharpen, Azure Consultant, Sol-Tec