This is the first in a series of blogs about various enterprise DevOps topics. The series is co-authored by Nigel Willie, DevOps practitioner and Sacha Labourey, CEO, CloudBees.
Let us assume that if you are reading this blog you are either interested in, or in the process of, rolling out a DevOps initiative across an enterprise. Further, if that is the case, you wish to successfully embed DevOps into the DNA of your enterprise and leave a legacy. In our view, those companies who have made a success of DevOps have recognized it involves cultural change across the organization and not merely the latest in a line of initiatives driven from Head Office.
That said, your management will have objectives and a reward structure in place and it is critical you understand this if you are to be successful in the short term. You could consider delivering any transformational program as being similar to sailing into the wind. You can’t head straight to your destination but must tack. You need to know your ultimate destination, but you also need to know that which needs to be delivered for your key stakeholders - which may not strictly be strategic.
We should also state that we have a very simple personal definition of DevOps and it is focused on outcomes, not capabilities. Successful DevOps provides the ability to deliver discrete technical artifacts rapidly to production to drive value to your business.
Nigel will now wind the clock back over twenty years to his early days in the industry:
When I started work, there was a small team of us sitting together around a bank of desks. We had someone who represented the business, somebody who wrote the screens (albeit old 3270 green screens for branch staff), a developer, an individual who wrote the functional specifications, someone who wrote the technical design specifications and a tester. The individual writing the screens would ask the business representative to wander round the desk and check if the green screen looked how they wanted it to look.
Before any of us knew the correct taxonomy, we exhibited several of the characteristics of Agile and DevOps, albeit with none of the automation. In addition, the assets we delivered were more monolithic and cadence was far lower than would be acceptable today.
So, what happened?
Business engagement (or lack thereof): A colleague once said to me, “First the business moved us into the basement, then into another building, then another city and finally another continent.” In many companies, IT lost contact with our business and became a cost center that delivered solutions rather than being a close partner. It is critical that those of us in technology become better at communicating with our business and understand what the asset we are accountable for does in their eyes. I see far too many technologists with little business contextual awareness.
Silo- ization : Within larger enterprises, there was a move to mono-skilled pools. A large pool of developers, a pool of testers, a pool of business analysts, a pool of DBA’s and so forth. This moved us away from a product to a project approach, with a pool of labor brought together for a specific task. I lived through this process and know that it was driven by IT itself, or at least by CFO’s within the IT part of the organization. The rationale came from the idea that product teams sometimes had downtime when demand for new features was not pressing. By creating pools of labor, the IT organization could react more rapidly to business priorities.
Why should you care about the history above?
“Those who don’t know history are doomed to repeat it” – Edmund Burke
It is our belief that anybody commencing a DevOps initiative should be aware of why similar ways of working previously were abandoned and take steps to ensure those challenges are recognized and mitigated against as the DevOps program gears up. It is imperative that the business is fully engaged and committed as key stakeholders in the value that can be gained from DevOps. You need to avoid the view of IT being a cost and ensure that you can clearly articulate value. Ideally, your business should start to articulate the value they see from DevOps to others.
Additionally, if your company previously moved into silos, an awareness of the rationale behind this is crucial. For example, look to put process in place to identify when business demand for product enhancements starts to increase or decrease to ensure you avoid the perception that resources are not being optimized.
In short, we would recommend before you start to transform your organization you must:
Understand what outcomes you are trying to achieve.
Understand what objectives your board has, and identify which short-term objectives add risk to the long-term strategy.
Understand why your company looks like it does now, how you got here and what motivators led to the current culture and environment.
We intend to look at some of the other challenges and learning points in future posts.
Follow the Enterprise DevOps blog series from Sacha and Nigel
Enterprise DevOps: An Introduction (this post)
Enterprise DevOps: I Wouldn't Start from Here: Understand Your DevOps Starting Point
Enterprise DevOps: The Peoples' Front of Judea, or Don't Sweat the Small Stuff
Enterprise DevOps: 13 Principles of Meaningful Metrics Measurement, Part 1
Enterprise DevOps: 4 Further Considerations for Metrics Measurement, Part 2
About the Authors
Nigel Willie
With over 20 years’ experience working in IT for one of the world’s largest financial institutions, Nigel has experience managing and delivering global transformation programs. Starting his career as a developer, Nigel’s most recent role was to deliver cross-platform DevOps automation capabilities to the enterprise. From his experience, he understands many of the challenges and mistakes involved in a DevOps transformation; indeed, he claims to have made most of the mistakes himself.
Nigel has also had the good fortune to work with a lot of highly skilled individuals, both as colleagues and across the industry. He is attempting to share some of his personal observations and thoughts in the hope they will be of value to others. Nigel is a great believer that every initiative is individual and any observations he makes are intended as principles or guidelines, not rules.
Sacha Labourey
Sacha is a native of Switzerland and graduated in 1999 from EPFL. While at EPFL, he started his first consulting business - Cogito Informatique. In 2001, he joined Marc Fleury’s JBoss project as a core contributor and implemented JBoss’ original clustering features. Sacha went on to become GM for JBoss Europe, leading the strategy and helping to recruit the partners that fueled the company’s growth in the region. In 2005, he was appointed CTO, overseeing all of JBoss engineering.
In June 2006, JBoss was acquired by Red Hat (NYSE :RHT ). As CTO, Sacha played a crucial role in integrating and productizing the JBoss software with Red Hat offerings. In 2007, Sacha became co-General Manager of Red Hat’s middleware division. He left Red Hat in 2009 and founded CloudBees in March 2010. Follow Sacha on Twitter .