What Is HeleCloud?

HeleCloud is an Amazon Web Services (AWS)-only systems integrator and managed services provider (MSP). The company operates offices in London and the Netherlands, with an engineering centre in Sofia, Bulgaria. Its business divides into two main practices: professional services and managed services.

According to CEO and co-founder Dob Todorov, the managed services arm runs as a “24/7 highly automated operation” designed to provide support for mission-critical applications on the AWS platform.

Who Does HeleCloud Work With?

HeleCloud’s customer base spans several sectors. Examples cited by Todorov include:

• CGI — the large systems integrator running the UK government’s smart metres programme, for whom HeleCloud builds and operates cloud-based infrastructure on AWS.
• Rakuten Viber — the voice-over-IP service, for whom HeleCloud reviews and optimises security and compliance on the AWS platform.
• Zopa — the financial services company, for whom HeleCloud is migrating significant portions of mission-critical systems from traditional hosting facilities to AWS.

The Core Misconception: AWS Does Not Manage Everything for You

The central message from Todorov is that many organisations adopted AWS under a fundamental misunderstanding of the shared responsibility model.

“Many organisations made the assumption that in AWS, it’s all managed for you from AWS and therefore you don’t need managed services at all — and that’s only partially true. It’s true that a lot of the conventional managed services provider work around hardware and connectivity is no longer required, but at the same time cloud requires someone to architect it to a fashion which is secure, compliant, high-performing and both cost and operationally efficient.”

— Dob Todorov, CEO, HeleCloud

In other words, AWS abstracts away physical infrastructure — servers, networking hardware, data-centre facilities — but it does not automatically design, secure, optimise or govern the workloads customers run on top of it. That responsibility still sits with the customer, or with an MSP acting on their behalf.

Where MSPs Add Value in the Cloud Era

Todorov argues that the role of the MSP has shifted rather than disappeared. Traditional MSPs focused on hardware racking, patching physical servers and managing network connectivity. On AWS, that lower layer is handled by Amazon. However, the layers above it — architecture, security posture, compliance, cost governance and operational automation — still require expert attention.

HeleCloud’s differentiation rests on two pillars:

• AWS specialism — deep, single-platform expertise covering ITIL v4 integration, infrastructure support, security and compliance management, performance management, service and data availability, and cost optimisation.
• DevOps as a managed service — the ability to deliver continuous integration and continuous delivery (CI/CD) pipelines as part of an ongoing managed engagement, rather than treating DevOps as a one-off professional services project.

“Managed services providers can add value by moving up the stack and making sure they automate and they involve DevOps principles on top of conventional IT service management.”

— Dob Todorov, CEO, HeleCloud

Todorov also points to the pace of AWS feature releases as a practical reason organisations need ongoing help. AWS regularly launches new services and updates existing ones; keeping an estate current and secure in that environment requires continuous engineering attention.

The Changing Cloud Market: New Build vs. Legacy Migration

Todorov describes a clear split in how organisations are approaching cloud adoption:

• Net-new workloads are almost universally being built in the public cloud.
• Existing legacy applications are largely staying in on-premises data centres or private cloud environments, at least for the time being.

“Cloud is becoming the mainstream platform for virtually all organisations; everything new is being built in the public cloud space, but a trend we’re not seeing is mass migration of existing applications — so even though there are some projects, for the time being large organisations are keeping their existing estate in data centres or in the private cloud.”

— Dob Todorov, CEO, HeleCloud

Todorov believes migrating existing applications to public cloud would deliver better security and compliance outcomes, but acknowledges that large organisations have not yet reached that conclusion at scale. Risk aversion, regulatory complexity and the sheer effort of re-platforming are common barriers.

Multi-Cloud Strategy

As multi-cloud becomes a common enterprise strategy, HeleCloud — being AWS-only — addresses non-AWS requirements by partnering with large systems integrators that have capabilities on other platforms. This allows the company to participate in broader deals without diluting its AWS depth.

What’s Next: SaaS, PaaS, AI and Data

Looking ahead, Todorov identified two trends he expected to define the following years (from the perspective of early 2020):

• Cloud providers moving further up the stack — expanding their SaaS and PaaS offerings beyond raw infrastructure, giving customers higher-level managed capabilities.
• Data and AI/ML convergence — organisations archiving large volumes of data on platforms such as AWS, and then applying artificial intelligence and machine learning tools to derive insight from that data.

Key Takeaway for DevOps and Cloud Engineers

The shared responsibility model is not just a compliance checkbox — it is an operational reality. AWS secures and maintains the underlying infrastructure, but every customer is responsible for what they build on top of it: architecture decisions, IAM policies, encryption configuration, patching schedules for managed services, cost guardrails and CI/CD pipelines. Whether that work is done in-house or by an MSP, it must be done. Organisations that skip it do not escape the responsibility; they simply accumulate unmanaged risk.

APM Adoption Is Nearly Universal—But Mostly Reactive

Application performance management (APM) tools are now a standard part of the IT toolbox: nine out of ten IT professionals surveyed reported using APM tools deployed either on-premises or via a SaaS platform. Despite that near-universal adoption, the SolarWinds survey reveals a significant gap between how teams could use APM and how they actually do.

Nearly eight in ten respondents said they spend less than 10% of their time proactively optimizing their environments. In practice, this means most APM usage is driven by incidents—teams reach for monitoring data after something breaks rather than using continuous telemetry to prevent issues before they surface.

The Three Biggest APM Challenges

Survey respondents identified a clear hierarchy of obstacles blocking more effective APM use:

• Lack of personnel training (57%) — The top barrier by a wide margin. Teams have the tools but not always the skills to extract full value from them.
• Lack of awareness of available APM solutions (44%) — Many practitioners don’t have a clear picture of what the current APM market offers, making tool selection difficult.
• Confusion over which solution fits their needs (42%) — Even when teams are aware of their options, choosing the right tool for their specific architecture and scale remains a challenge.

Jim Hansen, Vice President of Products for Application Management at SolarWinds, attributed part of the problem to tool sprawl. Organizations are simultaneously running database monitoring (64%), application monitoring (63%), and infrastructure monitoring (61%)—three overlapping disciplines that each demand expertise and context-switching.

Mixed Architectures Are Complicating APM Coverage

The challenge is compounded by the fact that most organizations are not running a single, consistent application architecture. Survey respondents reported managing APM across:

• Monolithic (traditional on-premises) architectures — 59% of respondents
• N-tier service-oriented architectures (SOA) — 40%
• Microservices-based applications — 39%

Running APM across all three simultaneously means teams need tools—and skills—suited to fundamentally different observability models. A single agent-based APM product may work well for a monolithic app but provide incomplete coverage for a distributed microservices environment where requests span dozens of services and multiple infrastructure layers.

Why Microservices Will Force a More Proactive Approach

Hansen pointed out that as organizations migrate away from monolithic applications, the shortcomings of a reactive APM posture will become harder to ignore. Microservices architectures introduce dense dependency graphs: a single user-facing transaction may traverse ten or more services, each with its own latency profile, failure modes, and infrastructure dependencies.

In that context, waiting for an alert before investigating is often too late—by the time a symptom surfaces, root cause may already be buried several hops upstream. This is driving interest in APM platforms that correlate signals across application traces, infrastructure metrics, and logs in a unified view, and that can surface anomalies automatically rather than requiring manual threshold tuning.

Confidence Is High—But Skill Gaps Remain

Despite the challenges, respondents expressed a relatively high degree of self-assessed confidence: 84% said they were confident in their ability to manage application and infrastructure performance. However, the specific use cases where respondents felt most comfortable reveal a continued reactive bias—40% said they are most comfortable using APM tools to troubleshoot application performance issues after they arise.

The top three insights teams said they gain from APM tools were:

1. Preventing application outages — 73%
2. Preventing app slowdowns related to performance or capacity — 63%
3. Improving user and customer experience — 62%

These three outcomes all point toward proactive APM value—yet the earlier finding that most time is spent reactively suggests a gap between aspiration and practice. Teams know what good looks like; they’re not consistently getting there.

Where Teams Want to Improve

When asked about priority areas for development, respondents gave a tightly clustered set of answers:

• Improving ability to track impact across key business metrics — 31%
• Improving ability to troubleshoot application issues — 30%
• Improving application code performance — 29%
• Managing and improving end-user performance — 29%

The clustering of these responses suggests teams recognize they need broad improvement across the APM skill set—not a single weak area—which reinforces the training-gap finding at the top of the challenges list.

What This Means for DevOps Teams

Reactive APM is better than no APM, but it falls short of the continuous feedback loops that underpin mature DevOps and SRE practices. Proactive APM—using baseline telemetry, anomaly detection, and dependency mapping to identify degradation before users notice—requires both the right tooling and teams that are trained to act on the signals those tools surface.

Several practical steps can help bridge the gap identified in this survey:

• Consolidate monitoring disciplines. Where possible, use platforms that unify application, infrastructure, and database observability to reduce context-switching and correlation overhead.
• Define SLOs and alert on symptoms, not just thresholds. Error-budget-based alerting encourages teams to act before outages rather than after them.
• Invest in training alongside tooling. The survey’s top finding—57% citing lack of training—suggests that tool procurement outpaces enablement. Structured onboarding and regular practice with APM dashboards and query languages pays dividends.
• Audit tool sprawl. Running three parallel monitoring categories without integration creates noise and skill fragmentation. Evaluate whether consolidation or tighter integration is feasible.
• Align APM to business outcomes. The 31% of respondents who want better business-metric correlation are pointing toward a real best practice: tying telemetry to revenue, conversion, or reliability SLAs makes APM relevant beyond the ops team.

As hybrid architectures and microservices continue to proliferate, the organizations that invest now in proactive APM practices—and the training to back them up—will be better positioned to maintain reliability at scale without proportional growth in toil.

What Is Astro?

Fairwinds, a managed Kubernetes services provider, released an open source project called Astro that creates a simplified, automated bridge between Kubernetes clusters and the Datadog monitoring platform. The project is aimed at operations teams that already rely on Datadog to monitor traditional monolithic applications and want to extend that same tooling to their Kubernetes workloads without rebuilding their monitoring workflows from scratch.

The Problem Astro Solves

According to Fairwinds CTO E.J. Etherington, one of the most common pain points for Datadog users running Kubernetes is that monitors are typically configured and deployed manually. As clusters scale and Kubernetes objects change — new deployments, namespaces, services — each corresponding Datadog monitor must be manually updated to stay accurate. This creates significant operational overhead and increases the risk of gaps in monitoring coverage.

Astro addresses this by automating monitor lifecycle management. Rather than requiring a site reliability engineer (SRE) to track changes in Kubernetes and reconcile them with Datadog configuration, Astro handles this automatically using rule sets based on defined patterns within Kubernetes.

How Astro Works

Astro operates at the Kubernetes namespace level. Its core capabilities include:

• Automated monitor management: Astro watches Kubernetes objects within a namespace and keeps corresponding Datadog monitors in sync as those objects change.
• Dynamic updates: When a Kubernetes object is modified — for example, a deployment is scaled or a new service is added — Astro updates the associated Datadog monitor automatically to reflect the current state.
• Contextualized alerting: Data from managed Kubernetes objects can be injected directly into Datadog monitor definitions, enriching alerts with contextual metadata. This makes it easier for on-call engineers to triage incidents without having to cross-reference multiple sources.
• Rule-based pattern matching: Monitors are created and managed based on defined rules tied to patterns in Kubernetes resource definitions, giving teams a consistent and repeatable way to enforce monitoring standards across clusters.

The end goal, as Etherington described it, is to eliminate the manual integration work that would otherwise fall to an SRE every time a Kubernetes environment changes.

Why Datadog, When Prometheus Exists?

Prometheus is the most widely adopted open source monitoring tool in Kubernetes-native environments. As a CNCF project, it integrates deeply with the cloud-native ecosystem and is a natural default for teams building greenfield microservices architectures.

However, many enterprise IT operations teams have already standardized on Datadog for production application monitoring — often years before they began adopting Kubernetes. Migrating away from an established monitoring platform is costly and disruptive. Astro is designed for exactly this scenario: organizations that have real-world Kubernetes workloads in production but need those workloads to feed into the same Datadog dashboards and alert pipelines used for everything else in their environment.

Etherington noted that Datadog is capable of ingesting metrics from a wide variety of open source and commercial software sources, making it a practical aggregation layer for heterogeneous environments.

Fairwinds’ Open Source Ecosystem

Astro is not Fairwinds’ first open source contribution to the Kubernetes community. The company also maintains:

• Polaris: A configuration validation tool for Kubernetes that checks deployments against best practices and security policies.
• Goldilocks: A utility that helps teams right-size Kubernetes resource requests and limits by analyzing actual resource usage, reducing both over-provisioning and out-of-memory incidents.

All three projects emerged from practical problems Fairwinds encountered while operating managed Kubernetes services for its customers. This grounding in real operational experience gives the tools a pragmatic focus that distinguishes them from more theoretical tooling.

The Broader Observability Challenge in Kubernetes

As Kubernetes adoption moves from experimentation to production at scale, the demand for robust, automated observability tooling continues to grow. Microservices architectures introduce complex dependency chains that make monitoring not just useful but essential. A failure in one service can cascade across many others, and without comprehensive observability, identifying root causes becomes extremely difficult.

Historically, IT operations teams applied monitoring selectively — prioritizing mission-critical monolithic applications due to tooling costs and complexity. That approach does not translate well to Kubernetes environments where dozens or hundreds of interdependent services may be running simultaneously.

Projects like Astro represent one approach to bridging the gap: rather than forcing teams to choose between their existing monitoring investment and Kubernetes-native tooling, they automate the integration so both can coexist without placing additional manual burden on already-stretched SRE and operations teams.

Key Takeaways

• Astro automates the creation and lifecycle management of Datadog monitors based on the state of Kubernetes objects.
• It is particularly valuable for teams already invested in Datadog who are expanding into Kubernetes without wanting to maintain two separate monitoring workflows.
• Monitors are kept continuously updated as Kubernetes namespaces and objects change, reducing manual SRE overhead.
• Fairwinds has open-sourced Astro alongside its Polaris and Goldilocks projects, all targeting real operational problems in managed Kubernetes environments.

The Scale of the IoT Data Problem

IoT devices sit at the edge of the network. They are purpose-built to sense and transmit — not to store or analyze. Most edge devices have constrained CPU, RAM, and storage because adding compute resources increases cost, power consumption, and physical size. Yet collectively, a large IoT deployment can generate data volumes that dwarf what any single on-device store could accommodate.

The logical answer is to offload storage and heavy computation to an external system — one that can scale independently of the devices themselves. That external system is, in almost every modern IoT architecture, the cloud.

Cloud Storage for IoT: Beyond Simple File Storage

Cloud providers offer object storage, time-series databases, data lakes, and managed streaming pipelines specifically designed to ingest high-velocity, high-volume IoT telemetry. Rather than provisioning physical storage inside each device — which would make devices larger, more expensive, and harder to maintain — engineers can stream raw telemetry directly to cloud endpoints and store it centrally.

This centralization has practical benefits beyond cost:

• Unified data access: All device data lands in one queryable location, making cross-device correlation straightforward.
• Retention flexibility: Retention policies can be adjusted without touching the devices themselves.
• Redundancy: Cloud storage is inherently replicated across availability zones, providing durability that no single edge device could offer.

Processing Power: Turning Raw Telemetry into Insight

Storage alone is not enough. Raw sensor readings — temperature values, GPS coordinates, vibration amplitudes — are meaningless in isolation. Value emerges when data from many devices, collected over time, is aggregated, correlated, and analyzed.

Cloud platforms provide the compute capacity to run these workloads at scale: stream processing pipelines can apply real-time transformations and anomaly detection as data arrives, while batch analytics jobs can identify longer-term trends across weeks or months of historical data. Machine learning models trained on this aggregated data can then be deployed back to the edge to improve device behavior — a pattern sometimes called the cloud-to-edge feedback loop.

A concrete example is IoT data used in CRM or customer analytics platforms. Individual device interactions — a user adjusting a thermostat, pausing a connected appliance — are low-signal on their own. Aggregated across thousands of users and devices in cloud infrastructure, these interactions can reveal behavioral patterns, inform product decisions, and drive personalized experiences.

Latency: When Cloud Isn’t Fast Enough

Sending data to a remote cloud data center and waiting for a response introduces latency — typically measured in tens of milliseconds over a well-connected link, but potentially much higher under congested or unreliable network conditions. For many IoT use cases, this is perfectly acceptable. A connected fridge reporting its temperature inventory has no need for millisecond response times.

However, there are categories of IoT application where this latency is unacceptable:

• Autonomous and assisted driving: Collision avoidance decisions must be made in microseconds to milliseconds. A round-trip to a cloud data center is far too slow.
• Medical devices: An implantable cardiac monitor detecting an arrhythmia needs to trigger a local alert immediately, without waiting for cloud acknowledgment.
• Industrial safety systems: A sensor detecting dangerous pressure buildup in a pipeline must trigger a valve closure locally and instantly.

This latency constraint is the primary driver behind edge computing — deploying compute resources physically close to the devices, on-premises or at network edge nodes, so that time-critical decisions can be made locally. The cloud then handles less time-sensitive tasks: long-term storage, model training, analytics, and dashboard reporting. A well-designed IoT architecture typically uses both tiers: edge compute for real-time response, cloud for scale and intelligence.

Security: Centralization as Both Shield and Target

IoT security is a well-documented challenge. Devices are often deployed in physically accessible locations, may run firmware that is difficult to update, and frequently connect over untrusted networks. A cloud-based security layer addresses some of these weaknesses:

• Centralized threat detection: Anomalous behavior on one device — unusual data volumes, unexpected connection attempts — can be detected centrally and used to trigger protective actions across the entire fleet.
• Certificate and identity management: Cloud IoT platforms provide device identity services that issue and rotate cryptographic credentials, reducing the risk of credential compromise.
• Firmware update delivery: Over-the-air (OTA) update infrastructure, typically cloud-hosted, is essential for patching vulnerabilities across large device fleets.

At the same time, centralizing data in the cloud creates a high-value target. A breach of the cloud backend can expose data from every device in the network simultaneously. This tension — centralization as both enabler and risk — is one of the core security engineering challenges in IoT architecture. Defense-in-depth strategies, including network segmentation, end-to-end encryption of device telemetry, and strict access control on cloud APIs, are essential mitigations.

Financial Scalability: Pay for What You Use

IoT workloads are rarely uniform. A retail chain’s sensor network may generate orders of magnitude more data during peak shopping seasons than in slow periods. An agricultural monitoring platform may have high data ingestion during growing seasons and near-zero traffic in winter. Pre-provisioning fixed on-premises infrastructure to handle peak load means paying for idle capacity the rest of the time.

Cloud infrastructure’s pay-as-you-go model maps well to these variable demand patterns. Storage and compute can scale up automatically when device data volumes increase and scale back down when they fall — without requiring manual intervention or capital expenditure. This elasticity is particularly valuable for IoT startups and teams running pilot deployments who cannot accurately forecast their eventual data volumes.

Architectural Patterns: Cloud-Only vs. Hybrid Edge-Cloud

Understanding when to use cloud-only versus a hybrid edge-cloud architecture is a key design decision in any IoT project. The following table summarizes common considerations:

Key Takeaways

• IoT devices generate large data volumes but have limited onboard compute and storage. Cloud infrastructure fills this gap.
• Cloud platforms provide not just storage but also the processing pipelines, analytics engines, and ML infrastructure needed to derive value from raw telemetry.
• Latency constraints in safety-critical IoT applications require edge compute alongside cloud backends — not instead of them.
• Cloud-based security tooling helps manage large device fleets, but centralization also increases the consequence of a backend breach. Security must be layered.
• Cloud’s elastic cost model suits the variable, hard-to-forecast data volumes typical of IoT deployments.

As IoT device fleets continue to grow, the cloud remains the most practical and scalable backend infrastructure available. The engineering challenge is not whether to use cloud, but how to architect the boundary between edge and cloud to meet the specific latency, reliability, and cost requirements of each application.

Yet for organizations that have genuinely internalized DevOps as a philosophy rather than a product purchase — Google, Netflix, and Amazon among them — it remains far from meaningless. Its practices demonstrably accelerate software delivery, improve collaboration, and create competitive advantage.

How DevOps Lost Its Groove

DevOps was conceived as a movement to help enterprises increase their ability to ship features and launch products at higher velocity. As it moved into the mainstream, however, a familiar pattern took hold. Self-proclaimed DevOps experts repeatedly failed to operationalize and scale the approach inside large organizations. Initiatives stalled because teams couldn’t justify the investment — partly because it is notoriously difficult to measure the ROI of a cultural shift.

As developers searched for concrete tools to bring an intellectual pursuit to life, the market responded with a catalog of products, each claiming to deliver DevOps in a box. “DevOps” became a marketing slogan attached to CI/CD pipelines, ticketing systems, monitoring dashboards, and cloud platforms alike. A web search for “DevOps solutions” returns pages of providers whose promotional copy makes vague promises: “We know the DevOps philosophy and have you covered” or “Learn how our solution can help you implement DevOps at any stage.”

The implication — that a software license is all that stands between your organization and DevOps maturity — is, of course, misleading. If only it were that simple.

The result is a healthy skepticism whenever the term is raised. There are worse fates than becoming a buzzword, but the noise reliably distracts from what DevOps is actually about.

What We Know About DevOps: Velocity Creates Value

The core insight of DevOps remains sound: improving software delivery requires the ability to measure outcomes, share those results across the organization, and iterate continuously. Getting features to customers faster generates competitive advantage and greater market share. Speed to market is not the whole story, but it is the forcing function.

In practice, however, the benefits of DevOps have proven elusive. A key reason is that DevOps provides a loose set of principles and cultural philosophies — collaboration, automation, and continuous improvement — but stops well short of prescribing how to implement them. Implementation is left to interpretation, and that ambiguity is both a strength and a significant liability. Looking to “DevOps” for a precise execution playbook will send teams down a dead-end road.

Site Reliability Engineering: DevOps Made Actionable

Google tackled the prescriptiveness problem directly. When the company published its foundational work on Site Reliability Engineering (SRE), it took the philosophy of DevOps and activated it — converting abstract principles into an operational guide. The analogy is instructive: the Agile Manifesto articulated values and principles; Scrum came along later to provide a concrete framework. SRE played a similar role for DevOps, codifying how to manage reliability, toil, and the relationship between development and operations teams at scale.

Metrics and Benchmarking: The DORA Framework

Structured frameworks have also emerged to help organizations benchmark their DevOps progress. Google’s DevOps Research and Assessment (DORA) group publishes an annual State of DevOps report that introduces metrics enabling leaders to assess delivery performance — from low performers to elite performers — across dimensions such as deployment frequency, lead time for changes, change failure rate, and time to restore service. The research also identifies practical strategies for scaling DevOps adoption, including establishing internal training centers, running multiple proof-of-concept phases, and forming communities of practice.

These frameworks matter because they shift the conversation from “are we doing DevOps?” to “how effectively are we delivering software, and where can we improve?” That is a measurably more useful question.

Moving Beyond the Buzzword in Your Organization

DevOps, at its best, is a means of culturally ingraining speed, agility, rapid development, scalability, and cross-functional collaboration. It is not one-size-fits-all. The right implementation depends heavily on organizational structure. Netflix and Amazon, for example, orient development teams into small, autonomous squads — each responsible for a discrete piece of the overall system. That model works for their architecture and culture; it may not translate directly to a regulated financial services firm or a government agency.

DevOps can be genuinely transformative only if adoption is treated as the internalization of practices, principles, and disciplines — not the procurement of a toolchain. It is a journey of learning, iteration, and improvement. Success will not be found overnight, and organizations that expect otherwise will be disappointed regardless of which products they purchase.

The Expansion Into DevSecOps

The DevOps movement is also expanding in scope. DevSecOps integrates security and compliance disciplines directly into the development and operations lifecycle rather than treating security as a gate at the end of the pipeline. The same caution applies here: the need to identify and respond to cyber threats demands operational rigor that cannot be satisfied by an off-the-shelf product. Bringing security genuinely into the DevOps culture requires the same patient, iterative work that DevOps itself demands.

AIOps: The Next Cultural Shift

Looking further ahead, the emergence of AIOps — using machine learning and big data to automate operational tasks and resolve incidents in real time — presents a similar challenge. Achieving genuinely intelligent operations requires significant organizational adaptation, not just a new platform subscription. The lesson DevOps teaches is clear: cultural shifts of this depth do not happen overnight and cannot be packaged into a product.

Key Takeaways

• DevOps is a philosophy, not a product. No tool or platform delivers DevOps on its own. Tooling supports practices; it does not replace them.
• Prescriptiveness matters. The lack of a precise “how” in DevOps is a genuine limitation. Frameworks such as SRE and DORA’s Four Key Metrics help fill that gap.
• Cultural change takes time. Organizations that treat DevOps as a quick fix will see limited returns. Sustainable improvement requires patient, iterative work across people, process, and technology.
• Structure shapes implementation. The right DevOps model depends on your organization’s size, structure, and domain. Copying another company’s model wholesale is unlikely to succeed.
• The umbrella keeps expanding. DevSecOps and AIOps extend the same cultural logic into security and intelligent operations. Apply the same discipline — not the same shortcut-seeking — to each.

DevOps does not have to be a buzzword inside your organization. The meaning it carries for your teams will be determined entirely by how seriously you turn its core principles — collaboration, automation, and continuous improvement — into daily practice.

This article is based on analysis originally published by The Enterprisers Project.

Stages of the Cloud-Native Journey

Adopting cloud-native principles is not a single event; it is a phased journey. Organisations typically pass through three broad stages before they can claim genuine cloud-native maturity.

Stage 1: Embracing the Evolution

The first stage is cultural and architectural. Because DevOps succeeds or fails on the strength of team collaboration rather than tool selection alone, organisations must first build a culture that welcomes rapid, iterative change. This means breaking down silos between development, operations, and security teams and establishing shared ownership of the delivery pipeline.

On the technical side, teams begin integrating DevOps practices with early cloud-native patterns. A common starting point is hardening the existing monolithic architecture with well-defined domain boundaries — a prerequisite before gradually extracting container-based microservices. Skipping this foundation tends to create a distributed monolith rather than a genuinely decoupled system.

Stage 2: Experimentation

Once the cultural and architectural groundwork is in place, teams move into deliberate experimentation. A common anti-pattern at this stage is Shadow IT — individual teams spinning up their own cloud infrastructure outside of approved organisational channels in order to move faster. While the intent is understandable, the result is fragmented governance, inconsistent security posture, and duplicated cost.

The antidote is active adoption of DevOps practices alongside a microservices architecture, so that velocity is achieved through sanctioned, repeatable processes rather than workarounds. Practical experiments at this stage include:

• Monitoring investment: Selecting and embedding an observability stack early increases deployment confidence and reduces mean time to recovery (MTTR).
• Component reuse: Identifying reusable libraries and build artefacts shortens future delivery cycles.
• Container-based infrastructure: Running workloads in containers and wiring them through CI/CD pipelines gives teams firsthand experience with scalability patterns and fault-tolerance mechanisms.

Stage 3: Cloud-Native at Scale

At full cloud-native maturity, microservices run on a container-based platform where deployments can occur multiple times per day. Services are decentralised into small, independently deployable units, which removes inter-team dependencies and compresses time-to-value. Microservices also offer language and framework agnosticism, allowing squads to choose the right tool for each specific problem rather than being constrained by a single technology stack.

How the Cloud-Native Model Emerged

Cloud-native thinking grew out of earlier architectural experiments, most notably the decoupling of front-end and back-end into headless architectures. Once organisations experienced the benefits of clean separation of concerns, they began asking a more ambitious question: what if the entire application were rebuilt around independently deployable, loosely coupled services?

The appeal of continuous integration and continuous delivery (CI/CD) was a major pull factor. Teams wanted the freedom to deploy individual components on their own release cadence, without waiting for a monolithic release window. Key organisational motivations included:

• Autonomous team ownership of individual services and their release cycles
• Smaller, focused development teams able to contribute meaningfully to large products
• Reusable build artefacts and shared libraries that accelerate future projects
• Reduced dependency on shared on-premises infrastructure through cloud-based environments
• A sandbox for larger-scale experiments that would be prohibitively expensive or risky on-premises

What Makes Cloud-Native Compelling?

Cloud-native is not simply a newer version of traditional cloud hosting — it represents a fundamentally different design philosophy. Several characteristics distinguish it:

• Data architecture shifts: Cloud-native patterns encourage polyglot persistence — choosing the right data store for each service — rather than relying on a single centralised database.
• Telecoms and infrastructure: Telecommunications providers and large infrastructure operators are actively building low-cost cloud computing centres capable of running custom, highly distributed applications at scale.
• Open-source momentum: Cloud-native development is closely intertwined with open-source communities (CNCF, Kubernetes, Prometheus, Envoy, etc.), giving individual contributors a meaningful role in shaping production-grade tooling.
• Business agility: Organisations that successfully adopt cloud-native models gain the ability to experiment rapidly, respond to market signals, and release features independently — compressing the distance between idea and production.

3 Common Pitfalls in Cloud-Native DevOps

1. Over-Investing in Tools

Automation depends on tools, but effective automation depends on the right tools used by teams that understand them deeply. Every new tool added to the stack carries onboarding cost, integration effort, upgrade overhead, and cognitive load. Teams that chase every new release in the CNCF landscape often end up with a sprawling, poorly understood toolchain that slows delivery rather than accelerating it.

The discipline is to evaluate tools against concrete workflow problems, adopt them deliberately, and retire them when better alternatives emerge. DevOps culture — team ownership, shared responsibility, continuous improvement — is still the engine; tools are just the gearbox.

2. Treating Pipeline Tests as the Last Line of Defence

CI/CD pipelines make automated testing easy to integrate, which is a genuine improvement over manual gate-keeping. The pitfall is complacency: treating a green build as sufficient evidence that a deployment will succeed in production. Build-and-unit tests cannot surface the full range of integration failures, performance regressions, or environment-specific issues that emerge at runtime.

DevOps teams should complement pipeline tests with continuous monitoring, alerting, and post-deployment verification. Observability — structured logs, distributed traces, and metrics — closes the feedback loop that tests alone leave open.

3. Neglecting Security Until It Becomes Urgent

Security testing is frequently deferred because it is perceived as slow and expensive. While it is true that embedding security tooling into CI/CD workflows is a positive step, it is not sufficient on its own. Cloud-native environments introduce new attack surfaces: container image vulnerabilities, misconfigured Kubernetes RBAC policies, exposed cloud storage buckets, and service-to-service trust boundaries all require explicit treatment.

A pragmatic approach is to shift security left in small, incremental steps consistent with agile principles — adding image scanning, secret management, and policy-as-code checks progressively rather than attempting a wholesale security transformation overnight.

Kubernetes: Leading the Way

Kubernetes has emerged as the dominant container orchestration platform and is now effectively the runtime foundation for cloud-native DevOps. Its appeal rests on several concrete capabilities:

• Declarative configuration: Desired state is defined in version-controlled manifests, making infrastructure reproducible and auditable.
• Self-healing: Kubernetes automatically restarts failed containers, reschedules workloads from unhealthy nodes, and replaces pods that fail health checks.
• Horizontal scaling: The Horizontal Pod Autoscaler adjusts replica counts based on observed metrics, enabling applications to handle variable load without manual intervention.
• Ecosystem: A rich ecosystem of CNCF projects (Helm, Prometheus, Fluentd, Istio, and others) extends Kubernetes into a full application platform.
• Community: Kubernetes benefits from one of the largest open-source contributor communities in existence, which drives rapid feature development and broad cloud-provider support.

For DevOps teams, Kubernetes provides a consistent target environment across development, staging, and production. This consistency eliminates a large class of environment-specific bugs and simplifies the cognitive model that engineers need to carry.

Conclusion

Cloud-native and DevOps are complementary movements that reinforce each other. Cloud-native architecture provides the technical foundation — microservices, containers, CI/CD, and declarative infrastructure — while DevOps provides the cultural and organisational framework that makes continuous delivery sustainable. Neither succeeds as well in isolation.

Organisations embarking on this journey should expect the path to be iterative. Start by building collaborative culture and hardening your existing architecture, experiment deliberately with containers and observability tooling, and progress toward a fully decoupled microservices platform as confidence grows. Avoid the common traps of tool sprawl, shallow testing, and deferred security. With Kubernetes as the operational backbone and a strong DevOps culture driving the team, the cloud-native destination is well within reach.

Original source: opensenselabs.com (2019)

This shift raises an important question: as DevOps practices such as agile methodology, continuous deployment, and iterative optimization become standard in modern engineering teams, should automation follow the same principles? The answer is yes—and this article explores how to apply a DevOps mindset to your automation strategy.

The Problem with “Set and Forget” Automation

Legacy automation was built for a more stable world: physical servers with predictable workloads, slow-moving infrastructure, and infrequent change cycles. You wrote a script, ran it on a schedule, and moved on. That model is increasingly incompatible with modern cloud-native environments where infrastructure is ephemeral, workloads are dynamic, and business requirements change rapidly.

The risk of static automation is compounded by scale. When a machine executes a flawed or outdated policy, it does so consistently and at speed—propagating mistakes across hundreds or thousands of resources before anyone notices. This is precisely why automation must be treated as a living system, subject to the same continuous improvement cycles that DevOps applies to software delivery.

The New Expectations of IT Automation

Applying a DevOps mindset to automation starts with asking the right questions before and after you automate anything. The following four questions provide a practical framework for building an iterative, continuously optimized automation practice.

1. Is This a Good Process Worth Automating?

This may seem like an obvious starting point, but it is frequently skipped. Processes and policies are often automated once and then forgotten—even as the underlying infrastructure, application architecture, or business goals change significantly. A continuous optimization approach forces teams to periodically revisit existing automation and ask whether each policy still serves its intended purpose.

Not every process is a good candidate for automation. Some workflows are sensitive enough that automating them without sufficient safeguards threatens data integrity or compliance. Others are high-level decisions that depend on contextual judgment that scripts cannot replicate. A good automation engineer identifies which tasks genuinely benefit from automation and which require human oversight, and they revisit that assessment regularly.

2. How Often Does This Process Occur?

Frequency matters both for justifying the investment in automation and for keeping automation schedules accurate. Tasks such as patching, load balancing, or workload orchestration may run on a fixed time-series schedule or be triggered on demand. As infrastructure evolves—particularly as teams adopt serverless and cloud-native patterns where workloads are short-lived and highly variable—those schedules must evolve too.

An automation schedule that made sense for a fleet of long-running virtual machines may be entirely wrong for a containerized microservices environment. Continuously adapting the schedule to match actual workload patterns and customer demand is a core part of keeping automation effective.

3. How Long Does the Process Take?

Automation must be tested for both efficiency and correctness against the actual duration and frequency of the task it replaces. Some legacy system updates take hours; some orchestration tasks are near-continuous. Automation that is slower than the manual process—or that introduces latency into a time-sensitive pipeline—creates new problems rather than solving old ones.

Treat automation performance as a measurable metric. Establish baselines for how long manual execution takes, then measure automated execution against those baselines regularly. Regressions in execution time are a signal that the automation needs to be revisited.

4. Is There an Irreplaceable Human Element?

Automation can handle well-defined, repeatable tasks with reliable inputs—but it struggles with ambiguity, novel situations, and tasks that require contextual judgment. Activities such as deriving insights from anomalous data, designing new workflows, program management decisions, or architectural trade-offs still benefit significantly from human involvement.

This is where AIOps—the application of artificial intelligence and machine learning to IT operations—becomes relevant. AIOps can extend automation into more complex domains by giving systems the ability to learn from historical patterns and make probabilistic decisions. However, for most organizations today, AIOps is still an emerging capability. Until it is mature and accessible, teams should explicitly map out the points in any automated workflow where human review and decision-making must occur, and build those checkpoints into the process deliberately.

Applying DevOps Principles to Automation

The parallels between DevOps and a mature automation practice are direct:

• Iterate frequently. Just as DevOps favors small, frequent releases over large infrequent ones, automation policies should be updated in small increments and tested in staging or limited-blast-radius environments before wide deployment.
• Measure everything. DevOps relies on observability to understand system behavior. Automation should emit metrics and logs—execution time, success and failure rates, number of resources affected—so that its performance can be monitored and regressed against.
• Fail fast and recover. Good automation includes error handling, rollback mechanisms, and alerting. When a policy fails, the failure should be surfaced quickly and the impact contained.
• Treat automation as code. Store automation scripts, runbooks, and policies in version control. Apply code review practices. This makes changes auditable and reversible.
• Collaborate across teams. Automation that spans development, security, and operations benefits from cross-functional input—the same way DevOps breaks down silos between dev and ops teams.

Automation as a Strategic Tool, Not an End Goal

Automation is one of the most impactful capabilities available to modern IT operations teams. It reduces the burden of repetitive manual work, accelerates incident response, and frees engineers to focus on higher-value problems. But automation is a means to an end, not the destination itself.

Think of automation as a system that turns operational data into action. The quality of that action depends entirely on the quality of the policies driving it—and those policies must be maintained, measured, and improved continuously. As AI and machine learning capabilities mature and become more accessible, they will extend what automation can do. Until then, it falls to IT professionals to apply the same discipline to automation that DevOps has brought to software delivery: iterate, measure, improve, and never stop asking whether the current approach is the right one.

This article is based on analysis originally published on devops.com, drawing on findings from the Capgemini enterprise automation survey.

No single transformation path fits every organization, but the research found that these five capabilities are essential at every stage of DevOps maturity. Teams that embed them early create the conditions for continuous improvement, faster delivery, and stronger cross-functional collaboration.

1. Monitoring and Alerting Are Configurable by the Team Operating the Service

Effective DevOps requires both empowerment and accountability at the team level. High-performing organizations give individual product and service teams the authority to define their own monitoring thresholds, alerting rules, and observability criteria for the services they run in production—rather than delegating that responsibility to a central operations group.

When teams own their own monitoring configuration, several things happen naturally:

• Faster incident detection: The people who built the service know which signals matter most and can tune alerts accordingly.
• Shared metrics culture: Teams can publish dashboards and share measurement approaches across the organization, promoting continuous improvement.
• Systems thinking: Visibility into how one service affects others fosters cross-team collaboration and a broader understanding of the production environment.

Tools such as Prometheus, Datadog, Grafana, and PagerDuty all support team-level configuration of alerts and dashboards. The tooling matters less than the organizational decision to give teams genuine ownership of what they measure.

2. Deployment Patterns Are Reused Across Applications and Services

Reinventing the deployment process for every application is expensive and error-prone. Top-performing DevOps organizations standardize on reusable deployment routines, pipeline templates, and tooling that any team can adopt and extend.

According to the Puppet report, 46% of high-performing DevOps organizations reported always reusing deployment patterns, compared to just 2% of lower-performing organizations. That gap is significant: standardized deployment patterns reduce the cognitive overhead of shipping software, make onboarding new engineers easier, and create a shared vocabulary for discussing deployments across teams.

In practice, reusable deployment patterns might take the form of:

• Shared CI/CD pipeline templates in tools like Jenkins, GitLab CI, or GitHub Actions
• Standardized Helm charts or Kubernetes manifests for containerized workloads
• Internal deployment libraries or platform engineering products that abstract infrastructure complexity

3. Testing Patterns Are Reused Across Applications and Services

The same logic that applies to deployment applies equally to testing. High-performing organizations do not ask every team to define its own approach to unit testing, integration testing, and end-to-end validation from scratch. They build and share reusable testing patterns that encode organizational knowledge about how to verify software quality reliably.

The Puppet report found that high-performing organizations are 44 times more likely to use repeatable testing patterns than lower-performing peers. Reusable test frameworks reduce the barrier to achieving meaningful test coverage, make test results comparable across services, and give platform and quality engineering teams a lever to raise the quality floor for the whole organization at once.

Common implementations include shared test harnesses, contract testing libraries (for microservices), and standardized policies for code coverage thresholds enforced at the pipeline level.

4. Teams Contribute Improvements to Tooling Owned by Other Teams

In siloed organizations, tooling improvements stay within the team that built the tool. Engineers in other teams who identify a bug or a missing feature either work around it or duplicate effort by building their own version. This is one of the most persistent anti-patterns in enterprise software delivery.

High-performing DevOps organizations break down that silo by creating a culture—and the technical infrastructure—for cross-team tooling contributions. The Puppet report found that high performers are 44 times more likely to contribute improvements to tooling provided by other teams. Treating internal tools as internal open-source projects, with contribution guides, code review processes, and clear ownership, is one proven way to enable this behavior.

Platform engineering teams that operate internal developer platforms (IDPs) are well-positioned to formalize this practice. Exposing platform capabilities as versioned APIs or libraries with public repositories makes it straightforward for application teams to raise pull requests with improvements.

5. Configurations Are Managed by a Configuration Management Tool

Configuration management was one of the earliest technical practices associated with the DevOps movement, and it remains a reliable baseline indicator of organizational maturity. Managing infrastructure and application configuration through code—rather than manual, ad hoc changes—enables reproducibility, auditability, and faster environment provisioning.

The Puppet report found that 53% of high-performing organizations always use a configuration management tool, compared to 2% of lower-performing ones. Tools in this category include Puppet, Ansible, Chef, and SaltStack for infrastructure configuration, as well as approaches like GitOps (using tools such as Flux or Argo CD) for application configuration in Kubernetes environments.

The benefits compound over time: teams that manage configuration as code can spin up consistent test environments on demand, reduce configuration drift between staging and production, and trace every infrastructure change back to a specific commit and author.

Putting the Five Practices Together

These five practices are mutually reinforcing. Configuration management makes reusable deployment and testing patterns easier to implement consistently. Cross-team tooling contributions spread those patterns faster. Team-owned monitoring closes the feedback loop so that each release cycle generates actionable data for the next one.

Organizations starting a DevOps transformation often look for a single lever to pull. The Puppet research suggests that sustainable improvement requires building all five capabilities in parallel, even if the initial implementations are modest. Start with configuration management and team-owned monitoring—both deliver value quickly and build the muscle memory for the collaborative practices that follow.

The statistics cited in this article are drawn from a Puppet State of DevOps report referenced in a TechRepublic article published in November 2018. Refer to Puppet’s annual State of DevOps Report series for the most current benchmarks.

Introduction

Since Puppet published its first State of DevOps Report in 2012, the annual survey has accumulated nearly 30,000 responses from practitioners around the world. That body of data makes it possible to look beyond global averages and ask more granular questions: Do DevOps adoption patterns differ by geography? Does industry vertical influence IT performance? And where does automation actually begin?

The State of DevOps Market Segmentation Report — Puppet’s first attempt at slicing the data by peer group — was designed to help organisations benchmark themselves against companies of similar size, region, and industry rather than against an undifferentiated global average.

Automation as the Primary DevOps On-Ramp

One of the report’s clearest findings is that most organisations begin their DevOps journey by targeting their most acute pain points — and that automation is the most common first step. Rather than starting with lean process design or metrics visualisation, teams typically reach for automation tools first.

The three most common starting points are:

• Continuous integration (CI) — automating the build and test cycle triggered by code commits.
• Deployment automation — reducing the manual steps required to move a build from a passing test suite into a target environment.
• Infrastructure automation — codifying server and environment configuration so it can be provisioned repeatably and at scale.

The motivation is straightforward: every manual handoff in a release pipeline is a potential delay, a source of inconsistency, and a drain on engineering time. Automation removes those friction points, shortens lead times, and frees teams to focus on building features rather than shepherding releases.

However, the data also shows that automation is far less pervasive than industry conversation might suggest. Despite widespread discussion of CI/CD and infrastructure-as-code, most companies report significant amounts of manual work remaining across their software delivery lifecycle. Automation is relieving the sharpest pain points, but few organisations have achieved end-to-end automated pipelines.

Measuring IT Performance: Throughput and Stability

To compare DevOps maturity across segments, the 2017 State of DevOps survey measured IT performance along two dimensions:

• Throughput — how frequently a team commits code and how quickly that code moves from commit to production deployment.
• Stability — how fast a system recovers from unplanned downtime (mean time to recovery, or MTTR) and the ratio of successful changes to failed ones (change failure rate).

High performers excel on both dimensions simultaneously. According to the report’s figures, high-performing organisations deploy code 46 times more frequently than low performers and achieve a 96 times faster mean time to recovery. They also have shorter lead times from commit to deployment and lower change failure rates — demonstrating that speed and stability are complementary outcomes of mature DevOps practice, not trade-offs.

Regional Performance Differences

Segmenting by geography reveals meaningful variation in the distribution of high, medium, and low performers:

• India, Japan, and Northern Asia had the highest proportion of high-performance IT organisations at 24%.
• Mexico, Central America, and South America followed with 20% of organisations rated as high performers.
• Central and Eastern Europe had the highest proportion of medium performers at 53%.
• The United States and Canada had the highest proportion of low performers at 45%.

A notable finding across all regions: more than half of surveyed organisations met at least a medium performance threshold. The widespread narrative that DevOps is still a niche practice does not fully hold up — adoption is broad, even if high performance remains concentrated.

Industry Performance Differences

When the data is broken down by industry vertical, the picture at the top is surprisingly uniform: most industries had roughly the same small share of high performers, clustered around 15%. The more significant variation appears in the low-performance tier.

Industries with the lowest proportion of low performers (i.e., doing relatively well):

• Media and entertainment — only 23% of organisations rated as low performers, the best result of any industry.
• Retail — 31% low performers.

Industries with the highest proportion of low performers (i.e., lagging behind):

• Financial services — 54% of organisations rated as low performers.
• Insurance and industrial/manufacturing — each at 53%.

Heavily regulated industries like financial services and insurance face additional constraints — compliance requirements, audit trails, and risk-averse change management cultures — that can slow DevOps adoption even when the technical appetite is present.

The Automation Ceiling: Change Approval Remains Manual

Even among organisations actively investing in DevOps, automation does not penetrate every stage of the software delivery pipeline equally. The data shows a clear pattern across industries:

• Configuration management and software deployment are the areas most commonly automated.
• Testing retains more manual steps than deployment, with many organisations yet to achieve comprehensive automated test coverage.
• Change approval is the stage most resistant to automation. Even in the media, entertainment, and technology sectors — the industries with the lowest rates of manual work elsewhere — more than half of organisations still rely on manual change approval processes.

This is a meaningful insight for teams planning their automation roadmaps. Organisations are willing to automate execution but remain reluctant to remove human judgement from the decision to release. Whether this reflects genuine risk management, organisational culture, regulatory obligation, or simply inertia will vary by company — but the pattern is consistent across sectors and company sizes.

The practical takeaway: if your organisation is automating builds and deployments but still routing every release through a manual change advisory board (CAB) or approval ticket, you are in good company. The data suggests that even high-performing organisations blend automated execution with human oversight at the approval gate.

Key Takeaways for DevOps Practitioners

• Start with pain points. Automation of your most manual, error-prone processes is a validated entry point for DevOps adoption — not just a theoretical best practice.
• Measure throughput and stability together. Teams that optimise only for speed risk instability. High performers achieve both.
• Benchmark against your peer group. Global averages can be misleading. Regional and industry context matters when assessing where your organisation sits on the performance spectrum.
• Expect automation gaps in testing and change approval. These are industry-wide challenges, not just yours. Prioritise incremental progress rather than waiting for a fully automated pipeline before starting.
• Regulated industries face additional headwinds. If you work in financial services, insurance, or manufacturing, the data confirms that your environment is more challenging — but it also shows room for significant improvement.

For teams looking to improve, the segmentation data offers a useful mirror: knowing where your region and industry sit on the performance curve is the first step toward identifying which practices to prioritise next.

The Mainframe Skills Gap Is Blocking DevOps Adoption

Despite decades of predictions to the contrary, the mainframe remains central to enterprise computing. A study cited by Forrester at the time of this report found that 64 percent of enterprises planned to run more than half of their critical application workloads on the mainframe. Yet only 37 percent reported being able to keep pace with the demand for skilled mainframe professionals.

That gap between mainframe reliance and mainframe expertise is a significant barrier to modernization. As workloads grow—driven by analytics, blockchain integrations, and increased mobile traffic—enterprises face pressure to accelerate mainframe application delivery using the same Agile and DevOps practices already standard on distributed and cloud platforms.

Compuware Updates zAdviser with AI and Real-Time Metrics

To address this challenge, Compuware announced updates to its zAdviser platform, a solution designed to help mainframe development leaders track, measure, and improve development velocity, quality, and efficiency. zAdviser applies artificial intelligence and machine learning to surface connections between individual developer behaviors and key performance indicators (KPIs), and to identify DevOps trends and patterns across the organization.

The updated release introduced several notable capabilities:

• Improved dashboard interface built on Elastic’s Elastic Cloud Service, providing a more accessible and unified view of mainframe DevOps data.
• Advanced behavioral and operational metrics to give teams deeper visibility into how developers interact with their toolchains.
• Near real-time data streaming, enabling faster detection of issues and quicker response cycles.
• Expanded AI and algorithmic correlation, helping teams identify whether high defect rates follow specific code changes and whether developers are making effective use of their DevOps tooling.

The practical outcome is that engineering managers can make data-driven decisions about training, tool adoption, and process improvement—rather than relying on anecdotal evidence or delayed retrospective reviews.

“Enterprises that have put off their mainframe modernization efforts must move quickly to bring their DevOps practices on the platform up to par if they want to stay competitive in a marketplace where continuous digital innovation has become table stakes. Rich, fact-based insight into their current state—and into whatever might be impeding them from achieving their desired state—is essential for accelerated adoption of mainframe DevOps.”

— Daniel Howard, Senior Researcher, Bloor Research

Partnership with CollabNet VersionOne: Value Stream Management Comes to the Mainframe

Alongside the zAdviser updates, Compuware announced a new partnership with CollabNet VersionOne to extend enterprise DevOps automation to mainframe environments using a Value Stream Management (VSM) approach.

The integration connects two complementary tools:

• Compuware ISPW — a DevOps-enabled source code management solution purpose-built for mainframe environments, handling version control, build automation, and deployment pipelines on z/OS.
• CollabNet VersionOne Continuum — an enterprise pipeline orchestration and value stream management platform designed to track, automate, and coordinate software delivery workflows across heterogeneous environments.

By connecting ISPW’s mainframe source control capabilities with Continuum’s orchestration layer, enterprises gain end-to-end visibility into mainframe software value streams alongside their distributed system pipelines. This helps break down the historical silo between mainframe and non-mainframe development, moving away from waterfall-bound delivery cycles toward iterative, Agile-aligned practices.

“As large enterprises digitally transform to compete in today’s fast-moving markets, the smart ones are aggressively transforming their mainframes away from siloed, waterfall-bound development, leveraging the Agile and DevOps best practices they’ve brought to their other platforms. This announced partnership combines Compuware’s modern take on mainframe tooling with the cutting-edge enterprise value stream management from CollabNet VersionOne.”

— Jason Bloomberg, President, Intellyx

Why Mainframe DevOps Matters

For organizations running core banking, insurance processing, retail transaction systems, or government workloads on z/OS, the mainframe is not a legacy curiosity—it is the production system of record. Yet many of these organizations struggle to apply the same CI/CD, automated testing, and pipeline tooling that their distributed platform teams take for granted.

The combination of AI-driven observability (via zAdviser) and value stream orchestration (via the CollabNet VersionOne integration) represents a practical path forward: make the mainframe a first-class citizen in the enterprise DevOps toolchain, rather than treating it as an exception that requires entirely separate governance and delivery processes.

As Forrester noted at the time, customer-obsessed enterprises need to modernize application delivery across all platforms—including the mainframe—to remove roadblocks to innovation and keep pace with digital transformation demands.

Key Takeaways

• The mainframe remains critical infrastructure for a majority of large enterprises, but the skills gap threatens their ability to modernize delivery.
• Compuware’s updated zAdviser platform uses AI and ML to surface actionable DevOps metrics specific to mainframe development teams.
• The Compuware–CollabNet VersionOne partnership integrates ISPW with Continuum to bring Value Stream Management to mainframe software pipelines.
• VSM on the mainframe allows organizations to achieve end-to-end pipeline visibility across both mainframe and distributed environments.
• Enterprises delaying mainframe DevOps modernization risk falling behind competitors who are already applying Agile practices across all platforms.

The Evolution of DevOps

In 2007, Belgian engineer Patrick Debois observed a persistent and costly friction between development and operations teams. Having worked across both disciplines, he recognised that agile methodologies—then largely confined to software development—could be applied equally well to infrastructure management. The concept was initially called agile infrastructure, but the term that stuck was DevOps: a portmanteau of development and operations.

In 2008, O’Reilly Media launched the first Velocity conference, built on a complementary insight: developers and web operators were working toward the same goals yet rarely collaborating effectively. Velocity created a forum for the two groups to share knowledge, and much of the early DevOps community coalesced around conversations that began there.

At the same time, the commercial internet was scaling dramatically. Companies such as Amazon, Google, Flickr, Facebook, and YouTube were growing from single servers to fleets of thousands. Downtime or degraded performance at that scale carried immediate, measurable business consequences, raising the stakes for everyone responsible for keeping systems running. The pressure to eliminate the wall between the people who wrote software and the people who operated it became impossible to ignore.

DevOps has since moved well beyond an idea. However, the cultural and tooling shift remains uneven: many organisations have invested heavily in development-side automation while operations practices have lagged behind, limiting the full value of the approach.

Five Stages of DevOps Evolution

Most organisations do not jump straight to a mature DevOps practice. The journey typically unfolds across five recognisable stages, each building on the last.

Stage 1: Normalise the Technology Stack

The journey begins with housekeeping. Teams adopt genuine agile practices, implement version control consistently, and start working toward continuous integration and delivery pipelines. Critically, redundant or conflicting technologies are identified and removed. The goal is to build on a standard, agreed-upon set of tools and to place application configurations under version control so that the environment becomes reproducible and auditable.

• Adopt proper version control for both code and configuration.
• Remove redundant tooling that creates unnecessary complexity.
• Establish a shared CI pipeline as a foundation for later automation.

Stage 2: Standardise and Reduce Variability

With a normalised stack in place, teams work to further consolidate their technology choices—ideally converging on a single operating system or OS family—and to reduce process complexity. Early collaboration between development and operations becomes a deliberate practice rather than an exception. System configurations join application configurations in version control, and applications may need to be rearchitected to align with actual business requirements rather than historical assumptions.

• Consolidate to a single OS or OS family where feasible.
• Reduce process steps and approval chains that add delay without adding value.
• Place system configurations in version control alongside application code.
• Begin cross-functional planning between dev and ops early in the delivery cycle.

Stage 3: Expand DevOps Practices

With the foundational pieces in place, this stage focuses on closing the gaps created by earlier changes. The output of the application development team must align with what the delivery pipeline actually produces—mismatches here undermine the efficiency gains from previous stages. Teams should reach a level of autonomy where individual contributors can complete work without seeking approval outside the team, and where changes can move forward without lengthy wait times.

• Audit and reconcile discrepancies between development output and operational delivery.
• Push decision-making authority to the team level to reduce bottlenecks.
• Measure and reduce cycle time for getting changes from commit to production.

Stage 4: Automate Infrastructure Delivery

This is where the gap between development velocity and operational delivery time starts to close meaningfully. Security configurations, system configurations, and infrastructure provisioning are automated, removing manual steps that slow delivery and introduce human error. The DevOps team can ship faster and is positioned to support self-service workflows in the next stage.

• Automate provisioning using infrastructure-as-code tooling.
• Include security and compliance configurations in the automation layer.
• Treat infrastructure automation with the same code-review rigour as application code.

Stage 5: Provide Self-Service Capabilities

At this mature stage, developers can provision their own testing environments on demand without waiting for an operations team member to intervene. Deployment pipelines are well-established and largely self-service. Success metrics—deployment frequency, lead time, failure rate, mean time to recovery—are visible to the entire team, creating a shared understanding of system health and delivery performance.

• Enable developers to spin up and tear down environments independently.
• Surface delivery and reliability metrics to every team member, not just management.
• Use feedback from metrics to drive continuous improvement across all five stages.

Key Takeaways

DevOps adoption is a progression, not a single transition. Organisations that try to jump directly to full automation without first normalising their stack and reducing variability often find that the automation simply scales their existing problems. Moving deliberately through each stage—standardising, collaborating, automating, and finally enabling self-service—produces compounding improvements in delivery speed, reliability, and team autonomy.

Original content sourced from devops.com.

The DevOps Journey Is Rarely Linear

Every organisation approaches DevOps differently, and the path forward is almost never a straight line. There are false starts, stalled initiatives, and cultural friction that can kill early momentum and breed cynicism across teams. Without a clear, prescriptive framework, many organisations find themselves unable to scale DevOps practices beyond a handful of high-performing teams.

That is the central finding of the 2018 State of DevOps Report, co-authored by Puppet and Splunk. The report categorises organisations into three broad maturity tiers—Low, Medium, and High—based on how frequently they apply key DevOps practices. The data reveals a striking distribution: approximately 80 percent of organisations fall into the Medium tier, roughly 11 percent are Low, and fewer than 10 percent qualify as High.

The jump from Low to Medium is achievable for most organisations willing to commit to foundational changes. The leap from Medium to High, however, is significantly harder—and that gap represents a meaningful competitive opportunity for teams that can close it.

The Five Stages of DevOps Evolution

The 2018 report maps organisations along an evolutionary scale built around a core question: how frequently are key DevOps practices actually being used? Organisations that apply all the practices consistently are classified as highly evolved (High). Those applying few practices infrequently are Low. The majority sit in the middle, doing some things sometimes.

The five-stage model is designed to give organisations a pragmatic, prescriptive path forward—one that helps them identify where they are today, replicate existing pockets of success across teams, and make measurable forward progress rather than stalling indefinitely at Medium.

The Executive Perception Gap

One of the report’s most important findings concerns the disconnect between leadership and the teams doing the work. For nearly every DevOps practice surveyed, C-suite respondents were more likely to report that the practice was in frequent use than team-level respondents were.

• 44 percent of C-suite respondents believed their organisation automates security policy configurations, compared to 36 percent at the team level.
• 59 percent of C-suite respondents in one question variant reported automated security policy configurations, again versus 36 percent at the team level.
• In the Asia-Pacific and Japan (APJ) region, only 59 percent of respondents felt supported by leadership in their DevOps initiatives, compared to 63 percent in the United States and 60 percent in Europe.

This gap is not simply a communication problem—it is a measurement problem. When executives rely on self-reported or anecdotal signals, they develop an inflated view of organisational maturity. The practical remedy is objective, automated measurement: telemetry and dashboards that surface the actual state of DevOps adoption rather than what teams or leaders believe to be true.

Collaboration Is the Scaling Mechanism

Highly evolved organisations share a defining trait: their teams collaborate to build and share automation rather than hoarding tools and knowledge within siloed groups.

• In APJ, 41 percent of highly evolved teams collaborate to automate services for broad organisational use, compared to only 13 percent of the least evolved teams.
• Best practices and reusable patterns are shared across the organisation in 28 percent of highly evolved teams, versus just 10 percent in the least evolved tier.

The underlying dynamic is straightforward: DevOps empowers individuals to make changes without navigating layers of approvals. That empowerment only becomes an organisational asset when the knowledge and tooling behind those changes is shared. Without deliberate collaboration, DevOps success remains local—a win for one team, invisible to the rest of the business.

Security Automation as a Maturity Indicator

Security policy automation emerges in the report as one of the clearest markers separating highly evolved organisations from the rest. According to the findings, highly evolved organisations are 24 times more likely to always automate security policy configurations compared to the least evolved organisations.

This is significant because it reflects a change in mindset, not just tooling. In low-maturity organisations, security is typically addressed reactively—bolted on before an audit or after an incident. In high-maturity organisations, security policy configuration is treated as an operational concern, automated from the outset and maintained continuously. Teams initially automate security for their own efficiency; over time, that automation matures into a shared organisational capability.

This pattern aligns with the broader DevSecOps trend: the recognition that security cannot be a gate at the end of a deployment pipeline if organisations want to move at DevOps speed.

Key Takeaways for DevOps Practitioners and Leaders

• Audit your actual maturity, not your assumed maturity. The executive perception gap is real and widespread. Use automated measurement and objective metrics to establish a baseline before planning your next phase of adoption.
• Focus on scaling, not just starting. Most organisations have at least one team doing DevOps well. The hard work is replicating that success across departments—and that requires deliberate investment in shared tooling, documentation, and cross-team collaboration.
• Treat security automation as a first-class practice. The 24x gap between high and low maturity organisations on security policy automation is a strong signal. If your security configurations are still manual or audit-driven, closing that gap should be a near-term priority.
• Bridge the leadership gap with data. If executives and teams disagree on how mature DevOps practices are, the answer is not a better presentation—it is better instrumentation. Dashboards, deployment frequency metrics, and change failure rates give everyone the same ground truth.
• Accept that progress is non-linear. Stalls and setbacks are normal. Treating them as signals to refine the approach—rather than evidence that DevOps does not work—is characteristic of organisations that eventually reach High maturity.

Industry Voices

Darryl McKinnon, Vice President and Managing Director for APJ at Puppet, noted at the time of the report’s release: “DevOps practices are becoming well established, yet many organisations continue to struggle to scale the pockets of DevOps success across multiple teams and departments. Whilst more organisations are recognising the opportunity to adopt DevOps, particularly at the leadership level, there are clearly some barriers to success that have to be addressed first. In the face of rapid digitalisation, mapping out the journey and better defining those challenges are a key step in enabling that success.”

Andi Mann, then Chief Technology Advocate at Splunk, added: “This year’s report findings validate that foundational practices have a profound impact on an organisation’s overall DevOps evolutionary journey and are key to scaling successes no matter how mature the DevOps transformation is within the organisation.”

Bottom Line

The 2018 State of DevOps Report offers a sobering but actionable picture. Being stuck at Medium is the norm—not a sign of unique dysfunction. The organisations that break through to High do so not by adopting new tools in isolation, but by embedding collaboration, measurement, and automation (including security automation) into the fabric of how they operate. Understanding which stage you are in, and what practices characterise the next stage, is the most reliable starting point for making real forward progress.

Why DevOps Adoption Keeps Growing

Organizations of every size continue to pursue DevOps practices, driven by a common set of pressures: shrinking time-to-market windows, rising quality expectations, the need to cut operational costs, and the imperative to stay competitive in increasingly digital markets. The shift toward cloud-native infrastructure, agile frameworks, and digital business models has reinforced the urgency—but technology alone does not deliver the promised acceleration. The missing ingredient is almost always people: specifically, how well teams collaborate across traditional boundaries.

DevOps is not a tool or a product. It is a combination of cultural practices, organizational structures, and automation capabilities that must be assembled differently in every company. That is precisely why it defies a universal recipe.

Leadership Is the Most Critical Success Factor

Depending on company size and complexity, a meaningful DevOps transformation can take months—often years. From practical experience across many organizations, the single most important factor is engaged leadership. Without active sponsorship from senior leaders, silos persist, budgets stall, and cross-team initiatives lose momentum.

Effective leadership support enables organizations to:

• Break down entrenched organizational silos between development, operations, security, and business teams.
• Create flexible, dynamic workflows that span multiple teams simultaneously.
• Align software delivery speed with the ability to respond to changing customer demands.
• Sustain momentum through the inevitable resistance that accompanies cultural change.

Without this top-down commitment, even the most technically sophisticated DevOps toolchain will produce marginal results.

Implementing DevOps Is Unique to Every Company

There is no single DevOps playbook that transfers cleanly from one organization to another. Every company brings its own history, culture, risk tolerance, and way of working. Two organizations can adopt the same CI/CD toolchain and end up with completely different outcomes because the human and organizational contexts differ.

DevOps is best understood as an amalgamation of several distinct dimensions:

• Technology and automation: CI/CD pipelines, infrastructure-as-code, monitoring, and observability tooling.
• Lean process design: Reducing waste, minimizing batch sizes, and streamlining feedback loops.
• Cultural transformation: Building shared ownership, psychological safety, and a blameless post-incident culture.
• Organizational structure: Restructuring teams around products rather than functions, often using models like team topologies.

The weighting of each dimension varies by organization. A startup with 20 engineers needs a very different approach than a regulated financial institution with thousands of developers across multiple geographies. Copying another company’s implementation without adapting it to your own context is one of the most common reasons DevOps transformations stall.

The Challenge of Scaling Beyond the Pilot

The trajectory of DevOps adoption closely mirrors what the industry saw with agile: most organizations begin with a small, often hand-picked pilot team, demonstrate early wins, and then struggle to scale those results enterprise-wide. The pilot succeeds in part because it operates outside normal organizational constraints. Scaling reintroduces all of those constraints simultaneously.

Common barriers that emerge at the scaling stage include:

• Legacy systems and monolithic architectures that resist continuous delivery practices.
• Inconsistent tooling choices across teams that create integration overhead.
• Middle-management layers that have not been aligned to the new way of working.
• Lack of platform engineering capability to provide self-service infrastructure to product teams.
• Insufficient investment in developer enablement and training.

Automation tools bring organizations closer to continuous integration and continuous delivery, but the gap between a functional CI/CD pipeline and a truly continuous delivery culture is significant. Many teams achieve automated builds and tests while still releasing infrequently due to approval bottlenecks or release-night rituals that have not been re-examined.

Uneven Adoption Across Application Types

DevOps adoption is not uniform across application portfolios within the same organization. Mobile and greenfield applications typically see earlier and deeper adoption because they were often built without the legacy constraints that affect older systems. Core enterprise platforms, ERP systems, and mainframe workloads frequently lag behind, creating a two-speed IT environment that itself becomes a source of friction.

Organizations need strategies for both ends of this spectrum: accelerating delivery for modern workloads while carefully managing risk and compliance for legacy systems. Attempting to force a single delivery model across all application types rarely succeeds.

Measuring DevOps Success Meaningfully

A persistent challenge is defining what DevOps success actually looks like for a given organization. Deployment frequency and lead time for changes are useful technical indicators, but business leaders also need metrics that connect delivery performance to outcomes:

• Time to restore service after an incident, which reflects operational resilience.
• Change failure rate, which indicates delivery quality under speed.
• Product revenue or customer satisfaction tied to specific delivery improvements.
• Process efficiency gains measured as reduction in manual handoffs or approval cycle time.
• Innovation rate, such as the number of experiments or new features shipped per quarter.

Without connecting DevOps metrics to business outcomes, transformation programs risk being judged solely on tool adoption rather than value delivered. The metrics framework should be established early and revisited as the organization matures.

Learning from Others Without Copying Them

There is genuine value in studying how other organizations have navigated their DevOps journeys. Case studies, industry conferences, and community sharing surface patterns and anti-patterns that can accelerate your own thinking. However, the key discipline is translation: understanding why a practice worked in another context before deciding whether and how to adapt it to your own.

Two organizations using the same automation platform will have different team structures, different governance requirements, different release cadences, and different definitions of done. The tooling is the easiest part to replicate. The organizational learning embedded in how those tools are used, governed, and continuously improved is the harder part—and it cannot be copied directly.

Key Takeaways for DevOps Leaders

• Secure leadership commitment first. Technical initiatives without executive sponsorship will plateau quickly.
• Treat your DevOps adoption as a product. Define a roadmap, set measurable goals, and iterate based on feedback.
• Design for your context. Study best practices from peers, but adapt rather than copy.
• Plan explicitly for scaling. A pilot that works with one team will require deliberate investment in platform engineering and enablement to scale across the enterprise.
• Connect metrics to business outcomes. Deployment frequency matters, but it must ultimately tie back to customer value and business performance.
• Be patient. Fundamental shifts in how software is created, delivered, and maintained take years, not quarters. Sustained momentum matters more than rapid early wins.

This article examines what full-stack monitoring encompasses, why enterprises are adopting it, and the key drivers pushing Site Reliability Engineering (SRE) and DevOps teams toward unified, centralized monitoring solutions.

What Is Full-Stack Monitoring?

Full-stack monitoring is the practice of collecting, correlating, and acting on telemetry data from every layer of your technology stack — from physical or virtual infrastructure all the way through to the end-user experience. It breaks down the silos that exist when separate teams monitor infrastructure, applications, and user experience in isolation.

A complete full-stack monitoring strategy typically covers five capability areas:

1. Infrastructure monitoring — Visibility into servers, networks, containers, cluster orchestrators (e.g., Kubernetes), cloud resources, middleware, application servers, web servers, and databases.
2. Application performance monitoring (APM) — Log monitoring and analytics, synthetic transaction monitoring, SQL transaction tracing, metric-to-log correlation, end-user experience monitoring, profiling, and code-level transaction tracing.
3. Cross-environment visibility — End-to-end monitoring across on-premises, cloud, and hybrid workloads presented through a centralized dashboard, giving operations teams a single pane of glass.
4. Alerting, analysis, and automated remediation — Using instrumentation data alongside IT service management (ITSM) platforms, ChatOps tools, and collaboration software to detect, triage, and resolve incidents faster.
5. Predictive analytics — Applying machine learning to monitoring data to derive operational insights, forecast capacity demands, and detect anomalies before they become incidents.

Key Drivers for Adopting Full-Stack Monitoring

A combination of business, technical, and cultural pressures is pushing enterprises toward full-stack monitoring. Understanding these drivers helps justify investment and shapes tooling decisions.

Business Agility and Deployment Frequency

Modern competitive markets require frequent releases. Without monitoring that keeps pace with continuous delivery pipelines, teams lose visibility into how each deployment affects system behaviour and user experience.

Application Reliability and Revenue Protection

Downtime has a direct financial cost. Applications are expected to be reliable, available, and scalable at all times. Full-stack monitoring enables SRE teams to catch degradation early, enforce Service Level Objectives (SLOs), and minimise mean time to recovery (MTTR).

Network Bandwidth and Latency Bottlenecks

Bandwidth constraints can silently degrade application performance. Network-level deep monitoring is required to identify bottlenecks before they escalate into user-facing incidents or business loss.

Failures at Any Layer

Failures can occur at the hardware, OS, container runtime, application, or dependency level — and often go unnoticed until end users report problems. Monitoring from multiple sources at different layers ensures failures surface quickly and with enough context for rapid remediation.

Application Complexity and Third-Party Dependencies

Modern applications depend on dozens of third-party components, external APIs, and distributed services. When any one dependency underperforms, application quality suffers. Full-stack monitoring captures these dependency chains and highlights where degradation originates.

Cloud-Native and Multi-Cloud Architectures

Cloud-native applications are inherently multi-tiered, often mixing PaaS and IaaS workloads across multiple cloud providers. Monitoring must span these distributed, hybrid environments and provide consistent visibility regardless of where a workload runs.

Containers and Orchestration

Virtualisation and container technologies such as Docker and Kubernetes create highly dynamic, ephemeral environments where instances spin up and down rapidly. Traditional host-based monitoring cannot track these workloads effectively. Orchestration-level and container-level monitoring are essential to maintain visibility in these environments.

Lack of Centralised Visibility and Stakeholder Buy-In

Fragmented monitoring tools produce fragmented data, making it difficult to build a shared understanding of system health across development, operations, and business stakeholders. SRE teams need centralised monitoring data to push back on risky releases, calculate acceptable risks, and present relevant dashboards to different audiences — from engineers to line-of-business owners.

Capacity Forecasting and Anomaly Detection

IT operations teams need to predict how applications will behave under varying load conditions. Machine learning applied to historical monitoring data and usage patterns can forecast capacity requirements and flag anomalies before they affect end users.

High-Volume, Multi-Source Data Correlation

Metrics, logs, and traces are collected from dozens of stack components simultaneously. Without automated correlation, engineers spend excessive time manually triaging data to find the root cause of an issue. Full-stack monitoring tools that provide built-in correlation reduce toil and accelerate incident resolution.

Infrastructure-as-Code and Configuration Risk

Modern infrastructure is provisioned, configured, and decommissioned through automation scripts. Configuration errors introduced through IaC pipelines can propagate quickly if not caught early. Monitoring should extend across the full resource lifecycle — from provisioning through active use to decommissioning — to catch configuration drift and misconfigurations before they cause outages.

End-User Perspective and Business Metrics

Traditional monitoring tools often lack visibility into the actual end-user experience and business-level metrics. New-generation full-stack monitoring platforms address this gap by combining real-user monitoring (RUM), synthetic monitoring, and business KPIs into a unified view — enabling faster post-mortems and more automated incident response.

The Shift from Traditional IT Operations to Digital Operations

The combined pressure of business agility requirements, reliability expectations, capacity forecasting needs, and end-user experience demands is fundamentally reshaping IT operations. Traditional reactive monitoring — where teams respond to alerts after something breaks — is being replaced by proactive and predictive digital operations models aligned with SRE principles and DevOps practices.

Full-stack monitoring is the technical foundation that makes this shift possible. By providing comprehensive, correlated, and centralised visibility across every layer of the stack, operations teams can move from firefighting to systematic reliability engineering.

What Comes Next

Understanding why full-stack monitoring is necessary is the starting point. The next steps involve evaluating monitoring tool options and designing a full-stack monitoring architecture suited to your environment — covering tool selection criteria, data collection strategies, dashboard design, alerting frameworks, and integration with incident management workflows.

Practitioner quotes below were originally compiled by enterprisersproject.com. Attribution has been preserved.

1. Trying to Copy High-Scale Unicorns

It is tempting to look at organisations like Netflix or Amazon and try to replicate their release cadence — shipping dozens of times a day — regardless of whether that pace creates real business value for your users.

“DevOps professionals need to kick the habit of trying every fad, tool, and trick to deploy several times a day like Netflix and Amazon are famous for doing. There is no business value in continuous deployment if your company doesn’t observe the impact of each small change on the way end users behave. Ultimately, DevOps has to move away from being ‘cool’ to being ‘relevant.'”

Vinayak Joglekar, CTO and co-founder, Synerzip

Continuous deployment is a means to an end, not an end in itself. Before optimising deployment frequency, establish the feedback loops and instrumentation needed to measure real user impact. Without that foundation, faster releases just mean faster accumulation of unvalidated changes.

2. Treating Speed as the Only Metric

“One DevOps habit to drop is the constant focus on releasing faster, without improving quality. For example, you should not drive deployment automation without any automated tests. It’s a sign that everyone understands the automation aspect of DevOps, but often misses the necessary cultural groundwork, like having developers, testers, and operations teams building automation collaboratively.”

Ian Buchanan, Developer Advocate, Atlassian

Automation without quality gates is just a faster path to production failures. A healthy DevOps pipeline pairs deployment automation with a comprehensive automated test suite — unit, integration, and end-to-end — so that speed and reliability improve together rather than trading off against each other.

3. Bolting Security On at the End

“There’s a tendency among many product organisations to be myopic about how they approach DevOps; the emphasis is on pushing product fast, but that comes at the cost of ignoring security throughout the development lifecycle and into production. DevOps and SecOps should cross-pollinate and sprinkle their expertise throughout, which would result in an improved approach: DevSecOps.”

John Martinez, VP of Customer Solutions, Evident.io

When security reviews happen only after code is written, teams spend cycles on rework and are permanently in catch-up mode. The DevSecOps model integrates security checkpoints, automated scanning, and threat modelling into every stage of the pipeline — from design through deployment. This is not just a tooling change; it requires hiring practices and role definitions to evolve so that security expertise is distributed across the engineering organisation.

4. Allowing Development Silos to Persist

“The most common roadblock I’ve seen in working with Fortune 2000 organisations is that development isn’t just one team but many. Everyone is solving their own problems within their own silo, so operations struggles to unify the activity into a consistent, repeatable process.”

TJ Randall, VP of Customer Success, XebiaLabs

Agile and CI/CD improvements implemented team-by-team, without cross-team coordination, produce a patchwork of incompatible processes. Operations ends up manually bridging the gaps. Breaking down silos requires explicit organisational investment: shared standards, cross-team working groups, and incentives that reward system-wide outcomes rather than local optimisation.

5. Over-Standardising Tooling

“Creating too many standards around tools and not letting teams experiment with their own tools limits success. You should set some guardrails around architecture and how infrastructure is configured, but allow teams to choose technologies that will be the most effective for their particular needs.”

Matthew Perry, Director of IT Operations, WWT Asynchrony Labs

There is a meaningful difference between architectural guardrails — which protect interoperability and compliance — and mandating every tool a team uses. Lean principles emphasise enabling flow through the value stream, which sometimes means letting a team choose a build tool or testing framework that fits their workflow, even if it differs from another team’s choice. Experiment within guardrails; standardise where it matters.

6. Believing a Single Tool Is Your “DevOps Solution”

“One of the worst habits keeping companies from succeeding at DevOps is when they think a tool is their ‘DevOps solution.’ DevOps is a mix of culture, process, and tools — with the tools acting as support for both culture and process.”

Justin Rodenbostel, Executive Director of Open Source Application Development, SPR

Purchasing a CI/CD platform, a monitoring solution, or a container orchestration system does not make an organisation DevOps. Tools are enablers. Without cultural alignment — shared ownership, psychological safety, blameless post-mortems — and mature processes, even the best toolchain will fail to deliver its potential.

7. Failing to Automate Security Processes

“Security’s still too much of a silo in DevOps. Automate security processes as much as possible — shifting them ‘left’ (earlier) in the development pipeline. And work to create a security mindset in your developers. Most will never become true experts in security but, by involving them in security exercises, you can help to encourage an environment where security is everyone’s job.”

Gordon Haff, Technology Evangelist, Red Hat

Manual security gates are a bottleneck that teams learn to work around. Automating static analysis, dependency scanning, secrets detection, and infrastructure compliance checks directly in the CI pipeline removes friction while raising the baseline security posture. Inviting security engineers to design these checks collaboratively with developers accelerates adoption and builds shared ownership.

8. Assigning DevOps Responsibility to One Person or Team

“The leading derailment factor is assigning DevOps responsibility to one person or team. For DevOps transformation to truly succeed, everyone should be involved and engaged. Redefine success from ‘feature shipped’ to ‘satisfied customer.'”

Ofer Karp, Senior VP of Engineering, Perfecto

A “DevOps team” that acts as a separate unit — handing off pipelines and infrastructure to product teams — recreates the very silo that DevOps was designed to eliminate. Genuine transformation means developers take on broader responsibility for deployment, monitoring, and operational support, while operations teams participate earlier in design and architecture decisions. This is an organisational change that spans planning, architecture, testing, deployment, and customer support.

9. Not Following Through on Process Discipline

“Our worst habits are not defining requirements to the core, not following sprints, and not understanding delays in the dev cycle. We’ll be following an agile process and assigning time for feedback and suggestions from the right parties at the right stage in the project.”

Thomas Varghese, DevOps Manager, Day Translations

Speed pressure frequently causes teams to skip requirements definition, sprint ceremonies, and retrospectives — the very practices that make iteration sustainable. Underdefined requirements generate rework; skipped retrospectives allow recurring delays to go unanalysed. Building structured feedback time into every sprint protects long-term velocity even when it feels like overhead in the short term.

10. Failing to Secure the Entire Delivery Pipeline

“Secure the supply chain too. It’s not just about worrying that your product in production is secure from attack, but that the supply chain of third-party components and tools in the DevOps pipeline are also secure and deployed and maintained securely. Also, the idea of anti-fragility is important — not deploying systems that are incapable of breaking, but assuming they will, and even purposefully making them fail, so as to see how the system responds and self-heals. Think of Kubernetes autoscaling or auto-relaunching failed pods.”

William Henry, Open Source, DevOps, and Cloud Strategist, Red Hat

Production application security is well understood, but the build pipeline itself — source repositories, CI runners, artifact registries, third-party dependencies — represents an equally critical attack surface. Supply chain compromises can introduce malicious code before it ever reaches a security scanner that inspects production. Beyond hardening the pipeline, designing for anti-fragility means proactively testing failure scenarios (chaos engineering) so that self-healing mechanisms, such as container restarts or autoscaling, are proven to work before an incident forces the issue.

Key Takeaways

• Relevance over mimicry: Match your release cadence and tooling choices to actual business needs, not industry celebrity.
• Quality and speed together: Automated testing must accompany deployment automation or you are simply accelerating failures.
• Shift security left: Integrate security into every stage of development; do not treat it as a final checkpoint.
• Break silos deliberately: Cross-team collaboration requires explicit organisational effort, not just goodwill.
• Guardrails, not handcuffs: Set architectural standards where interoperability demands it; give teams autonomy elsewhere.
• Culture and process first, tools second: No tool alone constitutes a DevOps transformation.
• Distribute ownership: DevOps is an organisational model, not a job title or a team.
• Process discipline enables speed: Sprint ceremonies and requirement definition are investments, not overhead.
• Secure the supply chain: The delivery pipeline is as important a security boundary as the production environment.
• Design for anti-fragility: Assume components will fail; build and test the recovery mechanisms proactively.

Why Scaling DevOps in Large Organizations Is Harder Than It Looks

For small teams, adopting DevOps is often straightforward: fewer stakeholders, tighter feedback loops, and development and operations skills that may already sit in the same room — or the same person. The cultural shift happens organically because the distance between intent and action is short.

Large enterprises face a fundamentally different challenge. Complex delivery programs, entrenched organizational structures, separate reporting lines for development and operations, and risk-averse governance processes all create friction. Plenty of organizations have launched DevOps transformation programs and stalled — or failed outright.

Yet the upside is real: faster, more reliable software delivery, reduced deployment risk, and shorter feedback cycles between engineering and the business. The question is how to get there at scale without repeating common mistakes.

Start With Your Bright Spots

In almost every large organization, at least one team finds a way to make DevOps work on its own — often on a greenfield project, led by a progressive engineering manager, with the freedom to choose its own tools and ways of working. These teams are your proof of concept.

The temptation is to simply copy what that team did and roll it out broadly. This rarely works cleanly. Context matters enormously: the team’s composition, the nature of the project, the support they received, and the constraints they didn’t face. Replicating outcomes requires understanding the underlying conditions, not just the practices.

With that in mind, here are four key lessons drawn from DevOps success stories that genuinely translate to enterprise scale.

Lesson 1: Don’t Force DevOps as a Concept

Mandating DevOps from the top down — telling teams they will “do DevOps” without explaining why or giving them agency — is one of the most reliable ways to generate resistance and cynicism. Engineers in particular tend to respond poorly to cultural labels imposed without context.

A more effective approach is to show teams how DevOps practices make their day-to-day work better: fewer late-night incidents, faster feedback on pull requests, less time waiting on manual approvals. Frame the conversation around outcomes that matter to the team, not around the transformation program itself.

It is also worth acknowledging that not every team member will be equally interested in learning new practices immediately. Creating space for people to move at different speeds — while still moving forward — is more sustainable than an all-or-nothing rollout. Atlassian, for example, publicly documents team health check and alignment techniques (referred to as the Team Playbook) as one way to surface where a team actually is before prescribing where they need to go.

Lesson 2: Learn DevOps by Practicing It, Not Studying It

Workshops, certifications, and reading lists have their place, but they are not sufficient to change how engineers work. Mindset shifts follow behavioral change — not the other way around. Teams that practice DevOps, make mistakes in a safe environment, and iterate on what they learn build lasting habits. Teams that attend a two-day class and return to the same workflow do not.

One approach described in the source material comes from a large telecommunications company: structured programs where teams applied DevOps practices to their own real work through a guided series of sprints on a compressed timescale. The goal was to give teams direct experience of working differently — faster feedback loops, automated testing, cross-functional collaboration — so they could internalize what the change actually feels like before scaling it.

Practical elements worth including in such programs:

• Running a small feature through a full CI/CD pipeline the team builds themselves
• Conducting a blameless post-incident review on a recent real incident
• Pairing developers with on-call engineers for a rotation
• Measuring and discussing deployment frequency and lead time before and after

Lesson 3: Treat DevOps Adoption as a Journey, Not a Destination

Teams that aim for full DevOps maturity in a single leap almost always get lost or burned out. DevOps adoption is iterative — much like the software development practices it promotes.

Providing teams with a clear, graduated maturity model helps in several ways. It allows teams to accurately assess where they are today, set a realistic next milestone rather than aiming for the theoretical end state, and measure progress over time. It also reduces the anxiety that comes from being compared to a high-performing team that has had years to develop its practices.

The source material references a Fortune 100 insurance company that distributed a practical guide to help teams self-assess, plan incremental improvements, and choose from a curated set of supported tools. Whether you use a formal maturity model, a lightweight checklist, or a tool like the DORA Four Key Metrics (deployment frequency, lead time for changes, mean time to restore, change failure rate) as benchmarks, the principle is the same: give teams a map before you ask them to navigate.

Lesson 4: Build a Common Collaboration Layer Across Teams

Cultural change and tooling are not separate concerns — they reinforce each other. As DevOps practices spread across an organization, a shared toolchain and common collaboration layer become strategically valuable.

Individual teams working on mobile apps, web services, and back-end systems will have unique pipeline requirements. But nearly all of them share the same fundamental activities: planning work, tracking issues, reviewing code, running tests, deploying software, and monitoring in production. Standardizing on a common platform for these activities — even if specialized tools differ at the edges — delivers compounding benefits:

• Onboarding speed: New teams and new engineers can start contributing faster when the baseline tooling is familiar.
• Engineer mobility: Moving people between teams is less disruptive when workflows and tooling are consistent.
• Cross-functional visibility: Security, compliance, portfolio management, and operations teams can interface with fewer systems and use shared language, reducing coordination overhead.
• Economies of scale: Licensing, support, and integration costs fall when the tool sprawl is managed centrally.

The success patterns from one high-performing team become transferable when the infrastructure that enabled them is available to others. At that point, DevOps stops being the property of a single team and starts being an organizational capability.

Putting It Together: From Isolated Wins to Organizational Capability

The four lessons above share a common thread: sustainable DevOps transformation is grown, not installed. It requires respecting team autonomy, creating genuine practice opportunities, setting realistic milestones, and building shared infrastructure that makes good practices the path of least resistance.

When this works, the effect is cumulative. Engineering teams ship faster and more reliably. Other business functions — product, security, compliance — gain visibility and confidence. The feedback loop between engineering and business outcomes shortens. That is when the core promise of DevOps — not just faster deploys, but better organizational alignment around software delivery — becomes tangible.

The hardest part is not understanding what DevOps success looks like. The hardest part is being patient and deliberate enough to build it in a way that lasts.

The latest solution from Redgate Software, known for its industry leading database development tools, promises to resolve much of the headache the General Data Protection Regulation (GDPR) is already causing. SQL Provision launches today and allows users to create copies of SQL Server databases in seconds which use a fraction of disk space, and mask any sensitive data to address data privacy and protection issues.

The provisioning of database copies to improve the efficiency and quality of database development and testing is becoming increasingly common as companies and organizations seek to introduce DevOps practices. Working with a copy of the production database enables developers to find errors faster and prevents problems when changes are deployed.

It does, however, take a long time and huge amounts of disk space to provision copies, so old copies are often used, which become increasingly unreliable over time and are difficult to keep track of, especially where multiple developers are involved. Coupled with this, the implementation of the GDPR in May 2018 is making the protection of sensitive data a priority for almost every company and organization.

SQL Provision has been created to support a database DevOps approach while keeping GDPR compliance central to the process. Using Data Masker, sensitive data can be anonymized or replaced with realistic data, helping to satisfy the requirements of regulations like GDPR, HIPAA and SOX. The virtual cloning technology of SQL Clone can then create full database copies in seconds using just a few MB of local disk storage, giving developers a truly realistic copy, while keeping confidential data protected.

The masking and provisioning of database copies is also managed from one place, so organizations can control their distribution and know when copies were provided, to which developers or teams of developers, and the precise data that was masked.

“The closer we get to GDPR, the bigger the issue of data privacy becomes,” says Richard Macaskill, Redgate Product Manager. “Companies need solutions that free them to take advantage of DevOps in their database development process, yet enable them to be truly compliant.”

This is particularly important because Redgate’s recent SQL Server Database Provisioning Report found that 83% of respondents agreed or strongly agreed that it is desirable to use production data in development and testing. With SQL Provision, they can continue to do so, knowing that data security, regulatory compliance and storage concerns have been accommodated.

Redgate has also deliberately priced SQL Provision so that small and medium sized enterprises can take advantage of it alongside large corporations. The tiered pricing model is based on the total size of the databases organizations need to provision, rather than the number of users.

As Richard Macaskill concludes: “Provisioning solutions have typically been restricted to big companies in the past. Every company and organization of whatever size will need to comply with the GDPR, so it makes sense to give them the opportunity to do so.”

The development teams behind Data Masker and SQL Clone which comprise the SQL Provision solution are continuing to refine the tools to streamline data masking and database provisioning yet further.

The Problem With Defining DevOps

Buzzwords accumulate definitions the way software accumulates technical debt — slowly, then all at once. DevOps is no exception. When Red Hat’s Josh Ranoa opened his “Open Innovation: Make DevOps a Reality” panel at a Red Hat Government Symposium by asking each panelist to define DevOps, the audience got not one answer, but several — each emphasizing a different dimension of the same concept.

The panelists — all practitioners actively implementing DevOps within their respective federal agencies — did not fundamentally disagree. They simply each saw fit to highlight what mattered most from their own operational vantage point. That divergence is itself revealing: DevOps is not a single tool or process. It is a layered practice, and which layer you emphasize depends on where you sit in an organization.

A Baseline Definition

Amazon Web Services offers one of the most widely cited compact definitions: “DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.”

This definition works well as a starting point because it captures the three essential ingredients:

• Cultural philosophies — shared ownership, blame-free retrospectives, cross-functional collaboration
• Practices — continuous integration, continuous delivery (CI/CD), infrastructure as code, automated testing
• Tools — version control systems, build pipelines, monitoring platforms, container orchestration

Critically, none of these three elements works well in isolation. An organization can adopt every DevOps tool on the market and still fail to ship software faster if its culture penalizes failure or siloes its engineering and operations teams.

How Federal Practitioners Define It

DevOps as Organizational Culture

Steven Grunch, manager of enterprise cloud services at the United States Citizenship and Immigration Services (USCIS), framed DevOps primarily as a cultural shift:

“I define [DevOps] as a culture of collaboration between different groups, whether that is the traditional developers and operations, or whether it’s between the business and IT organization. This idea that business and IT are two different things needs to change. We’re all trying to move in the same direction.”

Steven Grunch, USCIS

This framing is particularly relevant in government contexts, where organizational silos between program offices, IT departments, and procurement teams are often entrenched by policy, budget cycles, and years of institutional habit.

DevOps as Continuous Delivery

Simmons Lough, a self-described DevOps evangelist at the U.S. Patent and Trademark Office (USPTO), zeroed in on outcomes rather than process or culture:

“I like to concentrate on continuous delivery. I kind of look at it as fast, frequent deployments to production without taking shortcuts.”

Simmons Lough, USPTO

The phrase “without taking shortcuts” is important. Continuous delivery is not about rushing code into production; it is about building enough automated testing and validation into the pipeline that deploying frequently becomes safe and repeatable. In a government context — where system outages can affect millions of citizens — this distinction is especially critical.

DevOps as a People-Centric Discipline

Jennifer Hoover, a digital services expert in the office of the CTO at the Department of Homeland Security (DHS), offered arguably the most expansive definition:

“I always think of DevOps mostly as a people-centric focus. So many times I’ve been at conferences and panels and people talk about DevOps in a very technological way, where it’s focused on technology. But DevOps is so much bigger than technology. DevOps is about people, processes, technology — bringing that all together and then looping in innovation as part of that so we can move better and faster so we can deliver the mission for customers.”

Jennifer Hoover, DHS

Hoover’s emphasis on people is a useful corrective for organizations that treat DevOps primarily as a tooling problem. Automation pipelines and container orchestration platforms are means, not ends. Without investing in training, psychological safety, and cross-functional team design, even the best toolchain will underperform.

DevOps as Common Sense

Dave Gray, director of the division of infrastructure services at the Social Security Administration (SSA), got the biggest reaction from the audience with the most stripped-down take:

“I wish I could say that I thought of this myself, but one of my coworkers said ‘DevOps is really just another term for common sense.'”

Dave Gray, Social Security Administration

Reductive as it sounds, this framing has real merit. Many DevOps principles — communicate early, test often, ship small changes, fix problems before they compound — are things experienced engineers have always known to be good practice. What DevOps provides is a structured vocabulary and a set of proven practices that make those instincts repeatable and scalable across large organizations.

Why Government Adoption of DevOps Is Significant

Federal agencies operate under constraints that most commercial organizations do not face: procurement regulations, legacy infrastructure, strict security compliance requirements (such as FedRAMP and FISMA), multi-year budget cycles, and public accountability. These constraints make the case for DevOps both more complex and more compelling.

More complex, because adopting continuous delivery in an environment with long authority-to-operate (ATO) processes requires rethinking how security reviews are integrated into the pipeline — the concept sometimes called DevSecOps. More compelling, because the cost of slow, waterfall-style software delivery in government is borne directly by citizens who depend on those systems.

The fact that agencies like USCIS, USPTO, DHS, and SSA are actively discussing and implementing DevOps practices — not just evaluating them — signals meaningful momentum in federal digital modernization efforts.

Key Takeaways

• DevOps has no single canonical definition, but all credible definitions share core elements: collaboration, automation, continuous delivery, and feedback loops.
• Culture is as important as tooling. Organizations that invest only in CI/CD pipelines without addressing team structure and incentives will see limited results.
• Continuous delivery means safe, frequent releases — not cutting corners on testing or security.
• Government adoption faces unique constraints — compliance, procurement, legacy systems — that require adapting DevOps practices rather than copying them wholesale from commercial software companies.
• At its core, DevOps codifies common sense: communicate across teams, automate repetitive work, test early, and ship small incremental changes.

Overview

In October 2017, Atlassian announced the release of Bitbucket Server 5.4 and Bamboo 6.2, two updates focused on making DevOps workflows more practical for large enterprises and regulated industries. Bitbucket Server is Atlassian’s self-hosted Git code management solution, while Bamboo handles continuous integration (CI) and release management.

The central challenge Atlassian addressed with these releases is the tension that exists in large organizations between developer productivity and the governance, security, and scale requirements that regulated environments demand. Both products received targeted enhancements to reduce friction in the software delivery pipeline.

Key New Features

Bamboo Specs for Bitbucket Server

Bamboo Specs is Atlassian’s configuration-as-code feature for Bamboo. It allows teams to define their CI/CD pipeline configuration in code rather than through a GUI, enabling bulk changes, peer code review, version tracking, and rollbacks of pipeline definitions — the same practices applied to application code.

With Bamboo 6.2, Spec files can now be stored directly in Bitbucket Server repositories. This tighter integration means pipeline configuration lives alongside application code, making it easier to audit changes, enforce reviews via pull requests, and revert problematic configurations using standard Git operations.

Bamboo Smart Mirroring Support

Bitbucket Server’s Smart Mirroring feature allows geographically distributed teams to clone from a nearby mirror rather than from a central server, reducing clone times and network load. Bamboo 6.2 extends Smart Mirroring support to build agents, so CI builds can take advantage of local mirrors rather than hitting the primary repository server on every build trigger.

According to Atlassian, this is valuable not only for globally distributed teams but also for organizations with co-located infrastructure that experience activity spikes from large fleets of build agents. Mirrors help spread the load during peak build periods.

Webhook Support in Bitbucket Server

Bitbucket Server 5.4 introduced native webhook support, enabling teams to integrate third-party tools into their DevOps toolchain more easily. Webhooks allow Bitbucket Server to send HTTP POST payloads to external services — such as chat tools, monitoring platforms, or deployment systems — when repository events occur (e.g., pushes, pull request updates).

This reduces the need for polling-based integrations and makes it simpler to build event-driven pipelines that connect Bitbucket Server to the broader toolchain without requiring custom plugins for every integration.

Scaling DevOps in Large Organizations

Beyond the headline features, both releases included improvements specifically aimed at operating DevOps tooling at enterprise scale:

• Bamboo project-level permissions: Administrators can now control access at the project level in Bamboo, making it easier to manage permissions across large numbers of build plans without configuring each plan individually.
• GVFS support in Bitbucket Server: Support for the Git Virtual File System (GVFS) — designed to handle very large repositories efficiently — was added to Bitbucket Server 5.4, enabling teams working with massive codebases to maintain reasonable Git performance.
• New artifact handler options in Bamboo 6.2: Additional configuration options for artifact handlers give teams more flexibility in how build artifacts are stored and retrieved, important when operating CI infrastructure at significant scale.
• Agent bootstrapping proxies in Bamboo 6.2: New proxy support for agent bootstrapping helps organizations manage large build agent fleets in network-restricted or segmented environments.

Why This Matters for DevOps Teams

The combination of tightly integrated version control and continuous integration is foundational to modern DevOps practice. The features in these releases address three recurring pain points in enterprise DevOps adoption:

1. Configuration drift and auditability: Storing Bamboo Specs in Bitbucket Server brings pipeline definitions under the same version control discipline as application code.
2. Geographic distribution: Smart Mirroring for builds reduces one of the most common performance complaints in globally distributed engineering teams — slow repository clones blocking CI throughput.
3. Toolchain integration: Native webhooks lower the barrier to connecting Bitbucket Server to the rest of an organization’s toolchain without relying solely on vendor-supplied plugins.

For teams running self-hosted Atlassian infrastructure, these updates represented a meaningful step toward reducing the operational overhead of maintaining DevOps workflows at scale while preserving the control and security that regulated environments require.

Summary of Changes

What Does the Term DevOps Mean?

DevOps is a compound of software development and IT operations. It emerged as a grassroots movement of developers and operations professionals who wanted to change the way organisations build, deliver and run software. The core idea is straightforward: the two disciplines that have traditionally worked in separate silos — development and operations — need to collaborate continuously rather than hand off work over a metaphorical wall.

In practice, DevOps encompasses three interconnected dimensions:

• Culture: shared responsibility for software delivery and reliability across development and operations teams.
• Process: lean, iterative workflows with short feedback loops, continuous integration, and continuous delivery.
• Automation: tooling that reduces manual toil, enforces consistency, and accelerates deployment pipelines.

For management, the most important dimension is culture. Technology can be procured; cultural change must be led.

Why Adopting DevOps Practices Matters

Modern customers expect software-driven services to be reliable, fast and improving continuously. That expectation puts pressure on every organisation — regardless of industry — to deliver working software more frequently and at higher quality. At the same time, computing infrastructure is growing more complex, spanning on-premises systems, public cloud platforms, containers and microservices.

The conventional approach to software delivery was not designed for this environment. In a traditional model:

• Developers are incentivised to ship new features as quickly as possible. Their accountability ends when code is handed to the operations team.
• Operations teams are incentivised to keep infrastructure stable. They inherit software they did not build, under pressure to deploy it safely while also managing costs, user accounts, capacity and security.

These objectives are structurally opposed. Developers want to change things; operations teams want to keep things stable. The resulting friction causes slow deployments, poor reliability and organisational dysfunction that no amount of tooling alone can fix. The root cause is misaligned incentives and a lack of shared accountability — a cultural problem that requires a cultural solution.

Management Has a Powerful Role to Play

The annual State of DevOps Report, produced by Puppet and co-authored with industry researchers, has surveyed tens of thousands of technical professionals over multiple years and consistently finds that leadership behaviour is one of the strongest predictors of IT and organisational performance. The 2017 edition highlighted several findings relevant to management:

• Automation drives performance: High-performing organisations had automated a significantly greater proportion of their configuration management processes than low performers, allowing them to spend far less time on manual, error-prone tasks that slow down delivery.
• Transformational leadership correlates with high-performing teams: Teams led by managers who exhibit vision, inspirational communication, intellectual stimulation, supportive behaviour and personal recognition consistently fall into the highest performance tiers.
• Lean product management accelerates delivery: Organisations that adopt lean practices — small batches, frequent releases, customer feedback loops — deliver value to customers faster and improve more rapidly than those using traditional project-based delivery models.

The implication is clear: DevOps transformation does not happen from the bottom up alone. Leadership must actively sponsor, model and reinforce the cultural changes required.

Considerations for Middle Management When Adopting DevOps

Middle managers sit at the intersection of strategic direction and day-to-day execution. They are frequently the difference between a DevOps transformation that gains traction and one that stalls. Three principles are particularly relevant at this level:

1. Systems Thinking and Flow

Optimising a single team or department in isolation rarely improves the overall system. Middle managers need to understand the end-to-end flow of work — from a business idea through development, testing, deployment and operation — and identify the constraints that slow it down. This requires visibility across teams: shared dashboards, automated metrics and a culture of transparency about status and blockers.

2. Fast Feedback Cycles

Short, frequent feedback loops allow teams to detect and correct problems quickly, before they compound. Middle managers can enable this by removing bureaucratic gates that delay information flow, encouraging automated testing and monitoring, and ensuring that teams act on what they learn rather than filing results away.

3. Experimentation and Continuous Learning

Continuous improvement depends on the ability to run experiments, measure outcomes and change course. Middle managers play a decisive role here: if the culture punishes failure, people stop experimenting and the organisation stops learning. Managers must actively create psychological safety — making it clear that a well-designed experiment that disproves a hypothesis is a valuable outcome, not a career risk.

The Role of Upper Management in DevOps Transformation

Senior leaders set the conditions in which DevOps either thrives or withers. Their responsibilities in a DevOps context include:

• Modelling acceptance of failure: When senior leaders publicly acknowledge that experiments can fail without blame, middle managers and teams follow suit. This signal must come from the top; it cannot be mandated by middle management alone.
• Allocating budget for learning: Research, training, conference attendance and dedicated innovation time all require funding. Organisations that treat these as costs to be cut signal that learning is not truly valued.
• Aligning the rewards system: If performance reviews and bonuses still reward individual heroics and feature throughput rather than reliability, collaboration and system-level outcomes, the incentive structure will undermine every DevOps initiative. Senior leaders own the rewards system and must align it with DevOps values.
• Communicating a clear vision: DevOps transformation requires sustained effort across months or years. Senior leaders must articulate why the organisation is changing, what success looks like and how progress will be measured — and then repeat that message consistently.

DevOps Is an Organisational Strategy, Not Just a Technical Practice

The most common mistake organisations make when adopting DevOps is treating it primarily as a tooling question. Choosing a CI/CD platform, adopting infrastructure-as-code or deploying containers are all valuable steps — but they will not deliver lasting performance improvements if the underlying culture remains siloed and blame-driven.

DevOps asks development and operations teams to share accountability for the entire lifecycle of software: from writing code through deploying it, monitoring it in production and iterating on it based on real user feedback. That shared accountability only becomes real when management structures, incentives, budgets and leadership behaviours support it.

For executives who are serious about organisational performance in a software-driven world, DevOps is not optional and it is not a project with a defined end date. It is an ongoing commitment to building the culture, processes and capabilities that allow an organisation to learn and improve faster than its competitors.

Original source: businesscomputingworld.co.uk (2017). Reformatted and expanded for technical accuracy.