English | EN 
For me, DevOps is more than just automation or implementing certain tools. Conceptually, DevOps is not just implementing Puppet, Chef, Ansible, Selenium, or writing unit tests in your language of choice. DevOps is also not: agile specific, a prescriptive series of tasks and or tools to implement, a prescriptive methodology to be implemented. DevOps is not having ‘deployments’ occurring every day. DevOps is: a philosophy, a way of being, a way of operating, a goal that is never really achieved. DevOps is ‘run-rinse-repeat’ methodology, or the standardization and repeatability of your processes.
When I did a quick search for ‘DevOps’ on Google, I got interesting search resultswith several advertisements for tools, along with the Wikipedia article for DevOps. I am going to choose to ignore the fact that the Wikipedia article doesn’t do justice to my opinion of the DevOps philosophyand I feel it is somewhat short-sighted. A quick perusal of the article, for the uninitiated, makes one think that if you implement an Agile development process, leverage the cloud, and introduce some tools, you are now ‘doing DevOps’.
Let’s Explore
As I stated earlier, DevOps is a philosophy, a way of operating, a way of thinking about the day to day activities within an organization, and identifying inefficiencies within the ‘software manufacturing process’. When we look at the production of software, and all the individual inputs, and tasks necessary to produce software; the similarities between manufacturing become readily apparent. When we produce software, there are a distinct set of inputs: requirements, code production, validation, creation of supporting infrastructure, Quality Assurance, and the release of our code to our customer (internal or external). If we compare this to a simplified example in automobile production: a car is designed (engine sizes, transmissions, appearance), sub-assemblies are produced, sub-assemblies are combined, Quality Control occurs, the cars are shipped to dealers. At the end of the day, both software development and automobile production are a manufacturing process. Then why do we not take the approach to the manufacturing of software that the automobile manufactures do? Toyota introduced the concept of Kaizen within their assembly lines and were highly successful, to the point where they were copied by other manufactures.
Practical Application
The approach to ‘software manufacturing’ that most companies have implemented, is fraught with inefficiencies and with a Kaizen based approach, can lead to a significant cost savings, along with an increase in efficiency. If a car fails Quality Control, and has to be reworked, the manufacture now has to inject the rework back into a production line which was not designed to ‘fix cars’ but was designed to ‘produce cars’ (a discussion of a Six Sigma / Lean Manufacturing approach is the subject for another time). What is the cost for rework (fixing bugs), in the software development process? Let’s assume each bug takes four hours to fix, and we have a blended cost of $50US per hour for labor on our software manufacturing line. This means that each bug costs you $200US to fix. How many bugs are we finding and fixing each month, quarter, half, or year? What does that cost us in lost productivity? Very quickly, fixing bugs becomes ‘real money’ and the return on investment of the cost of implementing a DevOps journey suddenly becomes very affordable.
. . . Enter the Philosophy
As we have already discussed, rework leads to extra costs; so what if we do everything we can to eliminate rework? As I opened this post, DevOps is more than just automation. DevOps is a philosophy that consists of a three pronged approach: people, process and tools. The astute reader of this post, will notice that of the three prongs of DevOps, only one is about technology (tools).
Let’s take a look at the easiest prong to define; process. Many companies have a process in place around their software manufacturing process. We may have a Change Advisory Boards (CAB), we have code reviews, we have run-books for deployments; just to name a few processes. How much time do we spend in each of these three steps? If our code is not complete in time to make the deadline for a CAB meeting, what is the cost to the business? Is the manufacturing process for software changed so that we can meet the deadlines for the CAB, or do we follow our process and then request an exception to the process? Philosophically, and a strictly rhetorical question I always like to pose; when does an exception to the change process, become SOP?
For me, the first step in a DevOps journey is to take a good hard look at the software manufacturing processes. Identify the inefficiencies in the process. Re-align our definitions for things such as: standard change, normal change, exception, definition of done, definition of ready for development, etc. Look at each individual process in your software manufacturing process and take a Kaizen approach to your process improvements.
Once you have started the process of, well process improvement; take a look at the people. Do you have the right people to support the process? If not, can you train existing employees, or do you need to hire the right talent?
Now for the final prong of DevOps; the tools. Once we have embarked on our own companies approach to Kaizen in the software manufacturing process, we need to take the time to identify the appropriate tools to support your processes. What ALM tooling do we need? Have we implemented the best source control provider? Have we taken every opportunity to ‘shift left’ the identification of errors in our manufacturing pipeline? HOW are we deploying software? As stated before, and worth mentioning again, that the earlier we catch an error in our product, the cheaper it becomes for us to fix. If we identify, automatically, that a bug was created in our code base, as early in the process as possible, then the fix for that error costs less to remediate, than the cost of the bug entering production.
Let’s automatically check for business logic errors. Let’s automatically check to make sure that the user interface does what it is supposed to do. Let’s make sure that when code is committed to the code base that standards are followed. Let’s automatically check for performance issues. Let’s automatically make sure that all of our environments are identical in configuration. Let’s automatically validate that code that is released to production does not introduce a performance impact on our infrastructure. Let’s automatically re-deploy prior code when new code fails. Let’s automatically re-create infrastructure components which have failed.
I opened this post with the title that DevOps is greater than automation, but while closing this post, I want to ask you a philosophical question , does DevOps equal Automation?
