The Mainframe Is Not Going Away — But Its Tooling Needs to Evolve

For decades, mainframe developers relied on tools like ISPF green screens and the Eclipse desktop IDE augmented with proprietary plugins. These tools served their purpose well, but the wider software development world has moved on — and mainframe tooling must follow.

Broadcom highlighted this challenge in the Arcati Mainframe Yearbook, pointing to two converging pressures: a generational shift in the developer workforce and a dramatic acceleration in software delivery expectations.

A Workforce Shift and the Rise of Modern IDEs

Experienced mainframe engineers are retiring at a steady pace. The developers stepping in to replace them have grown up with modern toolchains and expect to keep using them. According to data cited from the Stack Overflow Developer Survey, Visual Studio Code’s popularity among developers grew from 34.9% to 50.7%, while Eclipse declined from 18.9% to 14.4% over the same period. Python emerged as the most sought-after scripting language skill.

These preferences are not just cosmetic. Developers who are comfortable in VS Code or browser-based environments will be less productive — and less happy — when forced into legacy toolchains. For enterprises that depend on mainframe talent pipelines, this is a real recruitment and retention risk.

DevOps Velocity Demands Are Reaching the Mainframe

Software delivery expectations have changed fundamentally across the industry. Data cited from 451 Research indicated that 24% of companies release application software daily or hourly. DORA’s State of DevOps report placed 20% of organizations deploying multiple times per day. Continuous deployment is no longer aspirational — it is the baseline expectation.

For the mainframe to remain a viable platform for application development — rather than just a runtime for legacy batch jobs — its development workflows need to match these cadences. That requires modern CI/CD-compatible tooling, scripting via CLIs, and team collaboration capabilities that distributed development teams already take for granted.

Eclipse Che and Che4z: A Browser-Based IDE for Mainframe Developers

Eclipse Che is an open-source, Java-based developer workspace server and browser-based IDE that is container-native. It was architected to deliver a VS Code-like experience from the browser, built on Eclipse Theia. Theia implements the same tooling protocols that underpin VS Code — the Language Server Protocol (LSP), Debug Adapter Protocol, and compatibility with VS Code extensions — making the transition familiar for developers already working in that ecosystem.

The analogy often used is Git: its usability and collaborative design made it the de facto standard for version control across teams of all sizes. Che’s workspace server aims to deliver comparable collaborative benefits, particularly for hybrid IT teams working across mainframe and distributed platforms.

The Che4z subproject, contributed by Broadcom, extends Che specifically for mainframe development. It provides:

• Access to the z/OS file system
• Remote editing and debugging of COBOL programs
• Syntax highlighting, code assist, and real-time syntax validation
• Language Server Protocol support for COBOL (with High-level Assembler planned)

Because Che4z uses LSP, developers can use COBOL with Che, VS Code, or any other LSP-compatible editor such as IntelliJ, VIM, or Emacs — significantly broadening the reach of mainframe language support without requiring a proprietary plugin ecosystem.

Zowe: The Open Source Foundation That Makes It Possible

The Che4z extensions are powered by Zowe, the first open source project based on z/OS. Zowe was founded by Broadcom, IBM, and Rocket Software and enables developers to manage, control, script, and develop on the mainframe using familiar patterns from cloud development — all while maintaining mainframe-native security standards.

While open source is not new to mainframe environments — zLinux has existed for years — Zowe was a significant step in opening access to off-platform toolchains. The Zowe CLI is a key component of the Che4z stack, enabling the kind of scripting and automation that underpins DevOps adoption. CLIs allow developers to automate repetitive tasks, integrate with pipelines, and script complex workflows — capabilities that were difficult or impossible with traditional mainframe tooling.

Code4z: Bringing Mainframe Development Into VS Code

For developers who prefer to stay in their desktop environment rather than a browser-based IDE, Code4z is a free Visual Studio Code plugin that provides access to mainframe datasets and elements directly from VS Code. It allows developers to write and manage mainframe code using the most popular desktop IDE available today, without needing to context-switch into a separate toolchain.

Why Containerized Workspaces Matter for Mainframe Teams

Because Che workspaces are containerized, they carry meaningful operational advantages over traditional desktop IDE setups:

• No local installation: Developers open a container and begin work immediately, with no environment configuration on their local machine.
• Fast onboarding: New team members can be productive in minutes rather than days — a critical advantage when mainframe talent is scarce.
• Reduced maintenance overhead: The heavyweight plugin management required by Eclipse-based setups is eliminated.
• Pair programming support: Che facilitates real-time collaboration between mainframe and distributed developers working on cross-platform applications.

For mainframe leaders under pressure to reduce costs and onboard the next generation quickly, migrating teams from Eclipse-with-customizations to a containerized Che environment represents a concrete opportunity to reduce operating costs and improve developer productivity.

Bridging Mainframe and Cloud: The Hybrid IT Case

For many large enterprises, the mainframe hosts critical systems of record — transaction engines and authoritative data stores — while cloud and mobile applications serve as systems of experience. Cross-platform applications increasingly need to combine the transactional power and data assets of the mainframe with modern user interfaces built on cloud and mobile stacks.

This integration work falls on cloud and mobile developers who are unfamiliar with mainframe tooling. Allowing them to use the editors they already know — VS Code, Che, LSP-compatible IDEs — removes a significant barrier and accelerates delivery. The open source, standards-based approach taken by Che and Zowe is central to making that practical.

Commercial Support for Open Source Mainframe Tools

Enterprises that depend on mainframe infrastructure are understandably cautious about adopting open source tools without a clear support model. Vendors including Broadcom address this by offering commercially supported versions of these open technologies alongside the open source releases.

Broadcom’s CA Brightside product, for example, provides a streamlined installation path, technical and legal support for Zowe core capabilities, and certified integrations with proprietary solutions such as CA Endevor SCM, CA File Master Plus, and CA OPS/MVS. This model allows enterprises to adopt open source tooling at their own pace while maintaining enterprise-grade support coverage.

The Broader Revolution in Mainframe Application Development

The convergence of Che, Che4z, Zowe, and Code4z represents more than a tooling refresh. It signals a fundamental shift in how mainframe development is positioned — away from a siloed, vendor-controlled ecosystem and toward participation in the same open source communities, protocols, and workflows that drive development on every other platform.

Expanded tool choice, greater alignment with off-platform development peers, and DevOps-compatible software delivery cadences are the practical outcomes. For organizations managing hybrid IT estates — where mainframe reliability and cloud agility both matter — this open source foundation is what makes sustainable modernization possible.

The Che4z extensions are open sourced and free to use. Community contributions are welcomed by both the Che and Che4z projects.

DevOps is often used alongside complementary frameworks such as Lean and Kaizen, borrowing concepts like waste elimination and continuous improvement. Rather than treating Dev and Ops as adversarial functions with different incentives, DevOps aligns them around a shared goal: delivering reliable value to end users at speed. Below are five important aspects that characterise a mature DevOps practice.

This article is based on a summary originally published on DZone.

1. Organisations Must Accept Cultural Change

Historically, development and operations teams operated in separate silos with different—and sometimes conflicting—objectives. Developers were measured on the speed of feature delivery; operations teams were measured on system stability. This tension is a root cause of slow release cycles and production incidents.

DevOps dismantles these silos by requiring a fundamental cultural shift. Both teams must share responsibility for keeping software running correctly at all times while continuously delivering new functionality. This means:

• Developers take ownership of how their code behaves in production.
• Operations engineers participate earlier in the software design and build process.
• Leadership aligns incentives across both groups toward common business outcomes.
• Blame culture is replaced with blameless post-mortems and shared learning.

Without genuine cultural change, tooling investments alone will not produce the reliability and velocity gains that DevOps promises. Culture is not a soft concern—it is a prerequisite for every other aspect on this list.

2. Quality Control Is a Shared, Continuous Responsibility

In traditional software delivery, quality assurance (QA) was a gate at the end of the development pipeline. Testers validated code after developers had finished, creating a bottleneck and a handoff that introduced delays and friction.

In a DevOps environment, quality control becomes a continuous, shared activity woven throughout the entire software lifecycle:

• Shift-left testing: Automated unit and integration tests run as part of every code commit, catching defects early when they are cheapest to fix.
• Developers and testers collaborate: Rather than handing off finished code to a separate QA team, engineers work together from the start to define acceptance criteria and build testable software.
• Operations provides feedback: Production monitoring data—error rates, latency, availability—feeds back into the development cycle, surfacing quality issues that only appear at scale.

Organisations that adopt DevOps tooling without investing in a robust, well-defined testing strategy frequently find that delivery speed increases but defect rates rise as well. A strong quality culture is non-negotiable.

3. Three Accelerators Drive the DevOps Process

Beyond cultural change, three practical accelerators determine how quickly and effectively a DevOps transformation takes hold:

• People: Skilled engineers who understand both software development and infrastructure operations are at the centre of any DevOps initiative. Investment in training, hiring, and cross-functional collaboration is essential.
• Process: Well-defined, repeatable workflows for building, testing, deploying, and monitoring software replace ad-hoc manual steps. Processes should be documented, version-controlled where possible, and continuously improved.
• Automation tools: Automation is the force multiplier that makes DevOps scalable. This includes CI/CD pipelines, infrastructure-as-code (IaC) tools, configuration management systems, automated testing frameworks, and observability platforms. Organisations may use open-source tools, commercial platforms, or a combination of both depending on their requirements and budget.

These three accelerators reinforce one another. Automation is only as effective as the processes it encodes, and processes only improve when the people running them have the skills and mandate to do so.

4. The DevOps Lifecycle Is Iterative and Continuous

A mature DevOps practice is organised around a continuous, iterative lifecycle rather than a linear, waterfall sequence. The key functional stages typically include:

• Continuous Integration (CI): Developers merge code changes frequently—often multiple times per day—into a shared repository. Automated builds and tests validate each change immediately.
• Continuous Delivery (CD): Every change that passes the CI stage is automatically packaged and made ready for deployment to any environment. Deployment to production may be triggered manually or automatically depending on the organisation’s risk appetite.
• Continuous Operations: Infrastructure is managed dynamically. Monitoring, alerting, auto-scaling, and self-healing capabilities keep systems available without requiring manual intervention for routine events.
• Continuous Assessment and Feedback: Metrics collected from production—performance data, error budgets, user behaviour—are fed back into planning and development, closing the loop and driving the next iteration.

This cycle eliminates the long, high-risk release events that characterise traditional software delivery. Smaller, more frequent releases reduce the blast radius of any individual change and make root-cause analysis significantly easier.

5. Understanding Key DevOps Patterns

DevOps practitioners recognise a set of recurring patterns that describe how development and operations work can be integrated. Four broad patterns are commonly discussed:

• Extending development practices into production: Developers use production-like environments for testing and staging, reducing the gap between where code is written and where it runs. Infrastructure-as-code is a key enabler here.
• Creating production feedback loops for development: Observability tooling—logs, metrics, traces—surfaces production behaviour to developers in near real time, enabling data-driven decisions about what to build and fix next.
• Integrating development practices into IT operations processes: Operational tasks such as provisioning, patching, and configuration management are treated as code, reviewed in pull requests, and tested before being applied.
• Embedding IT operations knowledge into development: Non-functional requirements—scalability, resilience, security, compliance—are defined and validated during development rather than discovered after deployment.

Understanding these patterns helps engineering leaders diagnose where their current workflow breaks down and which specific changes will have the greatest impact on delivery performance and system reliability.

Value That DevOps Adds to Organisations

When all five aspects are operating together effectively, organisations that adopt DevOps typically realise the following benefits:

• Shorter time to market for new features and products
• Reduced operational waste through automation of repetitive manual tasks
• Elimination of silos between development and operations teams
• Higher employee engagement, as engineers spend less time on toil and more time on meaningful work
• Improved customer satisfaction through more reliable, higher-quality software
• Faster release cycles enabled by task automation and continuous delivery pipelines

Increasingly, both technology-native companies and traditional enterprises are adopting DevOps principles and patterns to remain competitive in fast-moving markets. DevOps is not a destination—it is an ongoing commitment to improving how software is built, delivered, and maintained.

The Challenge: Becoming Fit for the Future

Many organisations have already embarked—or are about to embark—on Agile and DevOps transformation initiatives, driven by growing competitive and business demands. An event co-organised by CIO Platform Nederland and the DevOps Agile Skills Association (DASA), hosted by Dutch airline Transavia, brought together leaders to share practical experiences from two major Dutch organisations: Transavia and ABN AMRO.

The core question was straightforward but hard to answer: Is your organisation truly fit for the future? The discussion made clear that technical tooling and process frameworks alone will not get you there. The real work lies in culture, leadership behaviour, and sustainable mindset change.

The late Robert Stroud, former analyst at Forrester, framed the urgency well: “To unlock the promise of DevOps, CIOs must lead and support a cultural change within their technology management organisation, but as any leader knows, changing institutionalized behavior is the toughest of all management challenges. CIOs must recognize when a trend becomes an imperative for survival. DevOps has become this imperative.”

Lessons from Transavia: People First, Behaviours Second

Rik Farenhorst, CIO of Transavia and chairman of the DASA Leadership Forum, shared lessons from Transavia’s transformation journey. His central argument: organisations place too much faith in structure, processes, and automation, hoping that the right culture will simply emerge. It does not.

Farenhorst’s three key messages were:

• People first — transformation is a human endeavour before it is a technical one.
• Live your values — stated values must be translated into observable, day-to-day behaviours.
• Lead by example — leadership credibility depends on visible, consistent behaviour, not communications.

A concrete example of leading by example was the leadership team’s adoption of daily standups combined with visual management of strategic priorities. This practice built situational awareness, shared understanding, and genuine commitment across the organisation.

Farenhorst also acknowledged a reality that many transformation programmes ignore: not all teams mature at the same speed. Accepting this and adjusting coaching and leadership styles accordingly is critical to sustainable progress.

Lessons from ABN AMRO: From Agile to BizDevOps

Matthijs Dee and Ivo Carton from ABN AMRO described their journey from Agile to DevOps. Two themes echoed Transavia’s experience: teams mature at different speeds, and inter-team knowledge sharing is essential.

ABN AMRO developed a DevOps playbook—a practical toolkit that teams could use to assess and improve their own capabilities. Rather than mandating a single transformation path, the playbook gave teams a structured set of options to draw from at their own pace.

One of ABN AMRO’s most significant challenges was moving away from command-and-control and traditional hierarchical management models toward new leadership styles. Their conclusion was that the scope of change needed to go beyond IT: it had to encompass the business. This gave rise to their focus on BizDevOps—the recognition that DevOps is not only about writing and deploying code, but about delivering measurable business value end-to-end.

Three Key Takeaways: DevOps Will Fail Unless…

A presentation drawing on findings from more than 400 global teams who had participated in Phoenix Project DevOps simulations identified three practical takeaways for organisations attempting transformation.

1. Shift from Features to Outcomes (BizDevOps)

The first priority is reframing the flow of work. Organisations must move from a “code-to-commit” mindset to an “idea-to-value” mindset—measuring success not by features shipped but by business outcomes delivered. This shift was identified as one of the top challenges at the most recent DevOps Enterprise Summit at the time of the event.

2. Define and Commit to Desired Behaviours

Both Transavia and ABN AMRO pointed to the same challenge: articulating values or principles is not enough. Organisations must translate those values into specific, agreed-upon behaviours—for teams and for leaders. What does effective collaboration actually look like in practice? What does psychological safety look like when a deployment fails at 2am? These questions need explicit answers, not implicit assumptions.

3. Embed Continual Learning as a Core Behaviour

DevOps transformation is not a project with a defined end state—it is an ongoing journey of iterative improvement. Mike Orzen, author of Lean IT, put it clearly: “Improving your work is just as important as doing your work.” This means improvement work must be made visible in team backlogs, and leaders must protect time for it. Improvement should not be squeezed out by delivery pressure.

Culture Breakout: The Hardest Conversations

Three breakout sessions followed the presentations: “Value Creation and Management,” “Organisational Design – Agile/DevOps at Scale,” and “Sustainable Culture Change.” The culture session surfaced some of the most honest and practically useful discussions of the day. The key themes are summarised below.

Empowerment Across Management Layers

A recurring concern was how a CIO’s vision gets diluted as it passes through management layers before reaching teams on the ground. Suggested approaches included management by walking around—leaders being physically visible on the shop floor, listening to concerns rather than broadcasting direction, and entering into genuine dialogue about goals and what they mean for individuals.

Addressing Fear, Uncertainty, and Doubt (FUD)

Teams facing new ways of working frequently experience FUD: What will this mean for my job? My responsibilities? Can I actually do this? Leaders must actively remove FUD by creating a genuinely safe environment—safe to experiment, safe to fail, and safe to speak up. A no-blame culture is not a slogan; it requires consistent, visible behaviour from leadership over time.

Psychological Safety: The “It” Factor

Google’s internal research project known as Project Aristotle (2012) investigated why some teams consistently outperform others. The most significant finding was that psychological safety—a shared belief that the team is safe for interpersonal risk-taking—was the single most important factor in team effectiveness. Specifically: a sense of confidence that the team will not embarrass, reject, or punish someone for speaking up.

This finding directly validates the emphasis on no-blame culture and safe experimentation that both Transavia and ABN AMRO identified in their own transformations.

Team Training, Not Just Individual Training

Individual skills training is necessary but not sufficient. Teams need to learn how to work together—which means investing in team-level training that addresses soft skills: communication, giving and receiving feedback, and effective collaboration. Technical capability without these skills produces capable individuals working at cross-purposes.

The “Why” Must Connect to “What’s in It for Me?”

Organisations often adopt Agile, DevOps, or Lean as goals in themselves. The breakout discussion challenged this directly: Are these approaches a destination, or a means of solving specific problems and delivering specific results? And how do those results connect to the strategic goals of the business?

Crucially, the “why” must be translated into a personal answer for every stakeholder group—business leaders, IT managers, team members, and customers. Without that connection, commitment to the journey is shallow and vulnerable to the first setback.

Dealing with Silent Killers and Heroes

Not everyone wants to change, and some individuals actively—if quietly—work against transformation. Leaders need the skills to identify these “silent killers”: behaviours that sit below the waterline and undermine team progress.

The discussion also addressed the “hero” problem: individuals whose indispensability masks a dependency that prevents team maturity. Two approaches were discussed—either removing the dependency (metaphorically or literally) or redirecting the hero’s energy toward coaching and knowledge sharing to build broader T-shaped capabilities across the team.

Change Champions and Authentic Leadership

Identifying and empowering “change champions” within teams—individuals with peer-level respect who believe in the transformation—can be more effective than top-down mandates. Giving these individuals a platform, recognising their contributions, and celebrating team successes that result from new behaviours helps shift cultural norms organically.

Authenticity was also raised as non-negotiable. Leaders who want to build trust must demonstrate empathy that is real, listen to concerns and act on them, admit when they do not have all the answers, and show their own vulnerability. If behaviour is perceived as performative, trust evaporates faster than it was built.

What C-Level Leaders, Managers, and Teams Each Need

The event’s clearest conclusion was that different levels of the organisation require different capability investments:

• C-level leaders must develop new skills and demonstrate new behaviours—particularly around empowerment, vulnerability, and systemic thinking.
• Middle management layers must invest in organisational behaviour management: understanding what drives team behaviour and how to create sustainable change, not just compliance.
• Teams must develop not only DevOps technical skills but also team-building and soft skills—and must be given the time and safety to do so.

Summary

The event made one thing clear: the technical aspects of DevOps and Agile transformation are the easier part. The harder, more consequential work is cultural—and it requires deliberate investment in leadership behaviour, psychological safety, inter-team learning, and a shared understanding of why the transformation matters to every stakeholder involved.

CIO Platform Nederland and DASA committed to organising follow-up events and sharing experiences from member organisations to continue addressing these challenges.

The four mistakes below reflect common pitfalls drawn from DevOps practice. Recognising them before you start is far cheaper than correcting them after the fact.

1. Failing to Define What DevOps Means for Your Organisation

Ask ten engineers what DevOps means and you will get ten different answers: a philosophy, a culture, a CI/CD pipeline, a set of automation tools, a restructured org chart, or some combination of all of these. Every answer has merit, which is part of the problem.

Before choosing tools or restructuring teams, your organisation needs a working definition that is grounded in its own context. That definition should answer a practical question: what specific business problem are we trying to solve? Common legitimate motivators include:

• Reducing the time between a feature being ready and reaching production
• Increasing deployment frequency without increasing the rate of incidents
• Breaking down silos that slow down incident response
• Enabling the team to respond faster to changing customer requirements

A concrete, organisation-specific definition keeps the initiative grounded and gives you a measurable target. Without one, DevOps efforts tend to drift into tool adoption exercises that deliver little lasting value.

2. Adopting DevOps for the Wrong Reasons

Implementing DevOps because a competitor announced it, or because it topped the trending topics list at a recent conference, is a poor foundation for an expensive organisational change. The initiative needs to be driven by a genuine gap between where your delivery process is today and where it needs to be.

A useful diagnostic exercise is to look outward and inward simultaneously:

• Externally: Are your competitors shipping new features continuously? Are customers churning because you are too slow to respond to their needs? If your market moves slowly and release cadence is not a competitive differentiator, DevOps may not be the highest-priority investment right now.
• Internally: Would targeted improvements to your existing processes — better code review, clearer incident runbooks, improved test coverage — close the gap without a full DevOps transformation? Sometimes they would, and that is a valid conclusion.

DevOps done well is a significant investment of time, money, and organisational attention. Make sure the expected return justifies it before you commit.

3. Prioritising Tools and Processes Over Culture

This is the most common and most costly mistake. Organisations stand up CI/CD pipelines, configure monitoring stacks, and automate deployments — then wonder why nothing fundamentally changed. The answer is almost always culture.

In many organisations, development and operations teams have historically operated in separate silos, with different goals, different incentives, and sometimes an adversarial relationship. Developers optimise for shipping features; operations teams optimise for stability. DevOps requires both groups to share responsibility for the full software lifecycle — from writing code through to running it in production.

That shift — from us versus them to we — cannot be automated or mandated by a new org chart. It requires deliberate investment:

• Joint on-call rotations that give developers visibility into operational pain
• Shared post-incident reviews that focus on systems rather than blame
• Cross-functional team structures where developers and operations engineers work toward the same outcome metrics
• Leadership behaviours that reinforce collaboration over finger-pointing

Cultural change is slower and harder than installing a tool, but it is the foundation on which every other DevOps practice depends. Skipping it means your automation sits on top of the same dysfunctional dynamics as before.

4. Copying the Enterprise Playbook Without Adapting It to Your Scale

Case studies from large technology companies — organisations with hundreds of engineers, dedicated platform teams, and substantial infrastructure budgets — are widely cited as DevOps inspiration. They are useful reference points, but they are a poor blueprint for an SME to copy directly.

Large-scale DevOps transformations assume staffing levels and budget allocations that most SMEs simply do not have. Attempting to replicate them without the underlying resources leads to overextended teams, half-implemented practices, and frustrated engineers.

A more practical approach for an SME:

• Audit your current team honestly. Which DevOps capabilities already exist in-house? Where are the genuine gaps?
• Start narrow. Pick one high-friction part of your delivery pipeline — manual deployments, flaky tests, slow environments — and improve it measurably before expanding scope.
• Right-size your tooling. Managed services and cloud-native CI/CD offerings can give an SME much of the capability of a large enterprise platform team without the headcount to maintain it.
• Budget for learning time. DevOps adoption has a learning curve. If the business cannot absorb some short-term velocity reduction while the team builds new skills, the timing may not be right.

The agility of an SME is a genuine competitive advantage in a DevOps context — smaller teams can change direction faster and experiment more cheaply than large enterprises. The goal is to build a DevOps practice that fits your organisation’s actual size and constraints, not a scaled-down replica of someone else’s.

Getting It Right

Avoiding these four mistakes does not guarantee a smooth DevOps adoption, but it significantly improves the odds. The common thread across all of them is the same: clarity before action. Know what you are trying to achieve, know why you are doing it, address the human side before the technical side, and build for your scale rather than someone else’s.

SMEs that approach DevOps this way are well positioned to ship better software faster — and to sustain that pace as they grow.

This article is an independent expansion of a topic originally discussed on DevOps Online.

DevOps Adoption Is Harder Than It Looks

DevOps continues to attract significant organizational interest, but the road to meaningful adoption remains rocky. A survey conducted by Pensa, an intelligent SaaS specialist, polled more than 200 IT decision makers to identify the most significant challenges they face when implementing DevOps practices. The findings paint a clear picture: cost and technical complexity dominate the list of barriers, while cultural and skills gaps trail behind.

The Top Barriers to DevOps Success

The survey ranked the following obstacles by the percentage of respondents who cited each as their primary barrier:

• Limited budgets — 19.7%
• Legacy system constraints — 17.2%
• Application complexity — 12.8%
• Difficulty managing multiple environments — 11.3%
• Company culture — 9.4%
• Testing automation challenges — 7.9%
• Limited IT skills — 7.9%
• Lack of executive buy-in — 7.4%

Budget constraints rank first, but the second and third positions are telling: legacy infrastructure and application complexity together account for a substantial share of reported friction. These are deeply interconnected problems — modernizing complex, business-critical applications running on aging infrastructure requires significant capital investment, skilled personnel, and executive sponsorship, all of which are in short supply according to respondents.

Why These Barriers Matter

Budget Constraints

DevOps transformation is not a one-time purchase. It involves ongoing investment in tooling, training, process redesign, and often significant infrastructure changes. For organizations operating with lean IT budgets, the upfront cost of toolchain consolidation, CI/CD pipeline construction, and team restructuring can be prohibitive — especially without a clear, short-term ROI to present to finance stakeholders.

Legacy Systems and Application Complexity

Many enterprises carry years — sometimes decades — of technical debt. Monolithic applications, tightly coupled architectures, and undocumented dependencies make automation difficult and risky. Containerizing or refactoring these systems to support continuous delivery pipelines is a significant engineering undertaking that frequently stalls DevOps initiatives before they gain momentum.

Multi-Environment Management

Modern IT environments rarely live in one place. Teams manage workloads across on-premises servers, private clouds, and multiple public cloud providers simultaneously. Maintaining consistency in configuration, security policy, and deployment pipelines across these environments introduces operational complexity that slows DevOps velocity.

Culture and Executive Buy-In

Culture and executive support together account for roughly 17% of reported barriers — nearly as much as legacy systems alone. This is not surprising. DevOps requires breaking down silos between development, operations, and security teams, which often means reorganizing reporting structures, redefining performance metrics, and changing deeply ingrained ways of working. Without visible leadership commitment, these changes rarely take hold.

Platform Preferences Among Active DevOps Teams

For organizations that have already launched DevOps initiatives, the survey reveals a multi-platform reality. Public cloud dominates, but virtualization platforms remain widely used:

• Microsoft Azure — 30.5%
• Amazon Web Services (AWS) — 26.6%
• VMware virtualization — 19.2%
• Microsoft virtualization — 15.3%
• OpenStack — 7.4%

The spread across platforms reinforces a recurring theme in DevOps practice: there is no single winning platform. Teams are pragmatic, deploying workloads wherever it makes technical and commercial sense. This also makes tooling choices more complex, as teams must support pipelines that span multiple infrastructure providers with different APIs, security models, and operational tooling.

Industry Perspective

Pensa CEO Tom Joyce summarized the core findings: “Our initial DevOps survey reveals the biggest barriers to DevOps success involve the cost and complexity of transforming legacy IT environments into complete software-defined data centers, including compute, networking, storage, security, and applications. We also found that IT managers are committed to deploying DevOps on a range of platforms including public cloud, private cloud and on-premise virtualization, rather than being beholden to any single DevOps platform.”

Key Takeaways for DevOps Practitioners

The survey results highlight a number of practical considerations for teams planning or scaling DevOps adoption:

• Start with a business case. Budget is the top barrier. Building a clear ROI narrative — tied to deployment frequency, mean time to recovery, or reduced incident costs — is essential for securing funding.
• Assess legacy dependencies early. Before designing pipelines, map application dependencies. Hidden coupling in legacy systems will surface during automation and cause delays if not addressed proactively.
• Invest in platform-agnostic tooling. Given the multi-cloud and multi-platform reality, favor tools and practices that abstract infrastructure differences — such as infrastructure-as-code frameworks and container orchestration platforms.
• Treat culture as a first-class workstream. Technical changes alone will not deliver DevOps outcomes. Budget time and effort for training, team restructuring, and change management alongside tooling work.
• Pursue executive sponsorship actively. With nearly 17% of barriers linked to culture and leadership, securing a visible executive champion is as important as any technology decision.

The barriers identified in this survey — cost, complexity, culture — are structural, not accidental. Teams that acknowledge and address them directly, rather than treating DevOps as a tooling exercise, are better positioned to make adoption stick.

Once the basics are in place, focus shifts to more mature challenges: creating a fully integrated tools pipeline, managing test data without compromising privacy or security, and choosing the right infrastructure strategy. Regardless of where your organization sits on the DevOps maturity curve, the five issues below deserve deliberate attention.

1. Integrating a Fragmented Toolchain

The DevOps tooling ecosystem has grown rapidly. Tools now exist for every discrete stage of the pipeline: requirements management, agile planning, source-code management, build automation, artifact management, deployment, monitoring, and more. That breadth of choice is useful, but it creates a serious integration problem.

When development, QA, and operations teams each work with their own tools in isolation, the pipeline fragments into silos. Code cannot flow smoothly from requirements through testing and into production, and visibility across the entire lifecycle is lost. A well-integrated toolchain is not optional — it is the mechanism that lets business objectives translate into coordinated, traceable delivery.

Organizations generally have three approaches to integration:

• Build custom integrations in-house. This gives maximum control but carries high upfront cost and ongoing maintenance burden. Every time a tool is upgraded, integrations may break.
• Rely on vendor-provided out-of-the-box connectors. Faster to deploy, but the integrations may not match your specific workflows.
• Use configurable connector platforms. Some vendors offer connectors that are quick to set up yet can be customized when your workflow diverges from the default — a pragmatic middle ground.

Whichever approach you choose, evaluate integration overhead as a first-class cost when selecting or retiring any tool in the chain.

2. Treating Configuration as Code

A persistent source of environment-related failures is the mismatch between the configuration present when code is written and the configuration present in production. Debugging these failures is costly because it is difficult to reproduce the exact environment state that existed when a defect was introduced.

Configuration as Code (CaC) addresses this by storing all environment configuration — server settings, dependency versions, feature flags — as versioned files alongside application code. Practical benefits include:

• Faster root-cause analysis. When a bug appears, engineers can check out the configuration revision that matches the code version in question and reproduce the environment precisely.
• Narrowed failure domain. If the configuration is verified correct, suspicion shifts to the application code itself, shortening investigation time.
• Consistent test environments. Infrastructure configuration differences between development and test environments are a common but underappreciated source of false test results. Versioning configuration alongside code reduces this drift.

Tools such as Ansible, Chef, Puppet, and Terraform are commonly used to implement CaC practices, though the right choice depends on your stack and team expertise.

3. Speed Is Not Free — Justify Your Automation Investment

There is an implicit assumption in many DevOps conversations that faster is always better and that automation is the universal path to speed. Both assumptions deserve scrutiny.

Automation does reduce repetitive manual effort, but it introduces its own costs: additional tools to license or maintain, integration points that can break, and engineers who need to understand and update the automation scripts as the codebase evolves. An automation investment only pays off when the cumulative saved effort exceeds the ongoing maintenance overhead.

A more disciplined approach involves the following considerations:

• Tie speed objectives to business requirements. Not every industry is driven by rapid time-to-market. A regulated financial or healthcare application may benefit more from a steady, iterative release cadence than from daily deployments.
• Reduce rework before adding automation. If your team has clear objectives and precise handoffs, you will produce less rework — which is often a bigger time drain than slow pipelines.
• Automate incrementally. Identify the highest-value, highest-frequency manual tasks first and automate those. Avoid automating everything at once simply because tooling makes it possible.

Before expanding your automation footprint, articulate a clear business case: what specific outcome does this automation enable, and how does that outcome justify the maintenance cost?

4. Acquiring Sufficient, Safe Test Data

High-stakes applications — e-commerce platforms, customer-facing mobile apps, financial services systems — carry real risk if they are released without being tested against data that accurately represents production. Accumulating enough high-quality test data is harder than it sounds, particularly given the volume of data modern applications handle, the fragmentation of database technologies, and the legal requirements around data privacy.

Two common but imperfect approaches are:

• Scrubbing real production data. Removing personally identifiable information (PII) from customer records before using them in test environments. This can work, but an incomplete scrubbing process creates serious compliance and security exposure — particularly under regulations such as GDPR or CCPA.
• Generating synthetic test data. Creating fake data that mimics production data statistically. Synthetic data avoids privacy risk, but it can miss edge cases present in real data, reducing QA coverage.

Neither approach alone is sufficient for complex, sensitive environments. Test data management is a cross-functional problem that typically involves security, compliance, QA, development, and business stakeholders. Treating it as a single team’s concern — or selecting a single tool and declaring it solved — underestimates the challenge. Organizations handling sensitive data should establish a formal test data management strategy that addresses data masking policies, synthetic data generation, and ongoing governance.

5. Choosing Between Internal and Cloud-Hosted Infrastructure

Cloud infrastructure is a natural fit for DevOps workloads. Elastic compute makes it easy to spin up parallel build agents, run large test suites simultaneously, and scale back down when the work is complete. Major cloud providers offer managed services — load balancing, logging, monitoring, automated backup and failover — that remove significant operational overhead from engineering teams.

However, cloud hosting is not viable for every organization. Strict regulatory requirements, data sovereignty rules, or internal security policies may mandate that workloads run on-premises. Running a DevOps infrastructure internally introduces its own challenges:

• Fixed hardware capacity limits how many builds or test jobs can run concurrently.
• Long-running test suites may need to be scheduled during off-peak hours (evenings or weekends), delaying feedback loops by hours or days.
• Infrastructure provisioning, patching, and maintenance require dedicated staff.

One practical mitigation for on-premises environments is container-based scaling. By running build and test workloads in containers (using platforms such as Kubernetes or Docker Swarm), teams can make better use of existing hardware capacity and run more jobs in parallel without purchasing additional physical machines. This approach works well for teams primarily doing web or API development. Large enterprises with applications spanning multiple operating systems and device types will likely need to invest in more substantial on-premises infrastructure.

A hybrid model — keeping sensitive data and compliance-critical workloads on-premises while running lower-risk build and test jobs in the cloud — is also worth evaluating when your regulatory context permits it.

DevOps Is a Journey, Not a Destination

The five issues above can feel daunting, especially for teams early in their DevOps journey. It helps to remember that DevOps maturity is built incrementally. No organization moves from a siloed, manual software delivery process to a fully automated, integrated pipeline overnight.

Start with low-risk projects where the cost of a misstep is manageable. Celebrate incremental improvements — a faster build, a more reliable test environment, a smoother deployment. Each small win builds the organizational confidence and technical capability needed to tackle harder problems.

DevOps, at its core, is a continuous improvement discipline. The organizations that sustain it long-term are the ones that treat it as an evolving practice rather than a one-time implementation project.

Figuring out the most optimal way to enable agility and rapidly deliver services to customers—without compromising quality—continues to be one of our industry’s biggest challenges. Many IT leaders agree that implementing DevOps practices can significantly accelerate software releases while still assuring our applications meet quality objectives.

If you’re considering a move to a DevOps delivery model, here are six approaches I’ve found to be critical for ensuring a successful DevOps adoption within an organization.

1. Embrace a DevOps Mindset

DevOps doesn’t begin by just stating, “Let’s do DevOps,” and jumping in with tools. Your entire organization needs to have a clear understanding of what DevOps is and what specific business needs it can address, and, most importantly, everyone needs to be willing to change the way things have always been done.

One way to begin this process is to identify your current application value streams—the series of activities necessary for moving your products from development all the way into production. Understanding where in this delivery process there are constraints, bottlenecks, and wait queues will allow you to which activities you should concentrate on improving.

Identifying areas where your current delivery process is inefficient and must be improved is your opportunity to truly make change in your organization. But in order to do so, you must be willing to experiment. Short-term failure is acceptable, as long as you’re learning from it and improving. Instead of accepting inefficient ways of doing business because that’s the way it’s always been done, you will need to encourage your organization to ask questions like: “Why do we do this [process]? What’s its business value? How can we make it more efficient?”

Organizations often equate DevOps with automation. While automation can help accelerate manual processes, DevOps is fundamentally about collaboration and communication. If you don’t embrace strong communication and collaborative practices among everyone in the software development, testing, delivery, and operational process, automating your processes will not yield the business benefits you desire.

2. Make the Most of Metrics

One of the most overlooked initiatives in DevOps adoption is selecting the right metrics to record and track progress. Establishing the right baseline DevOps metrics early on and not being afraid to measure things that might initially not make you look very good is the key to being able to show demonstrative progress over time and real business benefits to senior leadership.

From my experience, these are some of most useful DevOps metrics:

• Production failure rate: how often the software fails in production during a fixed period of time
• Mean time to recover: how long it takes an application in production to recover from a failure
• Average lead time: how long it takes for a new requirement to be built, tested, delivered, and deployed into production
• Deployment speed: how fast you can deploy a new version of an application to a particular environment (integration, test, staging, preproduction, or production environments)
• Deployment frequency: how often you deploy new release candidates to test, staging, preproduction, and production environments
• Mean time to production: how long it takes when new code is committed into a code repository for it to be deployed to production

There are many other metrics you can collect too, but avoid collecting vanity metrics that look impressive but don’t tie to business benefit, as well as metrics that are easily gamed—meaning they make your team look good but don’t actually contribute to business improvements, such as the number of commits your team makes.

Once you’ve determined the metrics you wish to collect and have a baseline of where you currently stand, set goals for each metric so the team knows what to strive for.

Most importantly, constantly share your DevOps goals, metrics, and progress with everyone involved. Set up metrics dashboards that display current metrics and progress toward your goals. Providing complete transparency is sometimes a difficult thing for teams to do, but it will foster more effective communication and collaboration, breaking down barriers between the dev and ops teams in the process.

3. Understand and Address Your Unique Needs

Contrary to what those selling DevOps products will tell you, there is no “one size fits all” solution for DevOps. You cannot just drop in an automated tool or hire a self-proclaimed “DevOps engineer” and expect success. Every organization will have a unique DevOps journey tied to its specific business and culture, and that journey will be far more about changing people’s habits and communication patterns than what tools help you enable automation.

DevOps is a way of accelerating the creation and delivery of quality software, but it only succeeds if you focus on what makes business sense for your organization. For instance, if your customers can’t consume ten to twenty updates to your product a day, don’t make doing so your goal! Instead, focus on improving the usability, security, or some other key attribute your customer cares more about.

4. Adopt Iteratively

When getting started, don’t try to boil the ocean with a complete, enterprisewide DevOps initiative. Identify a pilot application, form a cross-functional DevOps team that includes dev, test, and operations, examine your value stream to determine constraints and bottlenecks, and create an initial deployment pipeline that addresses some of your process constraints. Measure progress and success, wash, rinse, and repeat.

Generally, you should look at tackling your biggest value stream constraints first, as doing so will have the largest business impact. Some of these constraints will be easy to resolve, while others will take a significant amount of time to correct—and often a whole lot of convincing others to change.

You’ll want to go through a few iterations to build confidence in the framework and the pilot before you start expanding to other projects. Ensure you’re making progress against your metrics before moving on and applying those lessons to other teams. Most importantly, make sure those involved are influencers who can take the principles back to their respective teams; keeping all your expertise locked up on your pilot won’t help you expand to the enterprise effectively.

If you’re beginning your DevOps journey from inside a software development organization, consider starting from the beginning of your delivery process and moving toward production. Properly implementing branch management strategies and build automation is key to fast feedback that will enable efficient downstream processes in the future.

Once sound build automation is in place, a more comprehensive continuous integration capability that includes continuous testing is in order. Getting your continuous integration process working effectively will allow you to begin shifting left your assurance activities over time and speeding up delivery.

5. Emphasize Quality Assurance Early

Based on my observations in most organizations, testers get the least amount of time to do quality assurance, and eventually, the quality of the product suffers. Organizations that struggle with DevOps often focus their efforts on automating deployments, overlooking the needs of QA.

While it is impossible to automate all your testing in DevOps, it is critical to automate all tests run as part of your continuous integration process (unit tests, static code analysis, etc.), as well as regression testing and smoke testing performed on each environment within your delivery process. Automating at least some functional testing and nonfunctional tests associated with security, performance, and other quality characteristics can often be achieved to speed up these activities.

Run lengthy, long-running tests that may require large, production-like environments late in your DevOps process so as to not slow down earlier feedback cycles that must be quick.

6. Take a Smart Approach to Automation

Automation is the cornerstone of accelerating your delivery processes, and everything—infrastructure, environment, configuration, platform, build, test, process, etc.—should be defined and written in code. If something is time-intensive, broken, or prone to error, start automating there first. This will quickly benefit your team by reducing delivery times, increasing repeatability, and eliminating configuration drift.

Standardize your approach to automation in order to ensure dev, ops, QA, and everyone in between has a common frame of reference and a common language. It’s important that you use software engineering best practices when building DevOps automation. Infrastructure as code should be designed and implemented with coding standards, effectively tested, under configuration control, and well documented. The quality of your automation should be just as important as the quality of your application.

Why DevOps Adoption Is Still Hard

As DevOps moves from buzzword to standard practice, the questions enterprise teams ask most often are remarkably consistent: Where do I start? What challenges am I likely to face? How do I resolve them? These questions surfaced repeatedly across a series of focus groups and facilitated workshops run with enterprise executives and senior engineering leaders.

DevOps represents the logical endpoint of a progression that began with waterfall development, moved through iterative delivery, Agile, and Scaled Agile, and now culminates in a model that shifts focus from building software to delivering it continuously and reliably. That shift sounds straightforward but consistently proves difficult in practice.

The DevOps body of knowledge has matured significantly. Books such as The DevOps Handbook (Gene Kim, Jez Humble, Patrick Debois, and John Willis) and The DevOps Adoption Playbook (Sanjeev Sharma) now emphasize real-world case studies and actionable practice over abstract theory. Even so, the gap between knowing what good looks like and achieving it inside a real enterprise remains large.

The Top 30 DevOps Challenges

Data gathered from more than 100 DevOps workshops with enterprise teams surfaced a consistent set of recurring challenge areas. The 30 most common are listed below, ranked by frequency of occurrence across those sessions:

1. Environment provisioning
2. Manual testing
3. No DevOps center of excellence
4. Test data management
5. Manual deployments
6. Planning in a DevOps environment
7. DevOps and suppliers
8. DevOps and governance
9. No integrated tools architecture
10. Manual releases
11. No DevOps metrics
12. DevOps and team composition
13. DevOps and regulatory compliance
14. No service virtualization
15. DevOps and specialist skills
16. Traceability across the DevOps landscape
17. Large, infrequent releases
18. Inconsistent environments
19. Agile practices confined to developers only
20. Limited transparency
21. Pervasive manual processes
22. Collaboration between development and operations
23. No DevOps vision or strategy
24. No production-like environments
25. Waste in existing processes
26. Limited customer feedback loops
27. Elicitation of non-functional requirements
28. Collaboration across all IT disciplines
29. Collaboration between business and IT
30. No standard source control (SCM) repository

How to Read This List

The list is deliberately broad. A few things to keep in mind as you review it:

• There is intentional overlap. Manual testing, manual releases, and manual deployments are distinct problems even though all three fall under the umbrella of manual processes. Each has different root causes and requires different interventions.
• Challenges span the people–process–technology triad. Some (e.g., no DevOps center of excellence) are primarily organizational. Others (e.g., environment provisioning, no integrated tools architecture) are technical. Many (e.g., planning in a DevOps environment) are process-level concerns.
• Scale matters. Some challenges, such as DevOps and suppliers or DevOps and regulatory compliance, are predominantly enterprise-level concerns. Others, such as eliciting non-functional requirements, operate at the team level.
• This is not a universal checklist. Every organization’s situation is unique. Your most pressing challenge may not appear on this list at all.

A Practice-Based Approach to Resolving DevOps Challenges

Each of the 30 challenges above can be addressed through well-defined DevOps practices. The important insight is that every practice simultaneously addresses people, process, and technology—not just one dimension in isolation.

Worked Example: Replacing Manual Deployments with Automated Deployment

Consider challenge #5: manual deployments. The typical symptoms are low deployment frequency, high error rates, and long mean time to recovery (MTTR). The obvious resolution is to adopt automated deployment as a practice. But automation is not only a tooling exercise. A genuine practice-based resolution addresses all three dimensions:

• People: Redefine deployment roles. For example, developers can be empowered to promote a code package to the next environment once it passes relevant automated tests, while promotion to production still requires an explicit approval gate.
• Process: Map and streamline the existing deployment workflow. Identify and eliminate unnecessary control points, approval steps, and handoff delays that add lead time without adding value.
• Technology: Automate the streamlined process using appropriate tooling—CI/CD pipelines, infrastructure-as-code, configuration management—so that human error is removed from the critical path.

This three-dimensional view applies to every challenge on the list. Addressing only the technology layer while leaving role definitions and process steps unchanged is the most common reason DevOps tool investments fail to deliver the expected improvement.

Walking Through the Practice Library

One effective workshop technique is to review a library of DevOps practices as a team—understanding the intent of each practice, assessing its applicability to your current context, and agreeing on a priority order. This review process naturally surfaces the challenges that matter most to your organization and grounds the resulting roadmap in shared understanding rather than top-down mandate.

A day-long practice review session with senior engineering and operations stakeholders—similar to the approach used during an agile transformation at a major European bank described in the source material—can produce a prioritized adoption roadmap with clear owners and dependencies. The output is more durable than a tool selection exercise because it builds organizational consensus alongside the technical plan.

Develop Your Own DevOps Adoption Roadmap

DevOps practices do not exist in isolation. They are derived from underlying principles that themselves have roots in Lean manufacturing, Agile software development, ITSM, and continuous improvement disciplines. Understanding that heritage helps teams select practices that are philosophically consistent with one another—avoiding the common mistake of grafting incompatible practices onto an existing process.

When building your roadmap, consider the following structure:

1. Identify your current challenges. Run your own internal assessment against the 30 challenge areas above. Add any challenges unique to your organization, industry, or regulatory environment.
2. Map challenges to practices. For each prioritized challenge, identify the DevOps practice or practices most likely to resolve it. Consult your practice library.
3. Assess practice readiness. For each candidate practice, evaluate your current people, process, and technology maturity. Gaps in any dimension are implementation risks.
4. Sequence and commit. Build a phased roadmap that sequences practices logically—foundational practices (e.g., source control standardization, environment automation) before advanced ones (e.g., continuous deployment to production, chaos engineering).
5. Measure and adapt. Define DevOps metrics before you start—deployment frequency, lead time for changes, change failure rate, and MTTR are widely used starting points. Review progress regularly and adjust the roadmap as challenges are resolved and new ones emerge.

Key Takeaways

• The 30 challenges above are the most frequently cited across enterprise DevOps engagements, but they are not exhaustive—your organization may face additional or different ones.
• Every DevOps challenge has a people dimension, a process dimension, and a technology dimension. Sustainable resolution requires addressing all three.
• Practices are the bridge between DevOps principles and real-world outcomes. A shared understanding of which practices apply to your context—and why—is more valuable than a tool selection decision made in isolation.
• A practice-based roadmap built through facilitated team workshops tends to generate stronger organizational commitment than a roadmap handed down from leadership.
• DevOps adoption is iterative. Start with your highest-impact challenges, measure results, and refine your approach continuously.

Originally sourced from techbeacon.com. The workshops and enterprise case studies referenced in this article are attributed to the original author’s consulting and facilitation work with enterprise DevOps teams.

The Enterprise DevOps Challenge

Adopting DevOps at enterprise scale is a fundamentally different problem than adopting it in a small, co-located team. Large organizations face obstacles that do not disappear simply by changing a culture or deploying a CI/CD pipeline: geographic distribution, deeply entrenched organizational silos, disconnected toolchains, and strict regulatory compliance requirements all slow or block progress.

Atlassian has long positioned its toolchain—Jira, Confluence, Bitbucket, Bamboo, FishEye, Crucible, and HipChat—as an integrated platform for software delivery. At Atlassian Summit Europe 2017, the company announced targeted features in Bitbucket Server and Data Center 5.0 and Bamboo 6.0 designed to lower the specific barriers that enterprises encounter on the path to DevOps maturity.

Amber Frauenholtz, Bitbucket product marketing manager at Atlassian, summarized the challenge in a blog post at the time: “Things like compliance and scale become just as important. Tooling must provide freedom and structure, scalability and performance—things that are not often found together.”

Why Enterprises Lag Behind on DevOps

A joint study titled the DevOps Maturity Model, conducted by xMatters and Atlassian around the time of the announcements, found that 43% of respondents in organizations with 1,000 or more employees reported either having no DevOps initiative in place or being unaware of one. That figure underscores a persistent gap between the DevOps conversation in the industry and actual adoption inside large companies.

Charles King, principal analyst at Pund-IT, offered a pointed explanation: “Many solutions focus more on making life easier for developers than they do on ensuring that operational requirements are met. That issue impacts enterprises especially hard, since their applications often need to be more scalable and follow more rigorous compliance guidelines.”

New Features in Bitbucket Server and Data Center 5.0

Committer Verification

One of the most compliance-focused additions in Bitbucket Server and Data Center 5.0 is committer verification. The feature enforces that only the verified author of a commit can push those changes to the central repository. It also maintains a tamper-evident log of code changes for audit purposes.

For organizations operating under regulatory frameworks, this is a meaningful control. Kurt Chase, Director of Engineering Services at Splunk—a heavy Atlassian user—described the value directly: “We have to be compliant with AWS GovCloud, with PCI [Payment Card Industry Data Security Standard], with HIPAA [Health Insurance Portability and Accountability Act]. There’s a number of security programs that we maintain compliance for, so this will help us.”

Smart Mirroring and Authentication Caching

Smart mirroring in Bitbucket Data Center 5.0 gives geographically distributed engineering teams a read-only mirror of the central repository, reducing latency for developers who are far from the primary instance. A companion feature, authentication caching, stores credentials locally on mirror nodes so that developers can continue to authenticate and access mirrored content even during short outages of the primary authentication service.

Chase noted that Splunk runs large engineering teams across the globe and was actively investigating smart mirroring: “The ability to avoid all that latency for local engineers is absolutely huge.”

New Features in Bamboo 6.0

Bamboo Specs: Build Configuration as Code

The headline feature in Bamboo 6.0 is Bamboo Specs, which allows build plans to be defined and versioned as code alongside application source code. Prior to this, modifying a build plan typically required navigating the Bamboo web UI and often involved other teams or administrators. Bamboo Specs removes that friction.

Alison Huselid, head of HipChat Server, Bamboo, FishEye, and Crucible at Atlassian, described the practical benefit: “Developers can now control the process of updating their build. They don’t need to context switch between their code and the build that’s been established.”

Chase echoed the sentiment from an engineering perspective: “It’s about time that they have given us the ability to have our build jobs as code and we can commit them to the repo.”

Configuration as code is a well-established DevOps practice—tools such as Jenkinsfile (in Jenkins) and .travis.yml (in Travis CI) had popularized the pattern before Bamboo Specs. The Atlassian implementation brings that capability into the Bamboo ecosystem and stores the configuration in the same version-controlled repository as the application code, providing a single source of truth and a full change history for build definitions.

Tighter Integration Across the Atlassian Toolchain

Beyond individual product features, Atlassian emphasized deeper integration between Bitbucket Server, Bamboo, and Jira Software Server. The integrated workflow allows a developer to:

• Open a defect or task in Jira
• Automatically create a linked branch in Bitbucket
• View the associated Bamboo build status without leaving either tool

Chase described Splunk as an Atlassian shop “up and down the stack,” relying on Jira, Confluence, Bitbucket, Bamboo, FishEye, and HipChat. He cited the cross-tool integration as one of the most valuable aspects of the platform for the Splunk DevOps team.

This kind of traceability—linking a work item through source control to a build result—is a foundational DevOps practice. It reduces the manual effort required to answer questions such as “which build contains the fix for issue X?” and “who changed this and when?”

Key Takeaways for DevOps Teams

• Compliance is a first-class concern at enterprise scale. Features like committer verification are not optional extras—they are prerequisites for regulated industries such as finance, healthcare, and government.
• Geography matters. Geographically distributed teams suffer real productivity losses from repository latency. Smart mirroring and authentication caching are practical mitigations.
• Configuration as code reduces context switching. Allowing developers to manage build plans in the same repository as application code is a meaningful quality-of-life and governance improvement.
• Integrated toolchains reduce friction. End-to-end traceability from issue to branch to build shortens feedback loops and improves auditability.
• Enterprise DevOps adoption remains a work in progress. The maturity gap reported in the xMatters/Atlassian study reflects a real structural challenge, not a marketing talking point.

Originally reported by TheServerSide.com, May 2017. Product features described reflect the state of Bitbucket Server and Data Center 5.0 and Bamboo 6.0 at the time of the Atlassian Summit Europe 2017 announcement.

Why DevOps Adoption Stalls

Many organizations recognize the value of DevOps in principle but struggle to translate that recognition into lasting change. Some teams never get started because they lack a clear definition of what DevOps actually requires — from their tools, their processes, and their people. Others launch a DevOps initiative only to watch it slow down under the weight of organizational friction, unclear goals, and cultural resistance.

According to Jan Schilt of GamingWorks, most of these struggles can be traced back to four concrete obstacles. Understanding what they are — and having a practical strategy to address each one — is the first step toward a successful DevOps journey.

The Phoenix Project: A Foundation for the Conversation

Before diving into the obstacles, it helps to understand the mental model that Schilt and many DevOps practitioners use as a reference point: Gene Kim’s novel The Phoenix Project.

The book follows Bill, an IT manager tasked with rescuing a critically over-budget and delayed IT initiative. Bill’s breakthrough comes when he applies manufacturing flow principles to IT work. His approach unfolds in three stages:

1. Flow: Visualize all work in progress. Make the pipeline visible so the team can see where work is moving and where it is stuck.
2. Feedback loops: Bring teams together across silos. Encourage quality to be addressed at its source rather than passed downstream. Each step in the flow should deliver value and return feedback to the previous step.
3. Continuous learning and experimentation: Build a culture where teams constantly improve based on what they observe, rather than following fixed procedures in a changing environment.

These three principles — flow, feedback, and continuous learning — map directly onto the obstacles that real organizations face when adopting DevOps.

The 4 Main Obstacles to DevOps Adoption

1. Genuine Cross-Functional Teamwork

DevOps requires assembling a team from multiple disciplines — development, operations, QA, security, and often the business side — all working together toward a single value stream. This is harder than it sounds.

Most organizations have deep-rooted functional silos. People are hired, evaluated, and rewarded within their discipline. Asking them to share ownership of a delivery pipeline with colleagues from other departments demands new skills: communication styles, shared vocabulary, mutual accountability, and a willingness to own problems outside one’s traditional remit.

Without genuine teamwork, DevOps squads become multi-department committees rather than integrated delivery units — and the friction between silos continues to slow delivery.

2. Building Real Flow in the Delivery Process

Understanding that work should flow is not the same as actually creating flow. Teams must map their value stream, identify bottlenecks, limit work in progress (WIP), and back all of this with strong visualization — typically a Kanban board or an equivalent tool that the whole team actively uses and trusts.

Without visible, managed flow, teams default to reactive, interrupt-driven work. Priorities shift constantly, context switching erodes productivity, and nobody has a clear view of what is blocking value from reaching the customer.

Practical flow work includes: holding daily standups focused on blockers, running regular retrospectives, and enforcing WIP limits even when stakeholders push back.

3. Embracing Continuous Experimentation and Learning

DevOps is not a destination with a fixed set of procedures to follow. It is an ongoing improvement journey in which teams continuously test hypotheses, measure outcomes, and adapt. This is profoundly uncomfortable for people and organizations that rely on documented processes and defined work instructions for predictability and audit compliance.

Teams that cannot tolerate uncertainty will resist the feedback-driven iteration that DevOps depends on. They will wait for perfect requirements, avoid deploying until every edge case is handled, and treat every failed experiment as an indictment rather than a data point.

Building psychological safety — the understanding that well-designed experiments that fail are valuable — is essential infrastructure for DevOps, just as much as a CI/CD pipeline is.

4. Applying Agile, Lean, and ITSM Principles in Practice

Most DevOps practitioners are familiar with Agile, Lean, and IT Service Management (ITSM) concepts in the abstract. The gap between knowing and doing is wide. Teams may understand Kanban theory but struggle to enforce WIP limits under pressure. They may know what a retrospective is supposed to achieve but run them as status meetings instead.

Translating management principles into consistent daily practice requires deliberate repetition, coaching, and experimentation in real conditions — not just classroom knowledge.

How to Overcome These Obstacles

Invest in Foundational DevOps Training

Start by ensuring the team shares a common language and baseline understanding. Foundational programs such as DevOps Foundation or DevOps Fundamentals courses establish that common ground. For teams ready to go deeper, more advanced programs cover how DevOps principles interact with organizational structure, service management, and measurement strategy. Pair any training with hands-on exercises — theory retained without practice decays quickly.

Choose a Low-Risk Value Stream to Start

Resist the urge to transform every team and every pipeline at once. Instead, identify a single value stream — a specific process, service, or customer-facing product — that carries lower risk and has a team of willing early adopters. A contained experiment with a motivated team produces tangible results and generates internal advocates who can coach other teams later.

Build Time for Learning into the Plan

No team gets DevOps right immediately. Schedules that leave no room for errors, retrospectives, or course corrections guarantee frustration. Plan deliberately for learning cycles. After each sprint or deployment window, run a retrospective: what worked, what did not, what will the team try differently next time?

Use Simulations to Accelerate Practical Understanding

One reason organizations like GamingWorks have developed DevOps simulations — such as one built around The Phoenix Project — is that real-world learning is slow and costly. A simulation compresses the DevOps learning curve into a controlled environment where teams can experience a realistic workload, build and manage a Kanban board, practice standups and retrospectives, apply automated testing scenarios, and feel the consequences of high WIP and poor flow — all without risking a production system.

Participants come away with experiential knowledge of what DevOps actually feels like in practice, not just what it looks like in a slide deck. That experiential grounding helps teams connect the principles to their own organizational context before they begin their live implementation.

Let Early Adopters Coach the Next Wave

Once the first value stream is working well, the team that went through it becomes your most credible internal resource. Engineers and operators who have solved real DevOps problems in your specific environment are far more persuasive coaches than external consultants. Structure a deliberate knowledge transfer program so that early adopters help onboard subsequent teams, reinforcing their own learning in the process.

Summary

DevOps adoption is not primarily a technology problem. It is a people, process, and culture problem. Addressing it requires honest diagnosis of which obstacles are most acute in your organization, a focused starting point, and the discipline to build learning into the process from day one.

Stop Over-Planning and Start Doing

One of the most common reasons DevOps transformations stall is analysis paralysis — teams spend months building roadmaps, gaining buy-in, and defining processes before a single thing changes. According to practitioners who have actually done it, that is the wrong approach.

Steven Armstrong, principal DevOps automation engineer at Paddy Power Betfair, speaking at Computing’s DevOps Summit, was direct when asked how he launched his organisation’s DevOps initiative: “We were just able to do it.”

Armstrong’s advice: identify a genuine pain point — a single point of failure, a fragile deployment pipeline, a manual process that blocks releases — and start there. “Pick something like that, the low-hanging fruit, and go for it. Pick something and just start on it; don’t spend a hideous amount of time in planning,” he said.

What “Low-Hanging Fruit” Actually Means in Practice

The low-hanging fruit principle is about identifying work that is:

• High-pain: Something that visibly slows the team down or causes repeated incidents.
• Self-contained: A change that can be made without requiring a full organisational restructure first.
• Demonstrable: Something that, once improved, produces a measurable outcome stakeholders can see.

Armstrong’s team targeted single points of failure in a legacy database architecture under their old system. Fixing a concrete reliability problem gave the team a visible win and built momentum for broader change — without requiring months of upfront justification.

This approach also reduces political risk. A small, targeted improvement is easier to fund, easier to execute, and easier to learn from than a sweeping transformation programme.

Shift Left: Embed QA in the Development Team

Beyond choosing where to start, Armstrong highlighted a structural change that had a significant impact at Paddy Power Betfair: embedding Quality Assurance (QA) engineers directly inside development teams, rather than maintaining a separate QA department that reacts to completed code.

This practice — commonly called shifting left — means quality is considered at the earliest stages of the development cycle, not bolted on at the end.

“You don’t want a situation where you have QA reacting to development changes. Then testing runs will fail because the devs introduced a new GUI or something. So we moved teams together and then when the devs were developing code, QA were embedded there to help at the point when they were defining the user story. So you’re writing the test criteria along with the requirements and design. That’s really important, because you can’t have siloed departments that are purely reactive any more.”

Steven Armstrong, Principal DevOps Automation Engineer, Paddy Power Betfair

In practical terms, this means QA engineers participate in story refinement sessions, contribute to acceptance criteria before a line of code is written, and write automated tests in parallel with development — not after a feature is declared “done” by the developer.

Separate QA Teams Are an Obstacle to DevOps Culture

Gordon Gracie, development team lead at insurer LV=, went further, arguing that the very existence of a separate QA function is structurally incompatible with a DevOps model.

“The biggest injustice you can have today is the idea of QA people in a separate role. Software engineers want to write great code. If the engineer is obsessed with quality, they’re also obsessed with testing that quality. Some people are experts in testing, but the idea of separate teams doing that work needs to be broken down. If you have that set up, you’re creating a culture that stops your engineers moving to a DevOps model.”

Gordon Gracie, Development Team Lead, LV=

Gracie’s point is not that testing expertise is irrelevant — it clearly is not. The concern is that when testing is institutionally separated from development, it creates a handoff boundary. That boundary introduces delays, miscommunication, and a diffusion of ownership over quality. Engineers pass code over a wall; testers find problems; code comes back. This cycle is fundamentally at odds with the fast-feedback loops that DevOps depends on.

Key Takeaways for Teams Starting a DevOps Initiative

1. Start with a real problem, not a framework. Find something that is causing pain right now — a flaky deployment, a manual handoff, a reliability bottleneck — and fix it. Don’t wait until you have a complete DevOps strategy.
2. Keep the first project small and visible. Early wins build trust and funding for larger changes. A contained improvement with a clear before-and-after metric is more valuable than a sprawling transformation with unclear outcomes.
3. Embed QA in the team from day one. Test criteria should be written alongside requirements, not after the code is complete. This is the practical meaning of shifting left.
4. Break down silos structurally, not just culturally. Telling separate teams to “collaborate more” rarely works. Physically or organisationally merging QA into delivery teams changes the incentives and the feedback loops.
5. Treat quality as an engineering responsibility. Testing expertise is valuable, but responsibility for quality should be shared across the whole team, not delegated to a separate function.

The Broader Lesson

DevOps transformations fail most often not because the technology is wrong, but because organisations wait for conditions to be perfect before they begin. They wait for full executive buy-in, a complete toolchain decision, or an agreed operating model. Meanwhile, the problems that DevOps is supposed to solve continue to compound.

The practitioners at Computing’s DevOps Summit offered a simpler operating principle: find the thing that hurts most, fix that thing, learn from it, and repeat. That is, in essence, what DevOps looks like in practice — not a destination arrived at through planning, but a habit built through iteration.

If you work in tech, you almost certainly have an opinion on DevOps. Critics argue it creates organisational friction and blurs accountability. Advocates — and there are many — say it is indispensable for shipping software reliably at scale. The truth is that both camps can be right, depending on how the practice is implemented. DevOps done badly is expensive noise. DevOps done well is a sustainable competitive advantage. The difference usually comes down to a handful of deliberate choices about what your DevOps team is actually responsible for.

The following three principles are drawn from operational experience at a high-growth technology company. They are intended for engineering leaders, platform engineers, and anyone responsible for shaping a DevOps function.

1. Task DevOps With Differentiating Your Technology Foundation

Commodity cloud services — AWS, Google Cloud Platform, Microsoft Azure — are genuinely excellent. They are also available to every one of your competitors on identical terms. Selecting a major cloud provider gets you to parity, not ahead. Real competitive advantage comes from what you build on top of, or alongside, the commodity layer.

A well-directed DevOps team can exploit lower-level differentiation that off-the-shelf cloud configurations do not expose. Examples include:

• Hardware-level tuning: Selecting workload-specific processors, or leveraging NVMe or high-throughput flash storage for latency-sensitive applications, can yield significant performance gains compared with default cloud instance types. The exact multiple depends heavily on the workload, but the principle — that specialised hardware outperforms generalised configurations for specific tasks — is well established.
• Hybrid deployment strategies: Intelligently mixing bare-metal co-location, private data centres, and public cloud regions allows you to optimise cost and latency simultaneously. This kind of blended architecture requires deliberate engineering; it does not emerge from simply clicking through a cloud console.
• Custom tooling for your specific domain: Generic infrastructure-as-code templates work for generic problems. If your product has unusual traffic patterns, data access patterns, or compliance requirements, bespoke automation built by your DevOps team will outperform off-the-shelf solutions.

The practical implication: when you scope your DevOps team’s roadmap, include explicit work items around infrastructure differentiation. If every sprint is pure maintenance, you are running fast to stand still.

2. Build Tools That Let Engineering Scale Without Adding Headcount

One of the clearest measures of a healthy DevOps function is whether it reduces the per-engineer operational burden over time. If onboarding a new engineer requires a week of manual environment setup, or if deploying to production requires a specialist in the room, your DevOps team has not yet solved the scaling problem.

The mechanism that makes scaling possible is systematic automation. Every infrastructure decision should be deliberate, documented, and encoded as repeatable automation rather than tribal knowledge. Concretely, this means:

• Automated server provisioning: New capacity should be spun up via code, not manual clicks. Tools such as Terraform, Ansible, or Pulumi make this reproducible across environments.
• Automated deployment pipelines: Code should flow from development through staging to production via a CI/CD pipeline (Jenkins, GitHub Actions, GitLab CI, and similar tools are common choices) with automated tests acting as gatekeepers at each stage.
• Automated anomaly detection and alerting: Observability stacks — combining metrics (Prometheus, Grafana), logs (the ELK stack or similar), and traces (Jaeger, OpenTelemetry) — should surface problems before users report them.
• Environment consistency: Configuration management tools (Chef, Puppet, Ansible) and container orchestration (Kubernetes) ensure that the environment a developer tests against matches what runs in production, eliminating entire categories of “works on my machine” bugs.

The test of success: can a developer who joined last month ship a feature to production without filing a ticket with the DevOps team? If the answer is yes, the platform is working. If the answer is no, the DevOps team is a bottleneck rather than an enabler.

3. Never Let DevOps Become an IT Help Desk

This is the most common failure mode for DevOps teams, and it is worth stating plainly: the moment your DevOps engineers are spending the majority of their time on laptop configuration, VPN access requests, or user onboarding, the team has become an IT support function. That is not a criticism of IT support — it is a legitimate and important discipline — but it is a completely different job with a completely different value model.

DevOps exists to drive infrastructure innovation and engineering velocity. IT support exists to keep individual users productive. Conflating the two harms both outcomes: users get slower support from engineers who resent the interruption, and infrastructure work stalls because the engineers are distracted.

How to detect the IT trap: Review your DevOps team’s ticket queue or task tracker. Ask these questions:

• What percentage of tickets come from individual users requesting help with their devices or access permissions?
• What percentage represent architectural improvements, performance work, or tooling that benefits all engineers?
• Is the ratio shifting over time — more user requests, fewer infrastructure projects?

A practical heuristic: if more than roughly 10% of DevOps capacity is absorbed by individual user requests, you have a structural problem worth addressing. The fix usually involves one of three approaches: hiring dedicated IT support staff, implementing self-service tooling (identity management platforms, automated access provisioning), or explicitly re-scoping the DevOps team’s mandate in writing so that boundaries are clear.

Putting It Together

None of these principles require a large team or a large budget. They require clarity of purpose. A DevOps team that knows it is responsible for differentiating the infrastructure, enabling engineers to scale independently, and staying out of the IT support business will naturally make better decisions about how to spend its time.

Conversely, a DevOps team without that clarity will drift toward whatever is loudest and most urgent — which is almost always user-facing problems rather than strategic infrastructure work. The loudest problems are rarely the most important ones.

If you are building or restructuring a DevOps function, start by writing down what the team is not responsible for. That boundary-setting exercise often reveals misalignments faster than any amount of process documentation. Once the scope is clear, the three principles above give you a practical framework for evaluating whether the team is delivering real business value — or just keeping the servers on.

While driving home, I heard this song from Rolling Stones

You can’t always get what you want
But if you try sometimes, well you just might find
You get what you need.

And the song made me think. In 2017, we are absolutely bombarded by choices and things evolve faster than ever, so how can you actually get what you need? For example, recently I had to guide someone searching for that perfect DevOps tool. In such a tool search, if you just Google ‘DevOps Tools’, an endless list of tools will sit and stare at you.

How can you choose the right DevOps tool for your organization?

If you’ve ever wondered if you need to adopt DevOps or even wondered what the hell it is, we have the answer for you. It is a practice where operations and development professionals or engineers participate in the entire service life-cycle (which means starting from design to development and till the production support stage). It is a recipe of success through cultural shift. If you are ready for DevOps adoption, it implies that you are ready to change fast, develop fast, test fast, fail fast, recover fast, learn fast and also prepared for product launch equally fast.

Organizations which fear change are skeptical to adopt new methodologies like DevOps. The methodology is especially useful for a company that is offering a software platform which is used by other companies. Through DevOps, one can easily resolve and mitigate the technical hiccups in the software within a short time.
Nagios, Monit, ELK (Elasticsearch, Logstash, Kibana), Confluence, JIRA, Consul.io, Docker, Jenkins, etc. are just some of the most popular DevOps tools available in the market today.

But how do you decide which DevOps tool will be the most suitable for your requirements?
Most of the tools that are available help to automate the process of software delivery. Amongst the available options, you can select the right one depending on your requirements. Choosing the right DevOps tool also depends on whether the tool can help you with all the phases which are – plan, build, continuous integration, deploy, operate, and continuous feedback.

PLAN
With a tool that you can help you ‘Plan’, you can learn about user requirements very quickly. You should look for a tool that provides sprint planning features. Sprint planning is a concept of ‘Agile Methodology’ wherein the product owner facilitates a meeting with the entire team and discusses the acceptance criteria. The tool should have a feature that helps team members to comment and share ideas, goals, strategies, assess and discuss requirements and contribute to road-maps.

BUILD
DevOps tools that allow coding in a virtual environment are likely to yield better results as there can be multiple variations that can be tried. Developers can create modular applications as these are more reliable and easy to maintain. Tools that allow collaborative coding are also becoming popular.

CONTINUOUS INTEGRATION
CI or Continuous Integration is a process wherein the code is submitted in a shared repository several times a day and tested each time. It is a reliable way to detect bugs early on and fix them before the cost of fixing them gets too high. DevOps tools that allow multi-branch environment are preferable. Some of these tools are Bamboo and HipChat.

DEPLOY
During deployment, one of the biggest challenges is to get all the information related to change, testing and deployment at one place. With a tool that can’t provide a provision to store everything in one place, doing status reporting at the end of project becomes a huge challenge.
Tools that provide dashboard that can be integrated into your code repository and gives a full visibility on deployment details like pull requests, deployment warnings, branches, etc.

OPERATE
There is a need to automate server monitoring and application performance monitoring. Tools like BigPanda, HipChat, Nagios, Splunk, etc. are also able to integrate group chat and get it quickly to the team so that there are no communication gaps and issues can be fixed faster.
Tools like JIRA are able to keep a track of incidents, changes and fix problems faster.

CONTINUOUS FEEDBACK
The key is to be attentive to client’s feedback. There are different ways to capture client feedback, some of which are client surveys like NPS, bug reports, tweets, etc. Tools that are able to integrate chat with the survey platform are an excellent choice. There should be an option to integrate real-time feedback that comes through social media channels like Facebook and Twitter.

Choosing the right DevOps tools largely depends on which area does your organization needs maximum help. The main objective of any DevOps tool, which you select, is to make the development cycle faster and improve cross-functional and internal collaboration and communication.

Why Enterprise DevOps Adoption Is Different

When a company says it wants to adopt DevOps, the first practical question is scale: how large is the organization, and how far does it intend to take the transformation? The answer changes everything. For smaller teams, DevOps adoption can be relatively organic. For large enterprises managing dozens of applications, hundreds of developers, and deeply entrenched organizational boundaries, the complexity grows dramatically.

At enterprise scale, a successful DevOps initiative requires two foundational commitments: first, a clear directive on how people and processes will be organized to manage application lifecycles and their interdependencies; and second, deliberate selection of the technologies that will manage those lifecycles and delivery pipelines. Without both, even well-funded initiatives stall.

DevOps Governance: What It Must Cover

Governance is not a bureaucratic afterthought — it is the scaffolding that allows multiple teams to move in the same direction. Effective DevOps governance should explicitly address each of the following areas:

• Cloud-based infrastructure services — both private and public options, with clear policies on provisioning and access
• Development workstation standards and images — reducing environment drift before code ever reaches a pipeline
• Source control standards — branching strategies, naming conventions, and repository ownership
• Continuous Integration (CI) — build triggers, artifact management, and failure response
• Continuous Delivery (CD) — promotion gates, environment promotion policies, and rollback procedures
• Testing methods and required coverage — unit, integration, security, and performance testing thresholds
• Configuration management — how infrastructure and application configuration is defined, versioned, and applied
• Continuous monitoring — what is measured, who owns alerts, and how incidents feed back into development
• Standardized health reporting — a consistent method for communicating Business Health, Operational Health, Testing Health, Development Health, and Pipeline Health across all applications

Leadership also has a strategic responsibility: carefully selecting which applications in the enterprise will genuinely benefit from DevOps practices first. Not every application is an ideal candidate for an initial rollout, and choosing poorly wastes political capital and resources.

The Four Biggest Pitfalls in Enterprise DevOps Adoption

1. No Comprehensive Plan

This is the most damaging pitfall. IT executives often have the ambition to adopt DevOps but fail to commit to a clear, well-defined plan for the full transition. Without a single top-down approach and active executive sponsorship, DevOps initiatives fracture. Infrastructure, testing, project management, development, and operations teams end up with different — and often conflicting — priorities. The result is a DevOps team broken into factions, each championing its own interpretation of what DevOps means for the organization.

Watch for these tell-tale symptoms of fragmentation:

1. Cloud services are unavailable or inaccessible to application teams.
2. Configuration management tools exist but are not consistently used.
3. Feedback loops only function within specific groups, not across team boundaries.
4. Development teams do not prioritize DevOps-related tasks in their sprint planning.
5. Agile practices are applied only within development, not across the full delivery pipeline.
6. Departmental silos persist and actively suppress cross-team innovation.
7. Individual groups spend excessive effort justifying DevOps to other departments rather than practicing it.

2. No Cross-Functional Training

Many organizations suffer from a significant gap between the tools and processes they adopt and the training investment they make in the people who must use them. A common pattern: the application team is nominally cross-functional on paper, but individuals from other departments continue to operate in their traditional siloed roles, never learning the adjacent technologies or workflows that DevOps depends on.

When teams are not educated on cross-functional processes and technologies, DevOps adoption degrades slowly and painfully. People revert to familiar patterns, handoffs accumulate latency, and the pipeline never achieves the flow it was designed for. Training must be a planned, budgeted, ongoing activity — not an afterthought left to individuals to pursue on their own time.

3. Missing DevOps Roles

A lack of planning and training directly creates a third problem: critical roles and responsibilities are simply absent from the organizational structure. This often goes unnoticed until something breaks and there is no clear owner to fix it.

The remedy is deliberate org design. A well-structured cross-functional agile team should be built around a specific application pipeline — not assembled from representatives of separate departments who remain primarily loyal to their original team. Ownership of the pipeline, the product, and the delivery process must live in one unified team with clear divisions of responsibility and accountability.

4. Information Stuck in Silos

Large organizations typically accumulate valuable data: operational dashboards, test result reports, deployment metrics, and development status indicators. Individual teams often build impressive internal tooling and refine processes within their own scope. The problem is that without an agreed-upon, centralized standard for sharing this information across the organization, all of that insight remains local.

Siloed information means siloed innovation. If the operations team has discovered an effective monitoring pattern, but development never sees it, the benefit is contained. If testing surfaces a recurring defect category, but it never reaches architecture discussions, the root cause is never addressed. A shared information standard — covering how dashboards are structured, what metrics are reported, and how frequently — ensures that individual improvements compound into organizational improvement.

Key Takeaways

Enterprise DevOps adoption is fundamentally an organizational challenge as much as a technical one. The principles are consistent across companies that succeed:

• Start with a comprehensive, documented adoption plan backed by executive commitment.
• Define governance across all pipeline domains before selecting tools.
• Invest in cross-functional training as a first-class activity, not an optional supplement.
• Build teams around pipelines and products, not around traditional departmental boundaries.
• Establish a shared information standard so that insights from any team benefit all teams.

The best DevOps adoption initiatives are driven from the top, backed by coordinated leadership, and structured so that every functional area has both a stake and a role in the outcome. Without that foundation, even the best toolchain and the most capable engineers will struggle to deliver lasting results.

The five steps below cover the foundational ideas every team should address when adopting or improving a DevOps practice.

1. Understand the 6 C’s of the DevOps Cycle

DevOps is a continuous loop, not a one-time project. Familiarize yourself with each phase before you start making changes to your pipeline.

• Continuous Business Planning. Identify the skills, expected outcomes, and resources you need before a single line of code is written. Planning never stops—each release cycle feeds back into the next planning phase.
• Collaborative Development. Development starts with a shared sketch plan. Developers, operations engineers, and product owners work together from the outset rather than handing work over the wall.
• Continuous Testing. Unit tests, integration tests, and automated regression suites run throughout development—not just at release time. Early, frequent testing catches defects when they are cheapest to fix.
• Continuous Release and Deployment. A well-built CD pipeline automates code reviews, gating, and deployment to production or staging environments, making frequent releases safe and repeatable.
• Continuous Monitoring. Once code is deployed, monitoring tools capture performance metrics, error rates, and infrastructure health. Alerts surface problems immediately rather than after users complain.
• Customer Feedback and Optimization. Real user feedback—through feature flags, A/B tests, support tickets, and analytics—drives the next planning cycle, closing the loop between engineering and business value.

2. Choose and Master the Right Tools

DevOps is a culture and a practice, not a toolchain—but the right tools make the practice sustainable. Management must invest in proper training so that developers and operations engineers are genuinely proficient, not just nominally licensed.

Common categories and representative tools include:

• Source Control: GitHub, GitLab, Bitbucket
• Configuration Management & Infrastructure as Code: Ansible, Chef, Puppet, Terraform
• Containerization: Docker, Podman
• Container Orchestration: Kubernetes, Amazon ECS
• Issue & Project Tracking: Jira, Linear
• Cloud Platforms: AWS, Azure, Google Cloud
• CI/CD: Jenkins, GitHub Actions, CircleCI, GitLab CI
• Team Communication: Slack, Microsoft Teams

Start with the tools that address your biggest bottleneck. Adding every tool at once creates complexity without value.

3. Deploy Frequently and Automatically

One of the clearest signals of a healthy DevOps practice is deployment frequency. If your team deploys once a quarter, bugs accumulate, release risk grows, and feedback loops lengthen. The goal is to deploy small, well-tested increments often—ideally multiple times per day in mature organizations.

Frequent, automated deployments require:

• A fully automated CI/CD pipeline that builds, tests, and deploys on every merged commit.
• Feature flags to decouple deployment from release, letting you ship code without exposing it to all users immediately.
• Automated rollback mechanisms so that a bad deployment can be reversed quickly without manual intervention.
• A culture that treats a fast rollback as a success, not a failure—because learning quickly is the point.

4. Adopt Containers and a Microservices Architecture

Automation—the engine of DevOps—is significantly easier when your application is composed of small, independently deployable services running in containers.

• Containers (Docker being the most common runtime) package an application with all its dependencies, producing a consistent artifact that behaves identically in development, testing, and production.
• Microservices architecture breaks a monolithic application into loosely coupled services, each owned by a small team. This lets teams deploy their service independently, reducing coordination overhead and release risk.

A word of caution: microservices introduce operational complexity—service discovery, distributed tracing, and network latency are real concerns. Evaluate whether your team’s scale justifies the trade-off before decomposing a working monolith.

5. Build Constant Communication Between Teams

DevOps collapses the wall between development and operations. That only works when both sides communicate continuously. Siloed teams produce siloed systems—deployments break because an operations engineer didn’t know a developer changed an environment variable.

Effective communication practices include:

• Shared chat channels (Slack, Teams) organized around services or incidents, not just team membership. This gives everyone visibility into what is deployed and what is broken.
• Blameless post-mortems after incidents, so that findings are shared across teams and mistakes become systemic improvements.
• Automated notifications from your CI/CD pipeline posted directly to team channels, so that deployment success or failure is visible without anyone having to ask.
• Regular cross-functional standups or syncs between development, operations, security, and product to surface blockers early.

Putting It Together

Whether you are at the start of your DevOps journey or trying to improve a practice that has stalled, these five areas—understanding the full DevOps cycle, investing in the right tools, deploying frequently and automatically, leveraging containers and microservices, and maintaining constant cross-team communication—give you a solid framework for diagnosis and improvement.

DevOps is not a destination you reach once. It is a continuous improvement loop, and the teams that treat it that way are the ones that see lasting results.

Original source referenced: dzone.com (2017).