An IT perspective of DevOps - Part 1: What does DevOps mean to me?
Due to a reorganization, in 2012 my team merged with our location's IT department and a central build and test team for one of the product areas to form a single organization called DevOps Infrastructure (DOI). At that time I had little understanding of the term DevOps, although Infrastructure did make sense since that is what IT is about. Today it is clear that what I do is more than just IT, and what our stakeholders want is also more than just IT.
In this series of posts I'll discuss various elements of DevOps from an IT viewpoint, starting off with “What does DevOps mean to me?”
Ten years ago my definition of development would have been the part of Collaborative Lifecycle Management (CLM), which relates to design, code and unit tests. Aspects such as requirements management or system testing were not included. Today I look at the definition in organizational terms, so development to me represents all the aspects of delivery wholly owned by that organization in order to deliver a product, solution or some kind of value. These aspects include code, testing and requirements management, along with service and support functions.
Operations comprises the components (of software delivery in my case) that have been pulled from the development organization, centralized and offered as a service back to development. This has for some time included IT and all the underlying infrastructure. For my department (DOI) it also includes build, test and release engineering disciplines, which are provided to multiple development organizations in a more cost effective way. However operations doesn't stop there. For example, a number of the products supported by my team need to be translated, while others require DOI deployment and packaging capability to make the product ready for market.
Extending this further, you could even regard some client roles as part of operations. If you think about it users who subscribe to beta programs are becoming part of a DevOps relationship, and when the product is available they will often offer feedback about their experience of installation and use through forums and problems logged.
Development plus operations
My initial thoughts about DevOps comprised a union of two separate teams with orthogonal aims. Development was driven by release dates while operations (primarily IT) was focused upon its areas of competency such as capacity planning, audit readiness and quality of service. Recognizing that a symbiotic relationship exists between the two teams meant that we (development and operations) could collaborate on how to make the best of this relationship. After all if we could understand each other's viewpoint we would be able to deliver a better overall result.
How many times have IT departments been requested by development to provide their specification of servers for a requirement that could be satisfied by provisioned servers? From an IT viewpoint it seemed that we were there to serve development teams (which we are) but without the recognition of the skills and value we provide. I'm sure the development teams had a similar viewpoint and probably thought they were helping IT by providing the specifications of the servers they wanted. It was obvious that closer working and better communication would lead to a better outcome.
After 18 months since the reorganization, my view of DevOps has changed. While some would say DevOps is about faster time to feedback, continuous delivery or driving automation through the cloud, for me it is the following:
“DevOps is the recognition of all roles, resources and services required to achieve a common goal.”
It's only when you can recognize all contributors and the value they bring to a commonly defined goal that you have a chance to succeed with delivering faster return on investment to your customers.
I'd be fascinated to hear your thoughts on DevOps and its meaning to you. To continue the conversation, leave a comment here or send me a tweet @jao1313.