I come across many different interpretations of DevOps in various interactions with my peers, customers, partners, and service providers. But the terminology used is consistent: Put a word-cloud around all these interactions, and you’ll surface the usual suspects very quickly. Join me as I decode the nine key phrases of DevOps – and explain why each concept matters greatly as enterprises adopt the DevOps model.
1. Culture of the enterprise. "You can use as much DevOps as you want," as I heard from one of my co-presenters during the Gartner ITXPO Symposium last fall. DevOps is about striking a balance between the desire for agility and the need for stability. The culture of the enterprise at large can strongly influence which way the balance tilts and by how much. Culture is also influenced by market forces, change of leadership, and employee behavior. Which brings us to people.
2. Mindset of the people. It all comes down to the people. Segments of the workforce may be very comfortable doing what they have been doing for years together, and may be less likely to change. On the other hand, you may have a whole other segment that is all about introducing new paradigms and business models enabled by technology solutions perceived to be cool and sexy. Fundamental concepts like team play and the willingness to work toward a common goal are best driven by people with the right mindset – a mindset of collaboration.
3. Art of Collaboration. Collaboration requires the workforce to reach across the table and put themselves in the shoes of the very individuals with whom they are dealing. Development teams need to think ahead and take proactive steps to ensure that operations teams will find software code to be smooth, robust, and stable. Operations teams must respect the need for the rapid injection of consumer-driven features. Both teams must collaborate and have open exchange of information, with the common goal of innovatively meeting the expectations of the business users. And IT must work together to inject the right levels of automation towards this common goal.
4. Science of Automation. Automation is not just about using tools to do repeated tasks. The science of doing automation right is all about ensuring that the right processes are being executed the right way. Automation of the wrong processes or processes being executed the wrong way only creates more problems. The science of automation can also be applied to business processes. Automation must be done in increments across logical subsets of process steps that are part of a continuous engine.
5. Discipline of Continuous Integration. DevOps is a way of life. It is something that is done in a continuum, like a smoothly operating engine running in constant motion. This spirit of continuity applies to the integration of isolated changes to the larger code base on a daily (or more frequent) basis for updated builds. Active collaboration is a key catalyst to have developers frequently integrate their work, to promote early detection of problems – just what the testing team ordered.
6. Passion for Continuous Testing. This is one term that I have not heard often as I would like. CI/CD. Got that. What about CT? In the spirit of the collaboration that is the hallmark of the DevOps mindset, testing is everyone’s responsibility. To enable a fail fast mode, testing must begin early in the life cycle, starting with software requirements, source code reviews, and test data sets. With the common goal of delivering a timely and meaningful solution, development and operations must work together to configure the testing environment to be close to the production environment. And while we are at it, testing is a fine process to be automated! With meaningful automation and relevant test data sets, regression testing can almost become a perfect science – which helps address the need for Continuous Delivery.
7. Need for Continuous Delivery. The concept of Continuous Delivery can be best described using healthy eating habits as a parallel. All too often, I hear about eating smaller portions more frequently, rather than eating large meals spaced further apart. Enterprise IT– and by consequence, the business – is now looking for more frequent and continuous release of new features. To this end, the business is also willing to accept the potential downside of occasional hiccups, as long as they are fixed very quickly. The steady stream of new features is a significant shift in mindset that has permeated to the business. In other words, business is going DevOps.
8. System of Continuous Monitoring. To effectively inject the fail-fast mindset into an organization and achieve rapid-fire releases of features, you need to enable continuous monitoring across the product life cycle, from development through operations. A challenge very often encountered is the proliferation of environments and platforms that need to be monitored. The only way to combat this challenge is through ruthless standardization of the applications, platforms – and yes, tools.
9. The power of standardized tooling. And finally, here we are. Tools. Yes, we absolutely need various tools to do many of the activities discussed above. However, tools are not the first thing to be addressed when it comes to DevOps. Also, standardization of tools goes a long way in simplifying the business of IT, injecting healthy levels of purposeful automation with reusable processes.
Here is my definition of DevOps using all nine of these phrases:
DevOps is a way of life for people with the right mindset to embrace the culture to collaborate, while scientifically automating the continuous delivery of software features, with the rigor and discipline of continuous integration and a passion for continuous testing, while using the power of standardized tooling to continuously monitor everything being done.
What is your definition? Please let us know.
And I do understand if even this definition needs to be refined on a continuous basis – in the true spirit of DevOps !
