This article is based on reporting originally published by TechTarget from DevOps industry events and analyst commentary circa late 2017. Product details reflect that period.
From Pilot Projects to Enterprise-Scale DevOps
Many enterprise IT organizations started their DevOps journey the same way: with a small, enthusiastic team stitching together open-source tools—Jenkins, Ansible, SonarQube, Artifactory—into a fragile, custom pipeline. That approach works well enough as a proof of concept, but it creates a serious visibility problem at scale. Data flows between tools with little traceability, handoffs are manual, and no single dashboard shows where a release actually stands.
As Forrester Research analyst Rob Stroud put it at the time: “DevOps starts as a series of experiments where enterprises glue together pipelines with anything they can find, but as the market matures, enterprises want one or two tools rather than eight.” Stroud described these fragmented environments as “separate islands and silos of automation”—the biggest obstacle to scaling DevOps across an enterprise.
The Problem: IT Automation Junk Drawers
The “junk drawer” metaphor captures the situation well. Over time, teams accumulate a collection of loosely connected automation tools that each solve a specific problem but were never designed to work together holistically. Common symptoms include:
- No end-to-end visibility into where a code change is in the delivery pipeline.
- Deployment automation that covers cloud and on-premises workloads but ignores mainframes—or vice versa.
- Manual approval gates and status updates communicated via email or chat, outside the pipeline entirely.
- Metrics that exist per-tool but cannot be correlated across the full software delivery lifecycle.
- Significant onboarding burden when new teams or applications need to adopt the pipeline.
A Forrester Global DevOps Benchmark survey of 237 DevOps practitioners (Q1 2017) found that while 50% had implemented DevOps and planned to expand, 64% said their businesses were dissatisfied with feature release speed, and only 34% reported that the complete lifecycle from development to production was fully automated. Those numbers illustrate the gap between DevOps adoption and DevOps effectiveness.
How Unified Pipeline Platforms Address Fragmentation
Commercial continuous delivery and release automation (CDRA) platforms emerged specifically to address this fragmentation. Rather than replacing every existing tool, they sit above the existing toolchain as an orchestration and visibility layer. The leading platforms of this category around 2017 included Electric Cloud’s ElectricFlow, XebiaLabs’ XL Release, CA Technologies’ Automic Release Automation, and IBM’s UrbanCode Deploy.
Key capabilities these platforms provide:
- Cross-environment orchestration: Coordinating releases that span mainframes, on-premises data centers, and public cloud targets from a single control plane.
- Pipeline visualization: A real-time view of where every release is in the pipeline, including approvals, test results, and deployment status.
- Tool integration: Native or plugin-based connectors to common tools such as Jenkins, JIRA, Confluence, Artifactory, Ansible, and test frameworks, so existing investments are preserved rather than discarded.
- Analytics and insights: Metrics on release velocity, failure rates, and bottlenecks that can be correlated to business outcomes like time-to-market.
- Governance and auditability: Structured approval workflows and audit trails required in regulated industries.
Product Developments at the Time: ElectricFlow 8.1 and XL Impact
In late 2017, Electric Cloud released ElectricFlow 8.1, which extended its orchestration capabilities to include IBM z/OS and Compuware mainframe applications, including IBM DB2 databases. This addressed a real gap: many enterprises run core business logic on mainframes and had no clean way to bring those deployments into a modern pipeline. ElectricFlow 8.1 also added tools for designing and monitoring microservices deployments, positioning it to handle environments at both ends of the technology spectrum.
XebiaLabs simultaneously released XL Impact, a analytics layer on top of its XL Release pipeline tool. XL Impact gave teams a bird’s-eye view of the DevOps toolchain, tracking code changes as they moved through the pipeline and evaluating whether IT was meeting business goals such as release velocity targets. It also offered remediation suggestions to improve pipeline efficiency.
Real-World Case Study: Somos Inc.
Somos Inc. is a nonprofit organization founded in 1993 that manages North America’s toll-free telephone number database—43 million records—from Herndon, Virginia. Its IT environment is a microcosm of the broader enterprise challenge: decades-old mainframe systems, an on-premises VMware-based data center, and Amazon Web Services cloud workloads all need to be part of a coherent delivery pipeline.
Before adopting ElectricFlow, Somos had assembled the familiar junk drawer: Atlassian JIRA and Confluence for project management, Artifactory for artifact storage, SonarQube for code quality analysis, VersionOne (later CollabNet) for application lifecycle management, Jenkins for continuous integration, Ansible for configuration management, and the Robot Framework for test automation. Each tool solved a problem; none of them gave a unified view of software delivery.
“We had Jenkins in use for some projects, and our goal with Electric Cloud was, ‘First, do no harm.'”
Gary McKay, Scrum Master, Somos Inc.
Rather than ripping out what was already in place, Somos used ElectricFlow’s integration layer to wrap the existing toolchain and gradually take over coordination duties. Jenkins remained in use for projects where it was already embedded; ElectricFlow coordinated those jobs as part of a broader pipeline rather than replacing them immediately. Over time, ElectricFlow took on more continuous integration and continuous deployment responsibilities as confidence in the new approach grew.
Measurable Outcomes at Somos
- Deployments that previously took multiple days were completed in hours.
- Daily build counts in test and staging environments rose from roughly six to between 20 and 30 per day.
- User acceptance testing moved to a cadence of up to twice per week.
- Production releases remained on a monthly cycle, reflecting the more conservative “mainframe-like” release process still required for the core telephone number database.
Those production releases feed into a longer-term modernization effort: translating a mainframe-based database of toll-free numbers, originally built in 1967, into a modern Java-based application accessible through REST APIs. That kind of legacy modernization is exactly the scenario where a unified pipeline platform earns its value—making it possible to move carefully, with extensive testing, without abandoning the pace improvements DevOps is supposed to deliver.
The Operations Perspective: More Than Infrastructure Automation
Edwin Yuen, analyst with Enterprise Strategy Group, noted that as organizations roll out DevOps pipeline tools, there is a natural focus on the developer experience and application delivery. That is appropriate—DevOps is fundamentally about delivering application value faster. But it also represents a significant opportunity for IT operations teams to redefine their role.
Historically, ops teams focused on infrastructure stability: provisioning, patching, monitoring, and incident response. DevOps pipeline tools give ops teams visibility into the development process itself, not just the infrastructure it runs on. Understanding where releases slow down, which environments introduce failures, and how deployment patterns affect reliability moves ops from a reactive support role into an active partner in software delivery.
“These tools offer ops a way to help developers, not just with infrastructure automation, but by understanding the development process.”
Edwin Yuen, Enterprise Strategy Group
Lessons for Teams Evaluating Pipeline Consolidation Today
While the specific product versions discussed here date from 2017, the underlying challenges remain current for many enterprises. When evaluating whether to consolidate a fragmented pipeline toolchain, consider the following:
- Audit before you buy. Map every tool in your current pipeline, what it does, what connects to it, and what gaps exist. You may find duplication or critical missing links that a new platform alone will not solve.
- Prioritize integration over replacement. The most successful rollouts, as illustrated by the Somos case, preserve existing tool investments and add orchestration on top rather than attempting a wholesale replacement.
- Define success metrics upfront. Deployment frequency, lead time for changes, change failure rate, and mean time to restore (the DORA metrics) give you an objective baseline and a way to measure whether consolidation is actually delivering results.
- Include legacy environments from the start. If mainframes, older middleware, or non-cloud workloads are part of your estate, verify mainframe and legacy support before committing to a platform—many CDRA tools are cloud-native by design and treat mainframe integration as an afterthought.
- Plan for UI and onboarding friction. As Gary McKay’s feedback on ElectricFlow 8.1 illustrated, unified pipeline platforms often evolve through multiple UI generations. Factor in training and adoption costs alongside licensing.
Summary
The shift from DIY pipeline assemblages to unified DevOps delivery platforms reflects a broader maturation of enterprise DevOps practice. Organizations that started with fragmented, tool-specific automation are discovering that visibility, consistency, and cross-environment orchestration require a layer of coordination that no single open-source tool provides on its own. The Somos Inc. experience illustrates how a pragmatic, integration-first approach—rather than a rip-and-replace strategy—can deliver measurable improvements in build frequency, deployment time, and testing cadence while still respecting the constraints of complex, legacy-heavy environments.