This is a short series of three also fairly concise articles exploring what is meant by the emerging and ever popular term DevOps. In this first post we look at DevOps as a culture.
What is DevOps? A culture? Yes.
First and foremost there is no exact definition of DevOps, there are indeed many views though. However there is general agreement across the IT industry that DevOps is as much a culture as it is a practice/method/concept and software engineering competency.
The closest formal description of DevOps as a culture has been described rather nicely by Gene Kim in his article The Three Ways: The Principles Underpinning DevOps, in short, the Three Ways are defined as:
- The First Way: Systems Thinking
- The Second Way: Amplify Feedback Loops
- The Third Way: Culture of Continual Experimentation And Learning
The above are fantastic high-level concepts and I believe a very effective way for management to champion a “DevOps” culture throughout an organization. There is in fact a very well written novel called The Phoenix Project which provides some thought provoking analogies between IT software delivery and manufacturing engineering, heavily referencing ‘The Three Ways’, I have found it spookily relevant on many occasions when engaging in new client relationships. A short review can be found here
We want DevOps!
Fostering the DevOps culture in an existing organization can be a significant challenge, not least when the organization has potentially incorrectly identified a direct need for DevOps resource (read Engineers) without aligning that to tangible business objectives. Whether it is ‘competitive advantage’, ‘quicker return on investment’ or ‘greater profit’ it is imperative that those business level objectives are identified and bought in to and championed from the CEO/MD down.
“The culture is in itself imperative, as without it, even the most efficient processes and impressive tools can ultimately be useless without the people required to execute and continuously improve them.”1
Once the common business objectives are identified and a shortfall in the culture to deliver on those is acknowledged, it is time to facilitate growing the culture, a number of ways this can be achieved is by…
- Encouraging collaboration by appointing both technical and non-technical ‘DevOps evangelists’. Evangelists should utilize multiple channels, both internally and externally, such as: technical and non-technical blogging that raise the profile of the Organization within the technical community, Etsy, Flickr and Facebook have fantastic examples of this approach.
- Fostering collaboration and communication internally and within team and organization level meetings, arranging frequent internal events to encourage experimentation and learning (think hackathons and/or 20% time) as well as attending and hosting community meetups.
- Begin reviewing each teams application lifecycle (ALM), define the boundaries of responsibility within the application lifecycle to enable the organization to ship quality software and maintain/satisfy governance. Identify those areas that are performing poorly and introducing delays, errors or inefficiency and target these (The Second way). Where this is being done well already, learn from it (The Second and Third ways). This should be a joint responsibility of the ‘Centre of Excellence’, management and the ‘DevOps evangelists’.
- In large organizations a ‘Centre of Excellence’ that realises ‘DevOps as an engineering competency’ can be beneficial, complementing existing skills with experienced DevOps engineers capable of delivering, mentoring staff and championing the ‘Centre of Excellence’ across team boundaries. The ‘Centre of Excellence’ must have DevOps as a culture at its core and must not simply be an additional engineering team, which would add further barriers to collaboration across the organization. The ‘Centre of Excellence’ must also not simply function as a chop shop for dealing with all DevOps related tasks, rather it should focus on identifying inefficiencies, aiding teams in overcoming issues by collaborating on building/implementing tooling and establishing processes and procedures. This approach will ultimately empower the business stakeholders, and Development, Test and Operations teams to work efficiently. If either of these points are ignored you risk defeating the purpose of adopting DevOps as a culture.
- Implement a roadmap for Operations and Development teams to deliver tooling, automation and service delivery. This will often require a cultural
shift in classic operational thinking by Ops teams offering ‘Infrastructure as a service’ to its customers (typically the Development and Test teams) with rapid turnaround.
- Establish a ‘Delivery focus group’ to include representatives across the business, and all IT Teams. Define and constantly review a roadmap that focuses on delivering high quality software so as to get to market and achieve Return on Investment (ROI) in the most efficient and scalable way.
With any of the above it is imperative that the culture encourages growing DevOps resources internally, culture is sensitive and this key part of DevOps is all about getting that balance right, effective management is key.
1. Quote taken from the very good DevOps for Dummies, by Sanjeev Sharma ‘http://sdarchitect.wordpress.com/2013/12/10/devops-for-dummies-ibm-developerworks-interview/’