From CD-ROMs to Continuous Delivery

A decade ago, software was shipped on physical media, installed once, and rarely updated. Today, code is delivered over the internet and customers expect a continuous stream of improvements—whether on desktop, mobile, or in the browser. In this environment, competitive advantage belongs to organisations that can release reliably and rapidly.

The structural obstacle has always been the tension between development teams, which prioritise speed and experimentation, and operations teams, which prioritise stability and control. DevOps—a portmanteau of “development” and “operations”—is the philosophy and practice that bridges this gap, enabling iterative delivery without sacrificing reliability.

DevOps as a Cultural Shift, Not Just a Technology Change

Every practitioner interviewed for the original ZDNet piece led with culture before tooling. Franco Ucci, then Senior Director of Fusion Middleware at Oracle, described DevOps adoption as a change management exercise first and a technology project second.

“The first thing I’d suggest doing is just socialising within your organisation, showing everyone that there’s an interest in self-improvement. Let everyone know that there is an opportunity to participate and encourage people to talk about what it means for them. Try and treat it as a positive change management exercise, not a negative one.”

Franco Ucci, Senior Director, Fusion Middleware, Oracle

Ucci noted that historically, development and operations teams engaged in what he called “blame ping-pong” when things went wrong. DevOps replaces that adversarial dynamic with a shared ownership model, where both groups are accountable for the product’s health. A practical mechanism he recommended: structured sprints with learnings shared across the entire team, so that both product development and process improvement are treated as experiments whose results belong to everyone.

Ryan Eames, Chief Architect and Principal Consultant for Digital Transformation at Verizon Enterprise Solutions, echoed that sentiment and added that management commitment is non-negotiable:

“I cannot emphasise enough the importance of instilling the right culture and the need for management teams to be unfaltering in their commitment to the process. Understanding that it’s all about the team—not egos, conducting blameless post-mortems, acknowledging that things break even if it’s nobody’s fault, and understanding that it’s okay to ask for help.”

Ryan Eames, Chief Architect, Verizon Enterprise Solutions

Eames also highlighted a common source of friction: mismatched expectations about what agile delivery actually produces. A minimum viable product is not a finished product—and operations teams unfamiliar with agile may treat an MVP as a complete release. Bridging that conceptual gap early prevents downstream conflict.

Bottom-Up Adoption: Embed, Don’t Mandate

Michael O’Dea, Director of Development Operations at Cylance (an AI security company), warned against the common mistake of imposing DevOps as a top-down mandate on existing departments. In his experience, the approach that works is embedding DevOps engineers directly within development teams rather than creating a separate, siloed DevOps department that acts as a gatekeeper.

“DevOps is something that needs to be a bottom-up type of endeavour. You’re best off placing DevOps engineers into the development teams themselves and then working with a centralised DevOps team to help develop tooling and establish monitoring.”

Michael O’Dea, Director of Development Operations, Cylance

Cylance used what O’Dea called “DevOps liaisons”—engineers with either a DevOps background or full-stack experience—embedded in product teams. These liaisons kept the development cycle entirely within the team’s control from initial iteration through to software release. The central DevOps team only stepped in at the final production release to verify QA, security compliance, and release timing.

Hiring for Breadth

O’Dea was candid about how difficult it is to hire effective DevOps engineers. The role demands a genuinely eclectic background—software engineering, systems administration, tech support, networking—that looks unfocused on a traditional résumé but is exactly what the role requires.

“For some managers, some of these résumés may seem too eclectic—these people have been all over the place. But DevOps is a role that is really all over the place, and that experience really does add up to being able to be multifunctional, which every DevOps engineer has to be.”

Michael O’Dea, Cylance

Start with a Pilot

For organisations with no DevOps experience, both Eames and Brian Smith, VP of Technical Operations at Tableau, recommended selecting one well-contained service with few integration points and running a focused pilot. The goal is to get development and operations working side by side on a real deliverable—agreeing upfront on process, tooling, and success criteria—before attempting organisation-wide rollout.

“Have the development and operations teams work together to deliver the next version. Take time up-front to agree on the process, tools and desired outcome. When you decide on the methodology, provide joint training for the team.”

Brian Smith, VP of Technical Operations, Tableau

Optimising DevOps Through API-Led Connectivity

Brad Drysdale, then Asia Pacific CTO at MuleSoft, offered an important qualification: DevOps alone is not a panacea. When individual projects are built in isolation—even using DevOps principles—teams repeatedly solve the same integration problems from scratch, creating duplicated effort and slowing overall delivery.

His recommendation was to combine DevOps practices with an API-led connectivity model. Instead of each project building its own bespoke integration with legacy systems, the first project that needs a particular dataset builds a well-governed, reusable API to expose it. Every subsequent project can discover and consume that API rather than reinventing the connection.

“Every time you build something in a project—for example, getting data from the mainframe to a device—you do that using modern APIs, in such a way that once you produce that data through a modern API, you allow it to be discovered and consumed inside of the organisation. When Project Two and Project Three come along, developers realise this asset already exists and can reuse it and deliver far more quickly.”

Brad Drysdale, Asia Pacific CTO, MuleSoft

Drysdale advocated a top-down design approach: start with the customer-facing application, identify what data it needs, and build APIs to expose exactly that data with security and governance built in from the start. The benefit is that every API created has an immediate business justification—it exists because a real application needs it—which makes it far easier to get organisational buy-in from central IT.

Eames reinforced the point from a different angle: APIs enable the automation and orchestration that make DevOps velocity sustainable at scale, allowing teams to avoid rebuilding capabilities that already exist and helping software scale without proportional growth in manual effort.

Real-World Outcomes

Eames reported that Verizon reduced the time to provision managed services from six weeks to a matter of hours, reduced operational costs by more than 35 percent, and increased Tier 1 problem resolution by 83 percent through its DevOps programme. Smith noted that automation reduced manual workload at Tableau, decreasing risk and increasing both velocity and reliability.

“One of the major tenets of DevOps is automation. The more manual a process, the longer it takes and you increase the likelihood of making a mistake. Your goal should be to automate everything in the delivery pipeline from code check-in to deployment.”

Brian Smith, Tableau

Security and DevOps Are Not at Odds

A persistent misconception is that DevOps speed and security rigour are fundamentally incompatible. Practitioners from across the original interviews pushed back firmly on this view.

APIs as a Security Control Point

Drysdale made the counterintuitive argument that well-governed APIs actually improve security compared to the alternative. When multiple projects each request direct, bespoke access to the same sensitive data store, central IT must create and maintain multiple access mechanisms—each with its own security surface. A single, governed API endpoint is a smaller, more auditable, more controllable target.

“It’s actually inherently more secure if you provide one governed entry point to that data, rather than six projects coming to central IT and IT having to provide six different mechanisms by which that data is accessed. Doing it once is great, doing it six times is probably manageable, doing it 100 times becomes untenable.”

Brad Drysdale, MuleSoft

Security Tests in the CI Pipeline

Ucci described how a DevOps framework enables security controls to be applied at the code-writing stage rather than bolted on at release time. Security requirements—such as segregation of duties or role-based access constraints—can be encoded as automated tests that run with every build, ensuring compliance is continuously verified rather than periodically audited.

Infrastructure as Code as a Security Baseline

O’Dea described one of the most practical security benefits of DevOps at Cylance: because all infrastructure is defined as code—including firewall rules, routing configurations, and security groups—the team has an authoritative baseline to compare against the live environment at any point.

“For the purposes of doing an audit, you know from the infrastructure as code exactly what your environment should look like, so you can simply compare what your environment looks like now to the infrastructure code that established it and you can identify anomalies very, very quickly.”

Michael O’Dea, Cylance

Cylance enforced this baseline actively: configuration management software polled every host every 15 minutes. If any local security configuration had been changed, it was automatically reset and an alert was raised, giving the team both immediate remediation and a forensic trail to investigate the cause.

Cylance also standardised on base OS images maintained by the DevOps team, giving them certainty about the patch state, firewall configuration, and security tooling on every host—eliminating configuration drift as a hidden security risk.

Documentation Is Not Optional

O’Dea closed with a frequently overlooked point: heavy automation does not eliminate the need for documentation. When a team is small and everyone knows the system, undocumented knowledge feels manageable. But as the system grows to dozens of subsystems managed by a growing team, the assumption that “code is self-documenting” breaks down quickly.

“As you reach a large point where you have 40 or 50 subsystems that you’re managing and 10 or 12 people doing it, people do not have the time to go read the code. You really do need to have a strong effort of documentation.”

Michael O’Dea, Cylance

Key Takeaways

• Culture first. DevOps fails if it is treated as a tooling project. Blameless post-mortems, shared ownership, and management commitment are prerequisites.
• Embed, don’t mandate. Placing DevOps engineers inside development teams produces better results than creating a separate DevOps department that controls releases.
• Pilot on a bounded service. Choosing a well-contained service with few integration points lets teams learn the model before scaling it.
• Combine DevOps with API-led connectivity. Reusable, governed APIs prevent duplicated integration work across projects and accelerate time to market.
• Design top-down. Start from the customer experience, identify what data it needs, and build APIs with governance and security built in—not added later.
• Automate the full pipeline. From code check-in to deployment, every manual step is a source of delay and error.
• Security is complementary, not opposed. Infrastructure as code, CI-embedded security tests, and governed API endpoints make continuous delivery more secure, not less.
• Document as you go. Automation captures what the system does; documentation explains why decisions were made and how subsystems relate.