Austin is famous for many things, but in the tech community South By Southwest (SXSW) has emerged as one of the go to events for technical innovation. SXSW is considered to be the launch pad for getting the word out on many great ideas. So, when I was asked to speak at IEEE DevOps Unleashed I was excited about the chance to connect with the Austin technical community and catch a little bit of the South By magic without having to deal with the crowds of the real event.
The IEEE CS DevOps symposium is a popular series of regional events that bring people together to talk about the DevOps movement. At the Austin event, I joined Bernard Golden (@bernardgolden), VP of Strategy at Active State, and Bernie Coyne (@berniecoyne) DevOps evangelist at IBM. Both shared very interesting views on the importance, challenges and potential approaches to DevOps. What was truly interesting about the talks, in my opinion, were the things not being talked about, or only mentioned in passing. For many organizations, DevOps is associated with release management and is squarely focused on the problem of reducing the overhead of software releases. And, although it is true for many organizations that the relationship between development and operations most visibly falls apart during the release process, the actual disconnect is much broader.
This holistic definition of DevOps has emerged in part because vendors want to associate their products with a great marketing campaign and industrial movement. But it has also emerged because the breakage between the two groups exists in many places. Each speaker approached this problem from their perspective. Bernard described three areas that must change in order to enable DevOps:
- Business Agility – the business side of rapid delivery
- Technical Innovation – the development practices and approaches that are affected, and
- Infrastructure choice – the realities of DevOps on the stack and architecture used.
Only when you consider all of these areas do you create the foundation necessary for DevOps. Release automation was only mentioned as one aspect of Technical Innovation. Important, yes, but not the only focus area.
Bernie provided an overview of the IBM approach to DevOps–mapping the need for DevOps in an organization that is competing with much smaller, nimble software companies. He described the breadth of IBM offerings and how IBM strives for using a DevOps approach in the context of a company that has both the weight of many years of process and the heft of 400K people. Bernie highlighted the importance of an incremental approach–one that focuses first on the practice areas that are the most broken, slowly adopting the changes that make sense. He described DevOps not as standard pattern that every organization can just blindly follow, but rather a series of recipes that will be different for each adoption model. If you reviewed IBM, you would find that very different processes and practices are being employed, but all of them are striving to break down the barriers between operations and engineering. 
Both Bernie and Bernard painted holistic, complete views of the transformation necessary to delivery software faster and reduce waste. I carried on this theme with the forgotten side of DevOps, concentrating on the lifecycle aspects of DevOps, and how we need to manage both the assets (code, infrastructure) and the work in a consistent, automated, and measured way. Only by connecting or automating both the asset and artifact approaches does an organization effectively break down the barriers that disconnect the lifecycle and create waste.
In the panel section of the event, there were many interesting questions, including: how can you apply these principles to operating systems or hardware development, and should you treat infrastructure the same way you treat code? A theme also emerged about objectives and measurement–without clear consistent shared goals and an effective way of measuring them you will never drive change in your organization. Bernard described shared metrics as the cornerstone of cultural change. And it became clear that if you measure development for change and operations for stability change is not only hard to execute on, but will never become embedded within an organization.
