All About Ops — Identifying Balance in DevSecOps Practices
By: Mark Peters
Modern technology and profitability rely primarily on Ops so, despite advocating DevSecOps practices, sensible individuals realize successful businesses are all about Ops. Upset yet? Understanding how to balance Dev, Sec, and Ops for your organization should matter to all professionals and this article emphasizes balance from ops. Development (Dev) creates competitiveness but without ops nothing reaches the customer. Security (Sec) manages compliance but without ops and dev, no products exist to become secure or compliant. DevSecOps creates a complex ecosphere where interactions rotate around dependency. Ops generates monthly cash flow and customer interactions; how can it not be central to an organization? Achieving balance is difficult. Successful DevSecOps does not create equality between tasks rather offers systemic understanding of flow, The First Way. Organizations concentrating only on Ops are likely failing to achieve DevSecOps success. Practitioners should specialize at identifying how Dev, Sec and Ops interact through balancing flows for improved feedback and improvement.
Taking a step back, Dev, Sec and Ops balance precariously; a Venn diagram highlighting personal preferences, functional interactions, and corporate guardrails. Analytically, each interaction receives a distinct label. Simple relationships show static inputs producing consistent results; if one has two apples, and one adds two apples, one has four apples. Complicated factors include more variables, when one buys two more apples, user money cannot be spent again while a store gains money and loses inventory which affects subsequent sales. More issues, but still relatively streamlined. Complex issues are the Gordian knot, a yarn ball where pulling on one string affects multiple strings in multiple ways not determinable initially. These three values help determine whether balance factors are dependent, independent, interdependent.
Dependent and independent determinations are frequently simple, one action either causes a clear result, dependent, like heating a pot of water raises the temperature, or independent, no result regardless of action as when heating the water never affects the refrigerator temperature. Most DevSecOps practices exhibit formal interdependence with no set hierarchy between the elements and multiple channels available to affect outcomes. Interdependent processes are resilient with complex relationships being resistant to and influenced by change. These non-linear, non-predictable outcomes must be mediated by task balance. For example, if sales decrease resulting in ops surveys customers for new ideas, passes the results to dev, and engages security, workloads will change at non-standard rates to develop, secure and deploy products based on whether delivery occurs in Kubernetes, Cobol, or a new language. At the same time, initial changes can come from a previously unknown vulnerability, or back-end improvements to a product. A complex engagement with interdependent variables, for the math inclined, shows as not simply y=mx+b but as fractal geometries.
With so many options, why start on Ops? Analyzing processes must start somewhere and while each DevSecOps element brings integrated components, hard workers, and dedication to overall success, starting with Ops begins with the largest, and most visible, surface. Only Ops converts business value into revenue establishing profit, expansion and paychecks. Only Ops manages customer-facing reality daily. Only Ops initiates business value insights. Dev and Sec may comprehend business requirements, and discuss value stream mechanics but Ops conducts business, all day, every day. Understanding customer needs starts many DevSecOps ideas but coherence only emerges from Ops interacting with purchasing individuals. Value-stream analysis considers Ops goals first when seeking balance, by size if not by any other characteristic.
Most important should be that Ops first does not mean Ops only. Considering balance leads to DevOps initial foundations and must be refreshed periodically through analysis. One could consider Dev first instead. Dev first often appears as a start-up mantra as a Field of Dreams variant, if we develop the product, the customers will come. Dev still must empower Ops to deliver customer value. Sec first will likely never be an option commercially. If no product exists, and no new features are added, nothing needs securing. If one follows Sec first, coordination will likely suffer as products are locked-down before being integrated. When increasing capabilities, the key question should not be how to build, but how to deliver through production, consistently and securely, as a balanced approach. At the end of the day, the central question should be, how do we deliver revenue across multiple value streams. Dev delivers new value, Sec delivers relative value, and Ops makes sure customers receive value, so, balance Ops first.
Recognizing Ops’ organizational importance, and the DevSecOps practices awareness of balance makes the next step recognizing your organization’s balance points. Finding balance means knowing when to lead, and when to follow. This holds true with personal relationships as well as corporate ones. Balanced interactions allow Ops to maximize revenue, function securely and pass ideas to Dev. Dev should complete code fixes to improve products, plan for new features, and deploy frequently. Sec must secure deploying code, minimize negative risk, and suggest future opportunities. One’s organization must identify metrics to ensure balance and maintain those balances. Flow metrics exist but can be highly individualized. An Ops team which does not regularly push improvements back to Dev, a Dev team which does not consider deployment constraints, or a Sec team implementing unmanageable restrictions may all be out of balance.
Most Dev and Sec folks who have read this far are probably still seething about prioritizing ops. The overall takeaway should not be Ops preeminence and instead realize finding balance through improving DevSecOps flows requires understanding processes. One can easily identify companies where Dev occurs without Ops, Ops without Dev, and where Sec was ignored. Recognizing shortfalls creates a need for action. Decisions create error but inaction leads to disaster, all practitioners should find base rates to compare regular activities in finding balance. Suggesting Ops as preeminently important should be neither bad nor detrimental. Ops can matter most within balanced DevSecOps approaches as unique work functions create different base rates. DevSecOps practitioners should pride themselves on identifying complex indicators suggesting balance. Simple rates may consider releases versus deployment ratios, architectural plan completion, security fixes, and of course, feedback loops. Each base rate demonstrates an initial point to show the complicated and complex way interdependent DevSecOps processes interact. Understanding organizational flow creates a basis for success. Stating, “Ops first” here as an analytical viewpoint, or in one’s own organization, creates an initial rate to balance a DevSecOps process. At the end of the day, one should not be Sec first, or Dev First, or Ops first but DevSecOps first, and improve flow across the entire organization.
Footnotes:
1 Keohane, Robert, and Joseph Nye. Power and Interdependence. Pearson 4 thEd. (20 Feb, 2011)
2 Field of Dreams, https://www.imdb.com/title/tt0097351/, “If you build it, they will come..”
DevOps Institute is dedicated to advancing the human elements of DevOps success through the SKIL Framework: Skills, Knowledge, Ideas, and Learning. Learn more.
Originally published at https://devopsinstitute.com on June 23, 2020.
