I spend a considerable amount of time with clients discussing DevOps and the potential value it can bring to them, but there is one theme that always resonates: the ability of a DevOps approach to eliminate risk. While many of us understand the benefits in terms of being faster (improved productivity), cheaper (reduced cost) and better (improved quality), I find that a conversation based around risk, especially when talking to the business or department heads, usually gets straight to their concerns in a language they understand.
IBM’s definition of DevOps is not simply about connecting development and operations; it is fundamentally about providing a capability that: 1) allows lines of business to connect with their customers (which may be internal employees) quickly, and 2) facilitates rapid feedback from their customers so relevant adjustments can be made. DevOps, therefore, embraces the philosophy of iterative (and incremental) development and delivery, whereby solutions are delivered through a series of incremental releases.
By ensuring all aspects of a solution (requirements, designs, code, executables, tests, etc.) evolve over time as each increment is completed, DevOps is fundamentally focused on addressing risks including:
- The risk of not knowing the requirements (have you ever tried to write down and freeze the requirements for a mobile app?)
- The risk of not knowing the solution (especially when it’s new, you’re defining a new architecture or you’re embracing new technologies)
- The risk of not knowing the effort (especially when the solution is novel for the organization)
- The risk of not delivering on time (when the pace of the team, for example, is an unknown)
- The risk of not providing the right level of quality (and the impact this may have on customer sentiment)
- The risk of adopting inappropriate practices (meaning that the approach being taken by the team is not working for them)
- The risk of having an ineffective delivery environment (including automation through the use of delivery tools)
I could go on. There are so many risks that can be addressed simply by delivering working software iteratively, that it’s surprising how many organizations continue to fall back to a “waterfall” mentality—even in high-risk environments where much is unknown.
The tack I’ve taken here originates from my time at Rational Software Corp. (which IBM acquired in 2003), where we would emphasize the need to deliver software iteratively and progress was measured based on the results achieved (i.e., working software) rather that the documents produced. My favorite graphic from that time is the one shown below, which shows how a modern approach changes the risk profile associated with a delivery project, since it focuses on removing risk as early as possible in the life cycle.
In summary, incremental and continuous delivery evident in a DevOps approach allows us to call out risk early and determine its resolution. DevOps often is used along with “lean startup” thinking (and its build-measure-learn cycle) and monikers such as “fail fast” since these are, at their heart, also focused on addressing risk.
Take the DevOps self-assessment to find out where are you on your DevOps journey
About the Author / Peter Eeles
Peter Eeles is an Executive IT Architect in the DevOps Global Tiger Team, IBM Hybrid Cloud, where he helps organizations improve their IT delivery capability in order to drive tangible business value. He has a particular interest in the adoption of architecture, agile, DevOps and cloud as innovation enablers. In the IT industry since 1985, Peter comes from a delivery background and was previously chief architect of IBM Rational’s Worldwide Solution Delivery organization, where he led many large-scale transformations in a variety of industries. Peter has written many papers and several books, including “The Process of Software Architecting” (2009), “Building J2EE Applications with the Rational Unified Process” (2002), and “Building Business Objects” (1998). He runs his own website at www.architecting.co.uk.
