What Is Cloud Computing?

Cloud computing is the delivery of on-demand computing services—including servers, storage, databases, networking, analytics, and software—over the internet. Instead of owning and operating physical hardware in a private data centre, organisations consume those capabilities as a metered service from a cloud provider and pay only for what they use.

The analogy most practitioners reach for is a utility bill: you do not build a power plant to run your office; you plug in and pay per kilowatt-hour. Cloud computing applies the same logic to compute and storage resources.

How Cloud Computing Works

Cloud providers maintain massive, globally distributed data centres full of physical servers, networking equipment, and storage hardware. They virtualise those resources and expose them through APIs and management consoles. Customers provision what they need—a virtual machine, a managed database, a container orchestration cluster—without touching a single physical rack.

From a DevOps perspective, this means infrastructure can be defined as code, spun up in minutes, and torn down just as quickly—enabling rapid iteration, immutable deployments, and cost-controlled experimentation.

Cloud Deployment Models

Cloud computing is not a single architecture. Choosing the right deployment model is one of the first decisions a team must make, and it affects everything from cost to compliance posture.

Public Cloud

Resources are owned and operated by a third-party provider and delivered over the public internet. Customers share the same underlying physical infrastructure, isolated by virtualisation. Examples include AWS, Microsoft Azure, and Google Cloud Platform. Public cloud offers the highest elasticity and the lowest upfront cost.

Private Cloud

Infrastructure is dedicated exclusively to one organisation, either hosted on-premises or by a third-party provider in a single-tenant environment. Private cloud gives organisations maximum control over hardware, network configuration, and data residency—important for regulated industries such as finance and healthcare.

Hybrid Cloud

A hybrid model connects private and public cloud environments, allowing workloads and data to move between them based on policy, cost, or performance requirements. A common pattern is keeping sensitive data on a private cluster while bursting variable compute demand to a public cloud. Achieving genuine hybrid cloud requires consistent networking, identity management, and tooling across both environments.

Cloud Service Models

Beyond deployment topology, cloud services are also categorised by how much of the stack the provider manages:

• Infrastructure as a Service (IaaS) — The provider manages physical hardware and virtualisation. You manage the OS, runtime, and application. Example: an EC2 instance or a bare-metal server from a cloud provider.
• Platform as a Service (PaaS) — The provider manages the underlying infrastructure and runtime environment. You manage the application code and data. Example: a managed Kubernetes service or a cloud-hosted database.
• Software as a Service (SaaS) — The provider manages everything. You consume a fully operational application via a browser or API. Example: a project management tool or a hosted CI/CD platform.

Most real-world architectures combine all three layers depending on the workload.

Key Benefits of Cloud Computing

Cost Efficiency

Capital expenditure on hardware, cooling, and facilities is replaced by operational expenditure tied directly to usage. Teams can right-size resources, use spot or preemptible instances for batch workloads, and shut down non-production environments overnight—none of which is possible with owned hardware sitting idle in a rack.

Elastic Scalability

Cloud resources scale up or down in response to demand, either manually or automatically through auto-scaling policies. This means an application can handle a sudden traffic spike without pre-provisioning for peak load around the clock.

Global Reach

Major cloud providers operate regions across multiple continents. Deploying an application closer to end users reduces latency and improves reliability. Content delivery networks (CDNs) integrated with cloud platforms extend this reach further to the edge.

Operational Productivity

Managed services handle routine operations—hardware replacement, OS patching, database failover, TLS certificate rotation—that would otherwise consume engineering time. Teams can redirect that effort toward product development and reliability engineering.

Security and Compliance

Reputable cloud providers invest heavily in physical security, network security, and compliance certifications (SOC 2, ISO 27001, PCI DSS, HIPAA, and others). Customers inherit those controls for the portion of the stack the provider manages. That said, cloud security operates on a shared responsibility model: the provider secures the infrastructure; the customer is responsible for securing their workloads, access controls, and data within that infrastructure. Misunderstanding this boundary is one of the most common causes of cloud security incidents.

Common Cloud Computing Use Cases

Cloud computing underpins a wide range of workloads that DevOps teams routinely build and operate:

• Cloud-native application development — Building microservices and containerised workloads designed from the ground up to run on cloud infrastructure using tools such as Kubernetes, serverless functions, and managed queuing services.
• CI/CD pipelines — Running build, test, and deployment automation on ephemeral cloud compute, eliminating the need for a dedicated build server fleet.
• Data storage and backup — Using object storage (e.g., S3-compatible services) for durable, geo-replicated data retention at a fraction of the cost of on-premises SAN or NAS.
• Data analytics and machine learning — Spinning up large compute clusters for periodic analytics jobs or model training, then tearing them down when the job is complete.
• Disaster recovery — Replicating critical workloads to a secondary cloud region to meet recovery time and recovery point objectives without maintaining a full standby data centre.
• Software delivery (SaaS) — Delivering applications to end users over the internet without distributing or installing software on client machines.

Things to Consider Before Adopting Cloud

Cloud computing is not universally the right answer for every workload. Engineers and architects should evaluate:

• Data sovereignty and residency — Regulatory frameworks in some jurisdictions require data to remain within specific geographic boundaries. Confirm your chosen provider offers compliant regions.
• Vendor lock-in — Proprietary managed services accelerate development but can create tight coupling to a specific provider. Evaluate the trade-off against portability requirements.
• Total cost of ownership — Cloud costs can grow unexpectedly without disciplined tagging, budget alerts, and right-sizing. Implement cost governance from day one.
• Latency-sensitive workloads — Some real-time processing or industrial control workloads require compute at the edge or on-premises, and may not tolerate the variable latency of a public cloud region.
• Skill requirements — Moving to cloud shifts operational burden from hardware management to platform engineering. Teams need investment in cloud skills and tooling.

Summary

Cloud computing provides on-demand access to compute, storage, and networking resources over the internet, replacing owned hardware with metered services. The three deployment models—public, private, and hybrid—serve different security, compliance, and cost requirements. IaaS, PaaS, and SaaS describe how much of the stack the provider manages versus the customer. For DevOps teams, the practical value of cloud lies in elastic scalability, infrastructure-as-code workflows, managed operational burden, and the ability to ship and iterate faster than legacy infrastructure allows. Adopted thoughtfully, cloud computing is a force multiplier; adopted carelessly, it introduces cost and security risks that are difficult to unwind.

This article unpacks each ingredient, explains why it matters, and shows how the three work together to deliver the speed, agility, and efficiency that modern enterprises need.

1. DevOps: Breaking Down Silos with Collaboration, Automation, and Continuous Delivery

DevOps is a cultural and technical movement that dismantles the traditional wall between software development and IT operations teams. Where those teams once worked in isolation—development writing code and throwing it over the fence to operations to deploy—DevOps integrates both disciplines into a shared, continuous workflow.

What DevOps Changes in Practice

• Faster release cycles: Continuous Integration and Continuous Delivery (CI/CD) pipelines automate testing and deployment, reducing the time from code commit to production release from weeks to hours or minutes.
• Shared ownership: Developers and operations engineers share responsibility for reliability, security, and performance—not just functionality.
• Automated feedback loops: Monitoring and alerting tools provide real-time signals that flow back into the development process, enabling rapid iteration.
• Reduced mean time to recovery (MTTR): Because deployments are smaller and more frequent, failures are easier to isolate and roll back.

Large-scale consumer platforms have demonstrated that DevOps practices enable an organization to develop, integrate, test, and upgrade applications continuously at a pace that would be impossible using traditional waterfall or siloed delivery models. The same principles apply to enterprise software, internal tooling, and customer-facing products alike.

For enterprises looking to stay responsive to customer needs, adopting DevOps means aligning the rhythm of software delivery with business objectives rather than with fixed release schedules imposed by process bureaucracy.

2. Containers: Portable, Isolated, and Independently Deployable Units

Containers represent the next evolution beyond virtual machines (VMs). Where a VM emulates an entire operating system—carrying significant overhead—a container packages only the application code and its specific dependencies into a lightweight, self-contained unit that shares the host OS kernel.

Why Containers Matter for IT Transformation

• Portability: A container image runs consistently across a developer’s laptop, a CI/CD pipeline, an on-premises server, or a public cloud—eliminating the classic “works on my machine” problem.
• Microservices alignment: Containers allow applications to be decomposed into loosely coupled services that can be developed, deployed, scaled, and updated independently.
• Resource efficiency: Containers start in seconds and consume far less memory and CPU overhead than equivalent VMs, enabling higher density on the same hardware.
• Faster iteration: Teams can push changes to individual services without redeploying the entire application stack.

Managing Container Sprawl with Kubernetes

As adoption scales, organizations inevitably encounter container sprawl—the same challenge that arose with server sprawl and VM sprawl in earlier infrastructure eras. Managing hundreds or thousands of containers manually is impractical, which is where container orchestration becomes essential.

Kubernetes has emerged as the de facto standard for container orchestration. It provides:

• Automated scheduling: Kubernetes places containers across a cluster of nodes based on available resources and defined constraints.
• Self-healing: Failed containers are automatically restarted; unhealthy nodes are drained and workloads rescheduled.
• Horizontal scaling: Workloads scale up or down automatically based on CPU usage, memory consumption, or custom metrics.
• Service discovery and load balancing: Kubernetes manages internal DNS and load balancing so services can find and communicate with each other reliably.
• Declarative configuration: Infrastructure and application state is defined in version-controlled YAML manifests, enabling GitOps workflows.

Kubernetes can run on-premises, in managed cloud offerings (such as Amazon EKS, Google GKE, or Azure AKS), or in hybrid configurations—giving enterprises flexibility in how and where they deploy containerized workloads.

3. Software-Defined Infrastructure (SDI) and Software-Defined Data Centres (SDDC)

Traditional data centres are built on proprietary hardware with fixed capacity and manual configuration processes that are too slow for the pace of modern application delivery. Software-Defined Infrastructure decouples the control plane from physical hardware, allowing compute, networking, and storage resources to be provisioned, configured, and managed programmatically through software.

Core Characteristics of SDI/SDDC

• Pooled resources: Compute, storage, and network capacity are abstracted into dynamic resource pools that can be allocated on demand rather than reserved in advance.
• Policy-driven automation: Provisioning, scaling, and decommissioning of infrastructure resources are driven by software policies, reducing manual intervention and human error.
• Commodity hardware: SDI software runs on standard x86 hardware, reducing dependence on expensive proprietary appliances and lowering capital expenditure.
• Agility: Infrastructure changes that once required physical work—racking servers, re-cabling networks—can be executed in minutes through a management API or UI.
• Consistency: Infrastructure-as-code practices apply equally to SDI, meaning data centre configurations can be version-controlled, peer-reviewed, and tested in the same way as application code.

The shift from hardware-defined to software-defined data centres also frees IT teams from routine administrative tasks, allowing them to focus engineering effort on building and improving services rather than maintaining physical infrastructure.

Why These Three Ingredients Are Interlocked

DevOps, containers, and SDI are not independent choices—they reinforce and depend on each other:

• DevOps needs containers to make CI/CD pipelines reliable and environment-agnostic. Containers guarantee that the artifact tested in the pipeline is identical to what runs in production.
• Containers need orchestration and infrastructure to run at scale. Kubernetes abstracts the underlying infrastructure, and SDI ensures that infrastructure is elastic enough to accommodate the dynamic resource demands of containerized workloads.
• SDI benefits from DevOps culture because infrastructure-as-code, automated testing of configuration changes, and continuous delivery practices apply directly to managing software-defined resources.

Together, these three pillars form a self-reinforcing platform: DevOps practices drive faster delivery, containers provide the portable deployment unit, and software-defined infrastructure provides the programmable, elastic foundation that makes the whole system scalable and resilient.

Putting It Together: A Practical Starting Point

For engineering teams beginning or advancing an IT transformation journey, a pragmatic sequence often looks like this:

1. Establish DevOps foundations first. Invest in CI/CD tooling, shared monitoring, and cross-functional team structures before migrating workloads. Culture change is slower than technology change.
2. Containerize new workloads before legacy ones. Start with greenfield services or stateless applications where containerization is straightforward. Build organizational competency before tackling stateful or complex legacy systems.
3. Adopt Kubernetes incrementally. Managed Kubernetes services on a cloud provider reduce operational burden during the learning curve. Move to self-managed or on-premises clusters once the team has sufficient operational maturity.
4. Introduce SDI alongside your container strategy. Whether through a hyper-converged infrastructure platform, a cloud provider’s virtual networking and storage services, or an open-source SDN solution, ensure your infrastructure layer can be programmatically controlled to meet the dynamic demands of container orchestration.
5. Measure and iterate. Track deployment frequency, lead time for changes, change failure rate, and MTTR (the DORA metrics). Use data to guide further investment.

Conclusion

IT transformation is not a single project with a finish line—it is an ongoing capability-building process. DevOps, containers, and Software-Defined Infrastructure are the three technical pillars that, when implemented together and supported by the right organizational culture, give enterprises the agility, speed, and efficiency required to compete in a digital-first market. The technologies are mature and widely proven. The differentiator is how effectively an organization combines and operationalizes all three.

The term “DevOps” is generally accepted as being coined by Patrick Debois when he named a development conference in Belgium “devopsdays” — in 2009 — a virtual lifetime ago in the world of software development.

Since then, DevOps has become the method du jour for thousands of organizations of all sizes and verticals in the never-ending pursuit to build better software faster. Its relationship with supporting methodologies like agile and continuous delivery are well and painstakingly documented. As DevOps has adapted and changed over the years, it has become a fundamental building block for many enterprise-level development pipelines.

But in this changing and shifting environment, the question arises: Does the term “DevOps” really have any meaning at all — or has it become just another trendy catchphrase that over the years has lost its significance?

Indeed a trend that we’ve seen in many companies is executive-level employees like CIOs adopting DevOps principles — things like continuous integration/delivery, test automation, and more — but not using the term DevOps at all.

Are you doing DevOps or agile?

Some folks would say that agile and DevOps are interchangeable terms, and that agile is more accurate to describe their pipeline strategies. So what’s the answer and how should we be looking at DevOps in 2018?

I believe that the issue at hand is the concept that DevOps as a strategy is fundamentally rigid. This is the idea that you’re either using DevOps, or you aren’t, and the way we viewed DevOps nine or ten years ago is the only way to approach things. Like so many things in the world of software, DevOps is constantly changing.

But as the saying goes, the more things change, the more they stay the same. Where I see the true power of DevOps is not in the exact strategy for how you put processes into place, or the way you test and optimize your pipeline, but the way that DevOps brings attention to the challenges that have always plagued enterprise-level software organizations.

New trends, classic problems

I have seen many trends and tools come and go throughout my career, but two items have always remained constant. First are the core issues that organizations face. These are things like disconnected teams, tools, and processes, or a lack of empathy between these teams. These issues could be data in silos, and an absence of visibility across the organization. You can go as far back as you want in the history of software development and you’ll find these problems.

What “DevOps”, as a term, is really about is identifying these issues and establishing an understanding of how they are impacting your company’s ability to deliver the best product and customer experience possible.

More importantly, DevOps is a tried and true solution for solving these issues. Enacted properly, DevOps breaks down silos, creates more cohesive teams, and provides visibility across the entire pipeline. This might mean using CI/CD, or instituting agile processes, or diving head-first into test automation, but at the end of the day, all of that fits firmly under the DevOps umbrella.

The second item that I’ve seen remain steady for organizations over the decades: Ultimate business goals. What most companies need most is speed, security, efficiency, and the ability to create meaningful value for their customers. Period.

It is true that the specifics of how these things are accomplished have certainly ebbed and flowed and the movement may have taken on a different look. Priorities might move up and down the list — for example, security in 2018 is a much larger concern for most organizations than it may have been a decade ago. But at the most basic level, these primary goals have remained the same — and these are all goals that DevOps aims to achieve.

Finding your style of DevOps

DevOps is certainly not a one-size-fits-all approach, but it never has been. The beauty of DevOps as a strategy lies in its flexibility and scalability. You are able to pick and choose what aspects of DevOps work for your organization — whether it’s something like adopting a BizDevOps approach or focusing on fully automating your testing. By making DevOps, however you interpret it, part of your pipeline, you help the organization achieve those goals of speed and delivering better quality to customers.

So to those that wonder if the term “DevOps” has run its course, I would say it’s just getting started — and it’s going to continue to be an amazing ride.

DevOps environments, with their fast and frequent release cycles, create real pressure on security practices. Developers are typically not trained in secure coding, and traditional security gate reviews conflict with the speed that DevOps promises. The result is a tension that DevSecOps attempts to resolve — but resolving it requires deliberate, structured training across your entire organization.

Establishing a DevSecOps culture is not a single-step initiative. It is a multi-layered organizational change, and its long-term success depends heavily on how well teams are trained. Managers frequently ask the same questions: Which areas need the most attention? What concrete steps actually produce lasting change?

The answer comes down to three interconnected focus areas: change management, capabilities, and roles. Each is distinct, but none works in isolation. Neglecting any one of them undermines progress in the others.

1. Change Management

Change management is frequently underestimated in technical training programs. Engineers focus on tools and skills, but rarely examine the organizational dynamics that determine whether new practices actually stick.

Mapping Transition States

Effective change management begins by understanding where your team is today and what the desired future state looks like. The transition between those states is not automatic — it requires deliberate planning. For DevSecOps, this means identifying what behaviors, processes, and mindsets must change, and in what sequence. Many engineers are unfamiliar with change management as a discipline, which means this is itself a training gap that must be addressed explicitly.

Building Internal Champions

The second attribute of change management is active contribution to the change process. Cultural inertia is one of the most common reasons security initiatives fail. Teams resist new workflows, especially when those workflows initially slow them down.

Training programs should help teams identify internal security champions — individuals who understand both the technical and cultural dimensions of the shift. These champions help align team motivation with organizational priorities and provide peer-level support that top-down mandates cannot. Without this grassroots reinforcement, even the best-designed training programs fade quickly.

2. Capabilities

Capabilities, in this context, means the concrete skills that individuals need to operate effectively in a DevSecOps environment. This breaks into two distinct concerns: acquiring the right skills, and retaining them.

Technical Skill Development

The technical side includes familiarity with Continuous Integration (CI), Continuous Deployment (CD), automated security testing, static analysis, dependency scanning, and secure coding practices. These are the competencies most commonly discussed in DevSecOps literature, and rightly so — they are foundational.

What is often missed is the depth required. Surface-level awareness of these tools is not enough. Teams need rigorous, in-depth understanding — the kind that only comes from structured practice and expert mentorship. This connects directly back to change management: leadership must actively support and resource this level of skill development, or the discipline required will not emerge on its own.

Knowledge Retention Through Just-in-Time Training

Acquiring skills is only half the problem. Retention is the harder challenge, particularly when teams are under delivery pressure and security knowledge is not applied consistently.

One effective approach is just-in-time training: delivering focused, contextual micro-modules at the moment a developer needs to apply a specific concept. Rather than long classroom sessions that front-load information and expect it to persist, just-in-time training embeds security knowledge directly into the workflow. Developers learn a concept and immediately apply it to real work, reinforcing recall through practice. This creates a continuous learning loop rather than a one-time knowledge transfer event.

3. Roles

DevSecOps fundamentally changes what it means to be a developer, a tester, or a security engineer. Traditional team structures rely on clear specialization: developers write code, testers verify it, security teams audit it. DevSecOps disrupts this model — and training must prepare people for that disruption explicitly.

Teams need to understand that their roles will expand, not disappear. The goal is not to make every developer a full security expert, but to broaden each individual’s perspective so they can reason about security implications within their existing domain. A developer should understand how the code they write creates or closes attack surfaces. A QA engineer should be able to integrate security test cases into their existing test plans.

Training programs should be designed to gradually extend existing roles rather than replace them entirely. People are more receptive to expanding their expertise than to being told their current skills are obsolete. Framing role evolution as professional growth — becoming a multi-domain specialist — is both more accurate and more motivating.

Why These Three Areas Are Inseparable

Change management, capabilities, and roles are not independent training tracks. They are tightly coupled:

• Without change management, even well-trained teams revert to old habits because the organizational environment does not reinforce new behavior.
• Without capabilities, teams understand that security matters but lack the practical skills to act on that understanding.
• Without role clarity, individuals do not know how their newly acquired skills translate into their day-to-day responsibilities.

Effective DevSecOps training requires systems thinking — treating the organization as an interconnected whole rather than a collection of individuals who each need a course. The training strategy itself must reflect the same holistic, iterative mindset that DevSecOps brings to software delivery.

Organizations that invest in all three areas build teams that do not just comply with security requirements, but understand why those requirements exist and how to uphold them under the continuous pressure of modern release cycles.

What DevOps Is Actually Solving

DevOps emerged as a cultural and technical response to the friction between software developers and infrastructure operators. Developers write code that needs to run somewhere; operators manage the servers, networks, and storage that code depends on. Without tight coordination, deployments slow down, incidents multiply, and blame accumulates.

The DevOps model addresses this by encouraging shared ownership, automated pipelines, and continuous delivery. When it works well, teams ship faster and with fewer outages. When it fails to take hold — which happens frequently — the culprit is usually organizational inertia, legacy tooling, and the sheer difficulty of replacing deeply embedded processes.

Why Infrastructure Coordination Is the Bottleneck

One of the core friction points in a traditional DevOps workflow is server provisioning and scaling. Even with infrastructure-as-code tools, deploying a new application version that requires more capacity means someone — usually on the operations side — must plan, approve, and execute those changes. That coordination loop adds latency to every release cycle.

Horizontal scaling, vertical scaling, and capacity planning all require human judgment and cross-team communication. For organizations running dozens of services, this overhead compounds quickly.

Where Serverless Changes the Equation

Serverless computing — through platforms such as AWS Lambda, Google Cloud Functions, and Azure Functions — abstracts server management entirely. Developers deploy code; the platform handles provisioning, scaling, and availability automatically. There is no server fleet to size, no capacity plan to review, and no operations ticket to file when traffic spikes.

This removes a significant portion of the coordination work that DevOps teams spend time on:

• No manual provisioning: Functions scale to zero and back up again on demand without operator involvement.
• Reduced operational surface area: Patching, OS updates, and runtime upgrades are managed by the cloud provider.
• Faster iteration cycles: Developers can deploy discrete functions independently, reducing the blast radius of any single change.
• Lower cognitive overhead: Teams that struggled with the cultural and process complexity of full DevOps adoption may find serverless easier to adopt incrementally.

Serverless Is Not a DevOps Replacement

Despite the benefits, serverless does not eliminate the need for DevOps thinking — it shifts where that thinking is applied. Observability, security policy, cost management, and deployment pipeline discipline still require deliberate engineering effort. In some ways, serverless increases the need for strong monitoring practices because the execution environment is opaque.

More practically, migrating existing applications to a serverless model is a significant undertaking. Most applications built for on-premises infrastructure or traditional IaaS platforms are not serverless-compatible without rearchitecting. Monolithic applications, stateful services, and long-running processes do not map cleanly to the function-as-a-service execution model.

A Realistic Migration Strategy

For established enterprises, the path to serverless is evolutionary rather than revolutionary — much like the transition from private data centers to public cloud. A practical approach includes three layers of activity:

1. Greenfield-first: All new applications should be evaluated for serverless suitability during design. If serverless fits the workload, build for it from the start. If not, architect the application so it can be ported later with minimal rework.
2. Selective migration: Identify discrete components of existing applications — background jobs, event processors, API endpoints — that can be extracted and redeployed as functions without rearchitecting the entire system.
3. Legacy stabilization: For applications that cannot feasibly move to serverless in the near term, continue applying DevOps practices while planning longer-horizon modernization efforts.

Startups and teams with predominantly cloud-native workloads can move faster through this progression. Organizations carrying years of legacy application debt will need longer runways and more deliberate migration planning.

The Practical Upside for DevOps Teams

As a larger share of an organization’s application portfolio moves to serverless, the nature of DevOps work shifts. Less time goes toward infrastructure coordination; more goes toward pipeline automation, observability instrumentation, security controls, and cost optimization. For developers, the payoff is significant: more time writing code, less time in infrastructure planning meetings.

Serverless does not cure every DevOps pain point, and it introduces new challenges around cold start latency, vendor lock-in, local development workflows, and distributed tracing. But for teams that have struggled to achieve the cross-functional collaboration that DevOps requires, serverless reduces the surface area where that collaboration is most difficult — infrastructure provisioning — and lets teams focus on delivering software.

Original reporting on this topic appeared at informationweek.com.

The Culture-Shock Problem With DevOps Adoption

For IT leaders trying to move their organizations from traditional, waterfall-style development to a DevOps model, the biggest threat isn’t tooling — it’s culture shock. Forcing an entire organization to change how it thinks about delivery, ownership, and feedback all at once is a recipe for disruption, resistance, and rollback.

One proven strategy for navigating this transition is to establish a DevOps Center of Excellence (CoE): a dedicated, protected team or environment where DevOps practices can start small, demonstrate value, and gradually expand across the organization. Rather than asking everyone to change at once, the CoE creates a beachhead from which the new approach can grow organically.

“Your business needs to run day-to-day into the future, so you have to find a separate area where you can create things in new ways,” says Kevin Baril. “An innovation hub, center of excellence, tiger team — whatever you want to call it. Create an environment where you can break from the traditional waterfall approach and leverage agile capabilities.”

Here are four concrete steps Baril recommends for building a successful DevOps Center of Excellence.

Step 1: Choose the Right Use Cases

The DevOps CoE will succeed or fail based on which business functions it targets first. Picking the wrong use case — one that is too complex, too politically sensitive, or too tightly coupled with legacy systems — can doom the initiative before it gains momentum.

Baril frames this as a leadership alignment problem first. “This is part of the transformational leadership concept. You have to have a leader who’s done a good job of aligning corporate business strategy with IT strategy and the architecture you’re using to enable it.”

When that alignment exists, it becomes much clearer which capabilities need to be commodity and cost-efficient versus which need to be differentiated and highly responsive to change. Target the latter category for your first DevOps initiatives — those are the areas where faster iteration and tighter feedback loops deliver the most measurable value.

Take your time here. As Baril puts it: “It takes a while to build that understanding of which use case should be first.” Rushing into the wrong domain wastes the goodwill and momentum that a successful early project would otherwise generate.

Step 2: Learn the Business Process Deeply Before You Build

Once you’ve identified your first use case, resist the urge to jump straight into toolchain setup or sprint planning. The CoE team needs to develop a thorough understanding of the business process they are improving before they can improve it effectively.

“Have a clear understanding of the outcome you’re trying to achieve and organize your team to accomplish that,” Baril says. “Your core team, introducing this new, transformative concept, needs to be fluent in the business on those concepts. Because using agility to create improvement depends a lot on the process you’re trying to improve.”

This means defining success criteria up front — whether the goal is faster release cycles, reduced manual effort, improved uptime, or lower infrastructure cost — and ensuring the entire team understands what “done” looks like. Without this clarity, velocity alone is not a useful measure of progress.

Step 3: Expect and Encourage Deep Business Involvement

One of the most important — and often underestimated — aspects of building a DevOps CoE is involving business stakeholders as active participants, not passive observers or end-users.

Baril points out that the frustration with waterfall development is shared equally between IT and the business. “Over the last 10 to 20 years, requirements were gathered in a structured way and by the time you built the system, a lot of the requirements had changed.” Business leaders often end up with technology that no longer matches what they actually need — a problem DevOps practices, with their emphasis on continuous feedback and iteration, are specifically designed to address.

Crucially, the boundary between IT and business functions has been blurring for years. “Increasingly, effective IT leaders and effective members of IT departments have a solid understanding of the business application of whatever they’re looking to accomplish,” Baril notes.

This cuts both ways. Modern low-code and platform-oriented tooling means that technically capable people in business departments can now play a direct role in building and deploying solutions. “So digital natives may be working with the rollout of new applications, and it wouldn’t be strange to have those people come from a business area instead of IT.” Your CoE should actively recruit from both sides of that fence.

Step 4: Don’t Assume You Need a Large Team to Start

Talent acquisition is often cited as the most challenging barrier to standing up a DevOps CoE. The skill set required — spanning development, operations, security, and business domain knowledge — is genuinely hard to find in one place. But that doesn’t mean you need a large team from day one.

Some organizations free up existing IT staff by automating routine tasks or consolidating systems, redirecting that capacity toward the CoE. This is a slower route but has the advantage of preserving institutional knowledge. The faster approach is targeted hiring.

“In many companies, it’s affordable to do that,” Baril says. “You have turnover, and the CIO has wide discretion about hiring. If you make the decision that this is a priority for us, then you can bring on a core group of people with the mindset to create a DevOps center of excellence.”

The key word here is mindset. The CoE team doesn’t need to be large — it needs to be composed of people who are genuinely committed to iterative improvement, cross-functional collaboration, and shared ownership of outcomes. A small, motivated team with the right culture will outperform a larger group that is simply executing instructions.

Key Takeaways

• Start with a protected space. A CoE lets DevOps practices prove their value without disrupting the rest of the organization.
• Use case selection is a strategic decision, not a technical one. Align it with business strategy before picking tools or hiring staff.
• Business fluency is non-negotiable. The CoE team must understand the processes they are modernizing, not just the technology they are deploying.
• Business stakeholders are partners, not customers. Involve them early and often; they have as much to gain from DevOps as IT does.
• Team size matters less than team mindset. A small, aligned group with the right culture can bootstrap a CoE effectively.

Building a DevOps Center of Excellence is ultimately an exercise in change management as much as it is an engineering challenge. Getting the organizational design right from the start gives the initiative the best chance of scaling across the rest of the enterprise over time.