DevOps and the Art of IT Operations

By Michael Hugos


Hugos is a former CIO and principal at Center for Systems Innovation. He is the author of Business in the Cloud, published by Wiley; and Enterprise Games, published by O’Reilly. His articles also appear in CIO, Computerworld, and other leading IT publications.


Business lives in an online, real-time world. It has to respond online and in real-time too. Taking months or years to respond to changing markets just won’t cut it anymore. That goes double for responding with business models that aren’t online and mobile savvy. Changes and enhancements to applications are the new reality today, not just an occasional event. Close communication and collaboration between application development teams and IT operations teams is crucial for success. And that’s what DevOps is all about.


DevOps builds on what Agile started. By using Agile approaches, development teams can build new applications and add new features in short iterations. But if IT operations people can’t roll that new software into production as quickly as it’s developed, what good does it do? Enter DevOps, which is a response to the growing interdependence between software development and IT operations.


Traditionally, development groups create software, hand it off to operations groups, who then roll it into production. This is hopelessly out of touch with current business and IT realities. Not only do companies need to respond to continuous changes in their markets, IT groups also need to respond to continuous change in the technology used to host and operate business applications. This continuous change in IT infrastructure is driven by the spread of cloud computing in all its forms (IaaS, PaaS, SaaS, and so on), along with widespread use of hardware virtualization and data center automation.


Indeed, the growth of cloud computing, hardware virtualization, and automation of data centers means that IT infrastructure itself is transitioning from hardware to software. That means people who operate this infrastructure are becoming programmers and developers in their own right, because they design and create software that runs their organizations’ IT infrastructure. As the boundaries between applications and infrastructure blur, those who develop apps and those who operate infrastructure have to find ways to collaborate more closely and effectively.


DevOps integrates and aligns the functions of these two groups. While DevOps is very much a work in progress, there is already enough experience in the field to identify the outlines of new practices that significantly promote the collaboration that’s needed. Those practices can be grouped into three broad categories:



  • 1. Increased volume and frequency of communications between developers and operations people

  • 2. Inclusion of IT operations specialists on application development teams

  • 3. Automation of routine activities involved in quality assurance testing and moving software from development into production

Increased communications is a basic requirement for better collaboration. In particular, experience shows that visual communication techniques-such as process flow charts, project timelines, and IT architecture diagrams-are the best way to facilitate understanding of the issues. So, the more information about new applications that development groups can provide to operations groups, the better the operations groups can prepare to receive those applications and roll them into production.


Effective communication is always a two-way street. Including IT operations specialists on development teams can result in better decisions about the IT architecture to use for given applications. It also drives better decisions about how to write application code, so as to make the best use of the selected IT architecture. Developers need to understand business requirements and be experts in the programming platforms they work with. They can’t be expected to keep up with rapid rates of change in IT architecture. But development teams can get that additional capability when they integrate operations specialists with their developers.


When development teams deliver new applications designed to run well on the IT architectures used by companies in their data centers and in their cloud platforms, the challenge is to smoothly roll the applications into production. That means automation of routine and repetitive tasks; such as quality assurance testing, code migration, and rollout and restore procedures. The more these routine tasks are automated, the fewer chances there are for human errors to gum things up. Automation also frees up time for people to work together on the higher value, non-routine tasks that are crucial to IT operations.


Agile methods are changing the way organizations develop application systems. And now (some would say “finally!”) DevOps is changing how companies operate their IT infrastructures. In spite of all these changes, the goal remains the same: to quickly deliver the reliable applications and business models companies need to succeed in the real-time world.


To learn more about the future of these evolving IT trends, look for me at CA World 2013 where I’ll be participating in a Luminaries Live! session.  The Luminaries Live! program gives industry visionaries 5 minutes each to present their thoughts on new ways that technology can drive innovation. It just might change the way you see the future of IT. Hope to see you there!


 

The following two tabs change content below.

Guest Contributor

New voices, thoughts and insights. This CA Technologies blog post features content written by an outside expert to bring a fresh perspective to our blog. Guest commentary is by invitation only.

Latest posts by Guest Contributor (see all)

This article has 2 comments

  1. My product management training and experience, coupled with how we setup and ran EDS data centers around a ‘find a problem/opportunity’ – make it ‘go away/happen’ resonates here and reminds me of the common sense behind DevOps. Elsewhere I hear a few call for a merger of DevOps and ITSM into a new common acronym.

    Frankly its all symptomatic of us allowing to be led by those who have never worked a day as a manager within an IT organization with hiring and firing responsibility. DevOps is a reality check for those of us who consult. I believe many organizations do this, or try to – but to make it happen you really need to respect the fact that the entire IT organization must work as a unit in serving the business, rather than be operated in silos and fiefdoms.

    Some of the framework chatter encourages silos, promotes unnecessary layers of ‘management’ and supervision, and trumpets an implausible ‘service lifecycle’. In the end, you will need an IT organization driven by management imperatives, measured through two lenses – operational (inside-out) excellence and service (outside-in) excellence, working around a common continuous improvement program that leverages agile thinking…. well thats my 2c and what I help folks realize and do…

  2. My product management training and experience, coupled with how we setup and ran EDS data centers around a ‘find a problem/opportunity’ – make it ‘go away/happen’ resonates here and reminds me of the common sense behind DevOps. Elsewhere I hear a few call for a merger of DevOps and ITSM into a new common acronym.

    Frankly its all symptomatic of us allowing to be led by those who have never worked a day as a manager within an IT organization with hiring and firing responsibility. DevOps is a reality check for those of us who consult. I believe many organizations do this, or try to – but to make it happen you really need to respect the fact that the entire IT organization must work as a unit in serving the business, rather than be operated in silos and fiefdoms.

    Some of the framework chatter encourages silos, promotes unnecessary layers of ‘management’ and supervision, and trumpets an implausible ‘service lifecycle’. In the end, you will need an IT organization driven by management imperatives, measured through two lenses – operational (inside-out) excellence and service (outside-in) excellence, working around a common continuous improvement program that leverages agile thinking…. well thats my 2c and what I help folks realize and do…

Leave a Reply