DevOps for IT Departments
DevOps started as a nimble development method used by startups and companies that have software based products. Fortune 500 IT Departments have been trying to adopt the practice ever since DevOps was first proposed at the Agile Development Conference in 2008. The “agile infrastructure” as it was first named, was the first incarnation of the idea that Agile Development was not enough; that cross-department cooperation and integration is necessary to fully realize the product delivery benefits promised by using an Agile model. At a high level, DevOps integrates the disciplines of development (software engineering), quality assurance, and operations.
It is important to note that Agile and DevOps are similar, but are two different concepts that should not be confused. A software engineering organization can have an Agile delivery model without the corresponding move to DevOps. DevOps has the additional infrastructure components along with the cultural and organizational change management (OCM) requirements necessary in any major cross-team initiative.
The ultimate goal of software delivery organizations is to provide useful product releases faster and with higher overall quality. As Forrester and many others have reported, DevOps is used by organizations to speed execution, boost staff productivity, and increase service quality [1].
Successful Implementations of DevOps in IT
Fortune 500 IT organizations have taken note of, and attempted to emulate, software-based product companies like Amazon, Netflix, and Google that have successfully implemented a DevOps model to gain the benefits sited. With some notable exceptions in the retail industry (Walmart, Target, and Nordstrum), IT organizations have not been overly successful in their attempts to implement a DevOps delivery model. Which begs the question of why has IT had such a mixed track record in DevOps implementations. The challenges in moving to DevOps for large IT organizations are largely due to three main areas:
Suitability of applications and the supported business units – the IT portfolio of applications and the business units they support are not equally suited to the Agile/DevOps model.
Lack of OCM – little to no attention being paid to the non-technical, human aspects that this type of change involves.
Suitability of the workforce – As a general rule the majority IT staff has not come from startups or software-based companies where DevOps has taken hold and as such lack the formal and informal training necessary to be successful.
Suitability of Applications and the Supported Business Units
All too often, IT leaders do not review their application portfolio to determine the apps that are most suitable to an Agile DevOps model. We have seen organizations attempt to implement DevOps for applications, user populations and business processes that are not able to absorb the velocity of change. For example, one client implemented an Agile/DevOps model for an application that was used by thousands of customer support reps. A high-velocity release schedule could not be accommodated by the customer care organization and the releases queued up, leading to wasted effort, bug fixes that spanned pending releases, increased cost, lower quality, no improvement in feature delivery to the business, and frustration for IT as well as the business. Applications and business users that can ingest frequent changes are more suitable candidates for DevOps.
Application suitability to DevOps includes how those applications have been architected. Loosely coupled service-oriented applications are better candidates for DevOps than monolithic systems. Often times, IT systems were not architected in a way that facilitates a more agile DevOps approach leading to failure in implementations. Knowing your user base and your application portfolio is an absolute requirement for DevOps.
Lack of OCM:
The split between the development and operations areas in IT has a long history. The two organizations have traditionally been run separately and are rewarded for very different outcomes. Software development has been asked to increase responsiveness, deliver products quickly, and create an endless stream of new features. Conversely, IT operations usually is asked to keep systems up and running while striving for “five-nines” – to do this they have had to carefully manage, and to some extent limit, change to the operating environments. The resulting cultural differences between the two groups has created an “us versus them” mentality that needs to be addressed if a DevOps model is implemented. You cannot underestimate the time and effort required to make these cultural changes – a strong organizational change management and training effort for technical and business staff members is the sine qua non to a successful DevOps implementation.
Suitability of the Workforce
The suitability of the IT staff is very much related to (but not to be conflated with) the OCM issue just discussed. Often times the IT staff in operations, development, and quality assurance have experience in their IT specialty and in the business domain in which they operate, but they do not usually have hands-on experience in new techniques that have been pioneered outside of the IT discipline. To counter this, IT leaders will typically hire a person from the outside with DevOps and Agile experience to “lead this effort” while simultaneously sending staff to a few DevOps training sessions. In every situation I have encountered the external expert is situated in the Development area – this exacerbates the divide between Operations, Quality Assurance, and Development. DevOps experts (you will need more than one good hire) need to be located in all three areas and company leaders must look for ways to eliminate barriers between departments.
Understanding your staff’s strengths and weaknesses and developing a realistic staffing plan to address these issues is necessary for success. Due to the sensitive and political nature of this endeavor, it is better to retain an unbiased outside opinion for this analysis.
In Closing – DevOps is Possible for IT
Successfully implementing DevOps in IT is possible, but not a trivial effort. It takes an honest assessment of your current situation, development of a realistic business case, and a strong implementation plan that addresses the major challenges discussed. In a future post, we will discuss implementing Agile and DevOps in an outsourced environment – introducing a new set of challenges.
[1] Amy DeMartine and Kurt Bittner, The Seven Habits of Highly Effective DevOps. Forrester Report October 2014 pg.4.