At the same time, database estates are growing. The same research found that 45% of DBAs expect to manage more databases in the coming year, while 43% expect their estate to remain the same. Cloud migration was cited as the biggest challenge by 22% of respondents. With greater workloads and more frequent changes, it is perhaps unsurprising that human error tops the list of issue causes at 22%, ahead of capacity problems and bad deployments.

For DBAs, surviving and thriving in a DevOps environment means focusing on four distinct areas: standardization, automation, monitoring, and data compliance.

Managing Databases in a DevOps World

The database is now a core component of the DevOps pipeline for many organizations. DBAs can no longer operate in isolation. They need to work alongside developers, adopt shared tooling, and contribute to the same CI/CD pipelines that development teams use. This shift requires DBAs to rethink both their processes and their relationship with the wider engineering team.

Standardizing Approaches Across DevOps Processes

Human error is the leading cause of database issues, and it becomes a bigger risk when larger, mixed teams of DBAs and developers are all making changes to the same database. Standardizing processes is the most effective way to reduce this risk.

Practical standardization steps include:

• Adopting a team-wide coding style for database objects, so that SQL written by any team member follows the same conventions. This makes code reviews faster and reduces confusion-driven errors.
• Using industry-standard development tools consistently across the team, rather than letting individuals choose their own editors or migration frameworks.
• Integrating database scripts into version control alongside application code. Merging changes early and often gives the team a single source of truth and makes it easier to identify when and where a problem was introduced.

Without these guardrails, a minor inconsistency in a schema change can escalate quickly into a production incident that is difficult to diagnose and expensive to roll back.

Automating for Speed and Consistency

Developers who have adopted DevOps already understand the value of continuous integration (CI), continuous delivery (CD), and continuous deployment. Automation reduces manual effort, eliminates whole categories of human error, and produces an auditable record of every change — a significant benefit for regulatory compliance.

Extending these same practices to the database delivers equivalent benefits for DBAs. A typical database CI/CD workflow might look like this:

1. A developer commits a schema change to version control.
2. A CI pipeline is automatically triggered, building a test database and applying the change.
3. Automated tests validate the change and flag any errors immediately.
4. The developer fixes errors and the cycle repeats until the change is clean.
5. The validated change is passed to a release management tool for review and approval before deployment to production.

This approach shortens the feedback loop dramatically and reduces the risk of broken database changes reaching production. However, automation is only as effective as the processes and tooling that support it. Organizations need to invest in the right database DevOps toolchain and ensure that DBAs are involved in designing the pipeline, not just subject to it.

Stepping Up Monitoring to Drive Continual Improvement

Continual improvement is a core DevOps principle, and it applies equally to the database. Monitoring plays a central role in enabling it.

At the operational level, database monitoring tools surface performance degradation, slow queries, blocking, and resource contention before they cascade into outages. DBAs in the Redgate research cited performance issues as a major ongoing challenge, which underlines how important proactive monitoring is at higher deployment frequencies.

Beyond reactive alerting, monitoring data provides the trend information teams need to improve proactively. According to the Redgate research, 40% of organizations already share database monitoring data with developers. This visibility helps developers understand the performance impact of their code changes and identify opportunities for optimization earlier in the development cycle — a clear example of DevOps collaboration generating tangible results.

Guarding Personal Data and Ensuring Regulatory Compliance

Data privacy regulations are expanding globally. The EU’s GDPR, the California Consumer Privacy Act (CCPA, which came into force in January 2020), and similar legislation in other jurisdictions place significant obligations on organizations that process personal data. Organizations must treat themselves as data guardians, not data owners.

This creates a specific tension in DevOps workflows: developers need realistic data to build and test against effectively, but production datasets containing personal information cannot simply be copied into development and staging environments. The solution is data masking and anonymization — tooling that replaces sensitive values with realistic synthetic equivalents so that developers can work with data that behaves like production data without exposing real personal information.

Effective data masking tools also generate an audit trail of how data was handled throughout the pipeline, which supports compliance reporting and reduces the risk of breaches during development and testing activities.

Key Takeaways for DBAs in a DevOps Environment

• Deployment frequency is rising. DBAs need processes that can scale with frequent, sometimes daily, database changes without accumulating risk.
• Human error remains the top threat. Standardized tooling, shared coding conventions, and version control reduce the surface area for mistakes.
• Automation is a force multiplier. CI/CD pipelines applied to database changes catch errors early and create compliance-ready audit trails.
• Monitoring supports both reliability and improvement. Sharing monitoring data with developers creates a tighter feedback loop and improves overall system performance.
• Compliance is non-negotiable. Data masking and anonymization tools allow development to proceed at speed without exposing sensitive data.

DevOps has permanently changed the relationship between DBAs and development teams. Organizations that bring their databases fully into the DevOps pipeline — with the right processes, automation, monitoring, and compliance tooling — will be better positioned to manage increasing workloads and maintain the reliability their business depends on.

This article draws on findings originally reported in the Redgate 2019 State of SQL Server Monitoring Report and an article by Matt Hilbert published on devops.com.

There are three foundational areas every organisation must address before — or alongside — a DevOps transition: technology-enabled agility, collaborative operating models, and competency orchestration. Each area surfaces its own set of challenges, and neglecting any one of them will limit the effectiveness of the others.

1. Technology-Enabled Agility

Of the three areas, achieving technology-enabled agility is the most tractable — provided your development and operations teams have reached a comparable level of maturity. The problem is that Dev and Ops often start from very different priorities: developers optimise for speed of change, while operations teams optimise for stability. Bridging that gap requires more than shared tooling; it requires a shared definition of what “good” looks like.

A useful benchmark for shared maturity is when both teams can demonstrate:

• Visibility and control over the flow of work in their business context
• Measurably reduced release cycle times
• Active management of bottlenecks and constraints
• Prevention of defect handoffs downstream — quality gates built into the pipeline
• Elimination of unnecessary waiting times between stages
• A working feedback loop that reaches back to the earliest stages of design and definition

Greater agility emerges from better communication enforced by process, not just goodwill. One concrete approach is resilience engineering: continuously tightening the key performance indicators (KPIs) for each development activity. Gradually raising the bar forces teams to build new habits and improve performance incrementally rather than attempting a single large transformation.

2. Collaborative Operating Models

Building a genuinely collaborative operating model is the hardest of the three challenges. Almost every organisation falters on its first attempt because it underestimates the depth of cultural change required. A new Jira board or a shared Slack channel does not constitute collaboration.

Breaking Down Silos

The starting point is forming a multidisciplinary group — spanning internal staff and suppliers — with a shared vision anchored to business value rather than departmental metrics. Everyone must understand the full IT-enabled value stream, not just their slice of it.

Extending Practices Across the Boundary

Collaboration cannot stop at the handoff point. Development practices need to extend into operations and operations disciplines need to flow back into development. In practical terms, this means:

• A single source of truth — one repository that both teams work from
• Trail-based quality gates baked into build and deploy pipelines
• Standardised, repeatable build and deployment processes
• Simulated production environments used during development, not just after release
• A single, clearly identified point of accountability across the end-to-end operating model

Building Trust Without Manufacturing It

Organisation design and process changes are necessary enablers, but they are not sufficient. Trust cannot be imposed by management — it must be built by the team members themselves. This requires treating all information and work as collective, not individual, property, and recognising that success is interdependent. When that mindset takes hold, the efficiency of collaboration becomes a leading indicator of organisational health.

A practical tool for supporting this is a central knowledge bank — a visual “work map” that shows associated work centres and their interdependencies, much like a city map marked with a “You are here” indicator. It gives every team member orientation and a quick path to the relevant context.

Design for Operations — and Vice Versa

Development teams must involve operations in “design for operations” — considering operability, observability, and runbook requirements from the earliest design stages. In return, operations teams must keep development informed about operational reality so that “operations work; don’t go backward” — meaning no rework, no unplanned remediation work generated by operationally naïve design decisions.

The recurring stumbling blocks in this area are culture, cooperation, compartmentalisation, and contractual constraints (especially where third-party suppliers are involved). Addressing all four simultaneously is difficult, which is why collaborative operating models take the longest to establish and are the most common source of DevOps stalls.

3. Competency Orchestration

Competency orchestration means aligning roles, skills, and capabilities across the organisation so that they work together seamlessly. It is frequently misread as a platform or tooling exercise — “we just need a better automation platform” — but that framing is too narrow.

True competency orchestration involves the bidirectional integration of the system of engagement (the interfaces and workflows people use daily) with the system of record (the authoritative data and process repositories). That integration spans people, process, and technology — not technology alone.

To orchestrate competencies effectively, organisations should work toward the following:

• A service-aligned competency framework — roles and skills defined around services delivered, not purely around technology stacks, with DevOps practices embedded into both technology and process elements of service provision.
• A unified DevOps practice — capable of handling a large and diverse application portfolio consistently, rather than creating bespoke pipelines for every team or product.
• An integrated measurement model — a coherent view of metrics across the full infrastructure and services stack, with no isolated automation islands that generate data no one connects to the rest.
• A service catalogue — with customisable, standardised service offerings aligned to the development, integration, and deployment platform. This is a prerequisite for meaningful DevOps toolchain integration, not an afterthought.
• A minimum viable product (MVP) model per feature — each feature release delivers just enough functionality to gather real user feedback and guide the next iteration, avoiding large batch releases.
• Full-stack continuous monitoring and notification — observability and alerting treated as first-class concerns across the entire product release lifecycle, not bolted on after the fact.

Putting It Together: A Sequenced Approach

None of these three areas can be tackled in complete isolation, but understanding their relative difficulty helps prioritise effort:

Technology-enabled agility is the fastest win because it is primarily a process and tooling problem. Collaborative operating models are the hardest because they are fundamentally a human problem. Competency orchestration sits in between — it requires both structural changes (the service catalogue, measurement model) and cultural ones (shared accountability).

Key Takeaways

• DevOps readiness is not primarily a tooling question. Tools amplify what is already there; they cannot compensate for absent collaboration or misaligned maturity.
• Dev and Ops teams must converge on a shared definition of maturity — not just a shared toolchain.
• Collaborative operating models require real trust built by teams themselves, supported by structural changes like single sources of truth and shared accountability.
• Competency orchestration should be framed as a service-alignment problem, not a platform problem.
• Continuous monitoring and a workable MVP model are not optional extras — they are core to sustaining a “continuous everything” DevOps mindset.

The organisations that succeed with DevOps are those willing to invest in all three areas in parallel, accepting that the cultural and organisational changes will take longer than the technical ones — and that the payoff is proportional to that investment.

Why DevOps Looks Like a Farce (at First)

Consider for a moment the core practices DevOps advocates for, and then imagine arguing against each of them in turn:

• Developers collaborating directly with users — Sounds risky. Surely customers should only interact with a formal interface?
• Developers and operations staff working together — Why not keep all communication through a ticketing system?
• Operations included in release planning — Won’t they just slow things down?
• Customer service briefed on new features before release — What value does that add?
• Test-first development practices — Seems like overkill for most teams.

Every one of those objections reflects how many organizations actually operated before the agile movement — and how some still operate today. The irony is that IT staff often have the clearest view of what keeps systems stable, and customer service representatives frequently surface the most actionable product feedback, simply because they interact with both the software and its users every day. Locking those people out of the development process is a real organizational cost, not a risk mitigation strategy.

Bimodal IT in a Nutshell

Gartner’s Bimodal IT model proposes that organizations run two distinct modes of IT delivery in parallel:

• Mode 1 — Predictable, stable, and deliberate. Suited to legacy systems and core business applications where reliability is paramount. Change is gradual and well-understood.
• Mode 2 — Exploratory and fast-moving. Suited to new product development, emerging technology adoption, and innovation initiatives where speed and experimentation matter more than certainty.

The underlying assumptions of Bimodal are worth naming explicitly:

• Agile and DevOps are best suited to new projects and nimble organizations.
• Applying DevOps to legacy systems introduces unacceptable risk.
• Organizations must choose between speed (DevOps) and quality (traditional approaches).
• Different applications require fundamentally different operating modes.

The Upsides of Bimodal IT

Bimodal IT is not without merit. Its strongest contribution is the explicit encouragement of pilot projects around emerging technology areas. Organizations have historically benefited from treating early-stage technology exploration — whether cloud adoption, NoSQL databases, mobile application development, or earlier waves like the move to the web — as a distinct track that operates under different rules and risk tolerances than core systems. For many enterprises, the instinct to ring-fence experimentation is pragmatic and organizationally sensible.

The Downsides of Bimodal IT

The problems with Bimodal IT become apparent when you try to apply it consistently across a real organization:

Who Decides Which Mode an Application Belongs To?

Categorizing applications as Mode 1 or Mode 2 forces difficult and often arbitrary value judgments. Which applications — and therefore which users — deserve faster delivery? More innovation? Higher quality? Better support? Bimodal does not provide a clean answer to those questions, and in practice, the answers tend to reflect organizational politics rather than user needs.

It Recreates the Silos DevOps Was Designed to Eliminate

Running two separate development processes, toolchains, and team cultures creates exactly the kind of organizational fragmentation that DevOps addresses. Mode 1 teams risk becoming a professional dead-end. Mode 2 teams risk becoming disconnected from the operational realities that keep production systems stable.

Most Applications Cannot Be Cleanly Categorized

Modern systems are rarely self-contained. Consider airline reservation and ticketing applications: the mobile-facing booking interface may follow a fast agile release cycle, but it is almost certainly tightly coupled to legacy transactional back-end systems. A change on either side typically requires coordination with the other. Labeling one component Mode 1 and the other Mode 2 does not eliminate that interdependency — it just obscures it.

The Speed-Quality Tradeoff Is a False Choice

Research from Puppet Labs and others (including the annual State of DevOps reports) has consistently found that high-performing technology organizations deliver both faster deployment frequency and higher reliability than low-performing organizations — not one at the expense of the other. The tradeoff Bimodal assumes is empirically weak. Additionally, practitioners including Gene Kim have cited data suggesting that a significant proportion of successful DevOps transformations — reportedly around 60% — involve legacy rather than greenfield applications, which challenges the assumption that DevOps is unsuitable for established systems.

How to Reconcile Bimodal IT with DevOps

The underlying intent of Bimodal IT — recognizing that different systems carry different risk profiles, and that organizational change requires structure — is reasonable. The implementation, however, tends to produce the wrong outcomes. The following approaches preserve that intent while avoiding the pitfalls.

Focus on People, Not Applications

Every organization has individuals who are more receptive to new methods, regardless of which system they support. Instead of assigning an application to Mode 1 or Mode 2 and locking its team into that mode, identify the people most likely to succeed with a DevOps approach and build early wins around them. Let demonstrated success drive broader adoption rather than top-down categorization.

Invest in Collaboration and Feedback Loops

Most organizations — regardless of application type — have room to improve communication between development, operations, and end users. Shortening feedback loops is beneficial across the board. It is not a Mode 2-only concern.

Break Down Silos Rather Than Formalizing Them

Bimodal can inadvertently legitimize the organizational silos that DevOps is designed to dismantle. People generally do not want to be confined to a narrow, unchanging role. Offering expanded responsibilities and cross-functional opportunities tends to be more motivating and more productive than enforcing strict operational boundaries.

Treat Shadow IT as a Signal, Not a Problem

Unsanctioned technology adoption — shadow IT — has a long history of producing genuine innovation, from early PC adoption to the emergence of cloud services. Rather than suppressing it, investigate why teams are working around official channels and address the underlying friction. The goal is to make the official path less painful, not to eliminate the pressure that drives people to find workarounds.

Reframe Speed as Speed to Value

The concern that DevOps moves too fast for legacy applications usually conflates release velocity with release risk. A more productive framing is speed to value: getting the most important changes to users sooner, in smaller increments, with fewer changes per release. Smaller releases are inherently lower risk than large batch deployments, regardless of the age of the underlying system.

Expand the DevOps Definition Beyond Dev and Ops

DevOps is a useful shorthand, but the label can create artificial boundaries. The principles apply equally to quality assurance, customer service, product management, and executive leadership. A broader definition of who participates in DevOps practices — and who benefits from them — will produce better outcomes than one confined to engineering teams.

Conclusion

Bimodal IT and DevOps are not inherently incompatible. The stability and risk-awareness that Bimodal advocates for are legitimate organizational concerns. The rapid delivery, continuous feedback, and cross-functional collaboration that DevOps advocates for are not threats to stability — they are, when properly implemented, mechanisms for achieving it.

The key shift is to stop treating application age as a proxy for the appropriate development approach, and to stop treating speed and quality as a zero-sum tradeoff. Innovation can and should happen across your entire portfolio — in legacy systems as much as in new ones. A DevOps practice that is inclusive of the whole organization, measured honestly, and built on genuine cross-functional collaboration will reduce risk, increase agility, and create competitive advantage from systems that might otherwise be treated as liabilities.

A few years ago, if you had asked many practitioners to define DevOps, the answer would have sounded something like: “Automation, infrastructure-as-code, automation, pipelines, more automation.” That answer is understandable — most early DevOps content focused almost exclusively on tooling — but it is also dangerously incomplete.

Automation is part of a DevOps practice, but it is arguably only 5–10% of what makes DevOps work. The reason so much writing has concentrated on automation is simple: tools are easy to write about. Relative to the harder cultural and organisational changes that DevOps demands, automation is the straightforward part.

What DevOps Actually Represents

Gartner’s widely cited definition provides a useful baseline:

DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.

Notice the order: culture comes first, collaboration comes second, and automation is mentioned last. The main components of DevOps are people and process. Automation is a force-multiplier — a lever — but without the right people and processes behind it, that lever accomplishes little of lasting value. At worst, automation without process simply lets teams make mistakes faster and at greater scale.

People: The Cultural Foundation of DevOps

At the heart of a successful DevOps practice is a culture that accepts failure, avoids blame, and demands collaboration and knowledge sharing. Each of these properties is load-bearing.

Accepting Failure Prevents Mediocrity

If team members fear how their manager reacts when they make a mistake, they will not attempt new approaches. The team stagnates while competitors who have embraced failure as a learning opportunity move forward.

Accepting failure does not mean lowering expectations or tolerating poor work. It means creating conditions where people surface problems quickly rather than hiding them. The expectation should be explicit:

“Mistakes happen. Don’t hide your errors. Communicate what happened, work on fixing it, and above all — learn from it.”

That posture directly reduces the destructive impulse to assign blame. Time spent deflecting responsibility is time not spent fixing the problem, and it poisons team trust in the process.

Removing Roadblocks to Collaboration

If your goal with DevOps is faster, higher-quality delivery, roadblocks must be aggressively removed. Fear, political gamesmanship, and mistrust between developers, operations, and the business are not minor inconveniences — they are blockers that need to be eliminated.

As a manager, tolerating finger-pointing within your team is a failure of leadership. DevOps culture requires that co-workers trust they will not be thrown under the bus for raising problems honestly.

Knowledge Sharing Is Non-Negotiable

If only one person knows how a critical system works, that person is a single point of failure for the entire delivery pipeline. There is no such thing as being “too busy to document” or “too busy to train a colleague.”

Knowledge hoarding — whether deliberate or through neglect — must be treated as a serious team-health issue, not a personal quirk. Normalise documentation, pair work, and cross-training as standard expectations, not optional extras.

Process: Where DevOps Actually Begins

You can have excellent automation and a strong culture and still not be practising DevOps if the underlying processes are missing or broken. Process is where meaningful DevOps transformation starts, and it delivers a higher return on investment than any tooling investment that follows.

Without defined processes, there is too much chaos to maintain a healthy culture, and any automation you build is likely solving the wrong problems.

Make Work Visible

The first step is giving the entire team visibility into the work backlog — not just managers. When everyone can see what is in flight, two expensive failure modes disappear:

• Duplication of effort: “I already have a script that does that.”
• Unintended side-effects: “Doing X while Y is in progress will cause Z to fail.”

Kanban boards, sprint backlogs, or any similar tracking mechanism only work if the team actually uses and maintains them. A board that goes stale within two weeks is a symptom of a process problem, not a tooling problem.

Require Accountability in Stand-ups

Daily stand-ups serve one primary purpose: shared situational awareness. Vague updates like “I’m working on server things” provide no value. The expected answer is specific: “Today I’m doing X, Y, and Z.”

This transparency is not about micromanagement. Every unknown status compounds delays, reduces quality, and erodes trust. The team needs to know what is happening — or not happening — so everyone can plan accordingly.

Agile Work Management Is a Prerequisite

If your team is not managing work in an Agile way — using Scrum, Kanban, or something comparable — the conditions for DevOps do not yet exist. Ad-hoc, undocumented work execution is incompatible with the feedback loops and continuous improvement that DevOps depends on.

Commitment to process requires continual reinforcement from both peers and management. “We set up a Kanban board and nobody used it, so we stopped” is not an acceptable outcome. Failure to update the board is itself a process failure that must be addressed — not a reason to abandon the process.

Where Automation Actually Fits

Once people and process are in place, automation becomes genuinely powerful. Continuous integration pipelines, infrastructure-as-code, automated testing, and deployment automation all amplify the output of a high-functioning team. Without that foundation, the same tools amplify dysfunction instead.

Think of automation as a socket wrench. In the hands of a skilled mechanic following a clear process, it speeds up the work enormously. Rusted and handed to someone with no process and no training, it is just a blunt instrument.

Further Reading

If you want to go deeper on the non-automation aspects of DevOps, two frequently recommended starting points are The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford, and Effective DevOps by Jennifer Davis and Ryn Daniels. The critical reviews of Effective DevOps are instructive in themselves: the most common complaint is that the author did not talk enough about automation tools — which suggests she got the balance exactly right.

Original source: dev.to. Republished and expanded for a DevOps engineering audience.