The Journey into DevOPS as a Mindset, not a Project

DevOps as a project is a failed premise since projects complete, DevOps is ongoing, ever improving.

DevOps as a continuous improvement project is a non sequitur since the Agile / DevOps process cannot evolve from a waterfall mindset.

DevOps as a journey is inconclusive since a journey, similar to a project, has a destination. Although a journey may be construed as an experiencetial trek with an end rather than an optimized path to a goal.

DevOps as a mindset, a culture is the most illustrative since DevOps embraces the experience of not only the ascent to the summit, but also the triumph of performance.

DevOps is the most efficient and least problematic software development approach available today. DevOps may not be the best approach, but it certainly beasts the alternatives - especially the historical alternatives.

This blog attempts to chart the experiencetial journey from constrained waterfall implementation to modern DevOps mindset by exploring the journey and recognizing objectives.

Disclaimer: Waterfall is a phase, Agile is a phase, DevOps is a phase. After DevOps, the new phase beginning to gain foothold is the Lean phase. This blog willfully overlooks the Lean phase - for now.

Before Agile and DevOps

Before Agile and DevOps - Waterfall: scope, research, analyze, plan, execute, evaluate, test, deploy, assess. Waterfall produces the expected results: operations tell each other "if you want to get the project done, keep IT out of it." I have heard this multiple times. IT, through waterfall, has earned that reputation. I regret my complacency.

MIL-STD490

I worked in the military-industrial complex in the 1980s. I was fortunate - fortunate to work as an Avionics Systems Engineer for General Dynamics on the F-16 (Lockheed Martin is now the F-16 prime contractor) and for Sikorsky Aircraft on the Seahawk Helicopter.

DevOps was not even a remote thought. Neither was Agile. In fact task estimates were based on the number of words of code (in 32K or 64K machines). Software definition and product management was defined in the MIL-STD490A specification (1). A functionality changed involved changes to a thick B-5 Software Development Specification, a Preliminary Design Freeze (PDF), a Critical Design Freeze (CDR), Development, Testing (ground testing and flight testing), and finally a C-5 Software Product Specification --- in that order. To call it waterfall was being disparaging to waterfall projects. This MIL-STD490A specification is the predecessor to the Capability Maturity Mode.

Capability Maturity Model

My first encounter with the Capability Maturity Model (CMM) was during my Software Project Management class, part of my Master or Engineering degree. This business practice model was based on nearly unattainable goals of becoming efficient through regiment and control (an oxymoron even when attained). The 5 phases of the CMM are: (2)

Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new or undocumented repeat process.
Repeatable - the process is at least documented sufficiently such that repeating the same steps may be attempted.
Defined - the process is defined/confirmed as a standard business process.
Capable - the process is quantitatively managed in accordance with agreed-upon metrics.
Efficient - process management includes deliberate process optimization/improvement.

Then along came Sarbanes-Oxley Act (3). Now, effectively, the CMM Level 4 model was thrust upon all public-stock companies.

Application Implementation Methodology

The Oracle Corporation compounded inefficiencies by providing commercial and industrial entities a new iteration of the B-5 and C-5 specifications - the Application Implementation Methodology (AIM) (4). AIM even came with its own specification templates: the MD-50 and MD-70 specifications (5):

MD50:
This document specifies various functional specification required for Techies to understand the functional requirement of Form or Report Customization and design.. This is prepared by Functional consultant to clarify the spec to Techies. For any component like Report, Interface etc we have to first get the requirements as to what is the source , destinations, what data should be moved and what functional validations would be required etc. All this would go into the MD050. Generally written by a non-technical people like Business Analysts or Functional Consultants.

MD70:
This is technical specification prepared by the programmer based on MD50. This provides tech specs, PLSQL code for the Report and Form and helps to understand and modify if required in future. MD070 is the technical document that is written to fulfill the functional requirement specified in MD050. It includes the approaches you take, pseudo code, validations, Data Sources, SQL Statements etc.

The AIM methodology was a cash-cow for consultants. AIM justified many unread documents, forgotten meetings, and development extensions. In truth, there were dozens of documents designed to keep the consultants employed.

Agile and DevOps Development Practices

Before Agile, the developer team took requirements, disappeared a few months, and re-emerged with a creatioon that, while technically correct, seldom achieved the need or expectations of the users and operators.

Agile and DevOps are not synonyms. In fact, Agile is a precursor to DevOps.

Agile Development Methodology

The Agile Manifesto has been the rallying cry for high quality, high performing software developers for more than a decade. The concept is simple: (6)

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

So simple, but entire organizations have materialized to train, coach, administer these principals. Large scale projects have been simplified and deliveries have been achieved as a result of these principals. When asked his biggest regret, the president of a large software development firm said "that I did not implement agile sooner".

A concluding note on Agile: the project manager must embrace the MVP approach - the Minimum Viable Product. Each sprint produces a product - a viable, if not complete, product.

DevOps

In a recent Forbes article (7)

DevOps is the result of a growing need for frequent releases and disruption in the market dynamics. At the core of DevOps is continuous development and delivery. Faster time to market, successful and frequent releases, shorter lead time and steadfast recovery are some of the compelling features of DevOps, along with the ability to segment projects into fragments providing overall project visibility.

The DevOps Cycle extends the narrow Agile fixed-length scrum cycle to encompass faster time to deployment without surrendering the benefits of Agile.

But there is no manifesto for DevOps.There is no manifesto because (8):

DevOps begins with stopping the nightmare scenario pitting Ops against Dev—or any other part of the organization. But it comes so much further. It’s for a new age of computing at webscale, using tools, teamwork and techniques to get to better, happier, more engaged outcomes for customers. Some of it is so new we are still figuring out words for it.

Amazon Web Services offers a different view of DevOps (9):

Either illustration works when trying to understand DevOps. Reading further into the Amazon articled:

Software and the Internet have transformed the world and its industries, from shopping to entertainment to banking. Software no longer merely supports a business; rather it becomes an integral component of every part of a business. Companies interact with their customers through software delivered as online services or applications and on all sorts of devices. They also use software to increase operational efficiencies by transforming every part of the value chain, such as logistics, communications, and operations. In a similar way that physical goods companies transformed how they design, build, and deliver products using industrial automation throughout the 20th century, companies in today’s world must transform how they build and deliver software.

In summary, Agile is a job foreman, DevOps is an orchestra conductor. (10)

The 2017 State of DevOps Report identifies the advantages to DevOps (11). These advantages as summarized by the Neudesic presentation at the DevOps 2.0 seminar (12):

Faster Delivery
High Performing teams have 48 times lower MTTR and 3 times lower change failure rate.

Safer Delivery
High performing teams spend half as much time on rework and three times as much time on new work.

More Efficient
High performing teams have a 50% reduction in security related incidents.

Improved Satisfaction
Teams adopting CD / DevOps doubled their internal net promoter score and had tripled their customer net promoter score.

Increased Profitability
Organizations practicing CD / DevOps are 26% more profitable than traditional divisions of labor.

Conclusion

The DevOps mindset, culture, process represents the most mature improvement in development productivity available. DevOps is the progression of the waterfall mindset, to the agile mindset, into the process-centric DevOps mindset. The lean mindset is on the horizon and is practiced by some, but the DevOps mindset remains the goal for many development shops.