devopsy.kinsta.cloud

Tag: Cultural Change

DevOps Didn’t Fail — We Just Finally Gave it the Tools it Deserved

Every once in a while, our industry needs a good, sharp elbow to the ribs. Not a cheap shot. A wake-up jab. That’s exactly what Charity Majors delivered in her recent Honeycomb blog post, “You Had One Job: Why Twenty Years of DevOps Has Failed to Do It.”

If you’ve known Charity as long as I have, you know this is her superpower. She’s never been shy about an opinion. She’s dynamic, fearless, and above all else, really sharp. I admire and respect her tremendously, and I genuinely enjoy having her involved in Techstrong activities. She makes every conversation better by refusing to let it get comfortable.

Her argument, boiled down, is this: DevOps set out to do one core thing, get developers to care about their software in production, and by that measure, it failed. Not dead. Not useless. But failed at its primary mission. That’s a provocative take, and like most good provocations, there’s a lot in it I agree with and some I don’t.

Let’s start with the easy part. DevOps has been far from perfect. Anyone who says otherwise is selling something. Too often, “DevOps” became a job title, a tooling checklist, or worse, a rebranding exercise for the same old silos with better conference swag. And yes, getting developers to care about what happens after the code hits Git, all the way through deployment and into real-world behavior, remains uneven at best. Charity is right to call that out.

But here’s where I start to push back, in true Shimmy fashion. Whether DevOps “failed” depends entirely on where you’re standing and what yardstick you’re using.

One of the enduring, almost comical truths of DevOps is this: Developers often think DevOps is too Ops-centric. Ops folks think DevOps is too Dev-centric. Both sides are convinced the other one got the better end of the deal. You know what that usually means? It’s probably a decent deal. Nobody got everything they wanted, which is often the only way progress happens.

The truth, as usual, lives somewhere in the messy middle.

Ask an Ops person what DevOps success looks like, and you’ll hear something very close to what Charity is advocating: Developers who care deeply about reliability, performance, and behavior in production. Ask security teams and you’ll get a different answer. For them, success is when everyone shares responsibility for security, when “shift left” actually shifts something besides PowerPoint slides.

Ask developers, and many will tell you DevOps succeeded when it removed friction. When it let them automate the non-coding work so they could, you know, actually write code. Platform engineers will talk about internal developer platforms, golden paths, and guardrails that let teams move faster without blowing themselves up. SREs, data scientists, and release engineers all bring their own definitions to the table.

That’s not a bug in DevOps. That’s the thing.

DevOps has always been slippery. It resists clean definitions. It refuses to sit still long enough for a standards body to nail it down. At its core, DevOps was never about a single outcome. It was about breaking down silos, increasing communication, and getting more people aligned around delivering value. Success, in that sense, was always going to be plural, not singular.

Charity is absolutely right about one thing that sits at the heart of her argument: Feedback loops matter. If developers don’t see what happens to their code in the wild, they can’t get better at building resilient systems. This is where observability enters the story, and it’s no accident that Charity has been one of its most forceful champions.

But here’s an uncomfortable truth we don’t say often enough. When DevOps first emerged, observability, frankly, kind of sucked. We didn’t even use the word much back then. The tools were blunt. The data was overwhelming but not insightful. We collected logs, metrics, and traces mostly because we could, not because they reliably told us what to do next.

Charity is right again when she argues that without advanced analytics, without machine learning, without the ability to actually make sense of massive volumes of data, observability can’t fulfill its promise. You can’t make wine before its time. You are only as good as your tools.

And what a time to be alive.

AI has changed the equation, not just a little, but fundamentally. It has turned observability from a passive recording system into an active partner in understanding complex systems. Suddenly, those feedback loops Charity talks about are not just possible, they’re actionable. It’s no coincidence that OpenTelemetry and other observability projects are dominating conversations in the CNCF and across the market. The ecosystem finally caught up to the ambition.

But AI’s impact doesn’t stop there. It’s transforming how we write code, test code, secure code, and operate systems. It’s collapsing feedback cycles that used to take weeks into minutes. It’s making it easier for developers to see downstream consequences and for Ops teams to surface upstream insights. In other words, it’s doing exactly what DevOps always wanted to do, just with far better leverage.

So if DevOps wasn’t fully delivering on its promise twenty years ago, that doesn’t make it a failure. It makes it early.

As Andrew Clay Shafer famously said, “The DevOps you get is the DevOps you deserve.” I’d add this: The DevOps you get is also the DevOps your tools allow. DevOps needed AI. It needed better data. It needed observability that could actually observe, not just collect.

From that vantage point, DevOps didn’t fail. It evolved. It struggled. It disappointed at times. But it also laid the cultural and organizational groundwork that makes today’s AI-powered tooling meaningful. Without DevOps, AI would just be another shiny object bolted onto broken processes.

Charity’s essay is valuable precisely because it forces us to confront our assumptions. It reminds us that slogans aren’t outcomes and that intent doesn’t equal impact. On that, we agree completely.

Where we differ is on the verdict. Failure implies finality. DevOps was never finished. It’s still becoming. And now, finally, it has the tools it always needed to be what so many of us hoped it could be.

That doesn’t mean the job is done. It means the job just got interesting.

January 20, 2026
Why Up to 70% of SRE Initiatives Stall Before They Scale — and How to Break the Plateau
Over the last decade, site reliability engineering (SRE) has shifted from a niche Google practice to a mainstream aspiration for enterprises modernizing their technology operations. Yet despite this momentum, a substantial number of organizations — in some industry analyses, as many as 70% — struggle to scale SRE beyond the initial launch phase. Most companies start strong: They assign a few engineers the SRE title, implement some monitoring tools and hold one or two incident postmortems. But then progress slows. The cultural shift stalls. Engineering teams become skeptical. Leadership moves on to the next initiative. Eventually, SRE becomes a title without the discipline to support it.

This plateau is not due to a lack of interest — it is due to a mismatch between the intention and actual implementation of SRE.

When SRE is Adopted in Name Only

A surprising contributor to stalled initiatives is the widespread habit of rebranding existing production support or teams. These teams often continue doing what they have always done — reactive incident response, manual change approvals or tool administration — without practicing core SRE principles such as SLO-driven operations, reducing toil, error budget-based decision-making or engineering automation.

This ‘title-first, principle-later’ approach creates an illusion of maturity that delays real transformation. Organizations believe they have SRE, but reliability outcomes don’t improve because the underlying mindset hasn’t changed. Even worse, engineers quickly recognize the mismatch, creating cynicism and resistance.

When Legacy Authority Becomes a Modernization Bottleneck

Another underexamined blocker emerges from within: Long-tenured individuals in positions of influence whose skill sets have not evolved alongside today’s reliability and cloud-native practices.

As these individuals often hold senior authority or control critical processes, they unintentionally slow progress by resisting changes to ownership models, blocking automation in favor of manual controls, discouraging experimentation, avoiding new tooling or cloud-native concepts and promoting old operational habits that conflict with the SRE mindset.

No organization intentionally designs this bottleneck — but it is common, and it is one of the reasons initiatives quietly stall.

Why So Many SRE Initiatives Plateau

Below are the most common failure patterns observed across organizations that attempted but struggled to scale SRE.

Lack of Clear, Top-Down Vision

SRE is fundamentally a leadership-driven function. Without a clear, transparent and consistent executive vision — translated into simple messaging, measurable business outcomes and a multiyear roadmap — teams often default to their old ways of working. When vision is absent, fragmented interpretations emerge: Some think SRE is a tool replacement project, some treat it as a production support upgrade, some assume it is DevOps 2.0 and some see it as an operational gatekeeping role. Lack of unified direction leads to misalignment, which stalls progress before it truly begins.

Misaligned Incentives Between Leadership and Engineering

Leadership may seek higher uptime, lower incident volume and fewer customer escalations. Engineers may want less toil, rationalized on-call responsibilities and automation. Yet neither side succeeds unless both share a unified, measurable reliability mission. When incentives and KPIs differ, momentum breaks.

Cultural Resistance and Fear of Change

Cultural resistance is often underestimated. Teams fear losing autonomy, being judged for outages and exposing gaps through blameless practices, face job insecurity due to automation and are reluctant to move from reactive to proactive work. For an SRE transformation to succeed, teams must trust the process and believe the goal is empowerment — not redundancy.

Over-Focus on Tools Instead of Principles

Tooling is valuable but not foundational. Many organizations start SRE by buying a new observability platform, building dashboards and implementing incident tooling. These are important, but without SLOs, error budgets and ownership clarity, the tools remain underutilized. The initiative becomes a tooling project, not an engineering practice.

Absence of a Measurable Maturity Model

Without a maturity baseline and ongoing measurement, teams cannot prove progress or detect stalls. SRE maturity must evolve in stages — not be treated as a binary — we have SRE/we don’t. Organizations without maturity tracking often struggle to show value, which weakens long-term sponsorship.

How to Break the Plateau and Build a Sustainable SRE Practice

Establish a Clear, Top-Level Reliability Vision

Every successful SRE program begins with explicit leadership sponsorship that answers: Why are we doing this? What business value will SRE unlock? What are the expectations for the next 12–36 months? How will we measure success? This vision must be communicated consistently — not once.

Build Cross-Level Motivation With Shared KPIs

SRE only thrives when leadership and engineering teams share the same metrics and incentives. Effective KPIs include:
- SLO adoption rate per service
- Error budget burn trends
- MTTR and incident response effectiveness
- Toil reduction targets
- On-call health metrics
- Automation adoption
These KPIs must be reviewed by both leaders and engineers, creating shared accountability instead of pressuring one side.

Start With Small, Value-Driven Wins

Large-scale transformations rarely succeed without early proof. Teams should begin with small, visible improvements that create immediate value — both for leadership and engineers — examples include eliminating a top recurring incident, reducing alert noise by 40% in two weeks, implementing a first SLO for a critical service and automating 2–3 high-toil tasks. These wins build credibility, reduce skepticism and show that SRE produces tangible outcomes — not overhead.

Invest in Training and Enablement

SRE requires foundational knowledge — SLOs, incident management, automation, observability and cloud-native reliability patterns. To build this knowledge, organizations must provide hands-on workshops, brown-bag sessions, paired engineering, internal SRE office hours and platform runbooks with shared libraries. Such training reduces fear, accelerates adoption and builds engineering confidence.

Address Legacy Bottlenecks Transparently

Organizations must proactively identify and address outdated processes or authority structures that hinder modernization. This should be handled respectfully but decisively — either through upskilling, role redesign or clarified ownership models. Ignoring bottlenecks is one of the fastest ways for initiatives to stagnate.

Embrace SRE as a Change-Management Program, Not a Technical Project

SRE changes how teams collaborate, deploy, operate, measure and respond — making it a cultural transformation. Successful teams treat it as long-term change management, behavior redesign, leadership alignment and engineering empowerment. Tools help, but culture determines success.

Continuously Measure and Publicize Maturity

Use a simple maturity model (e.g., Level 0 to Level 3) that tracks SLO coverage, operational toil, engineering automation, incident response discipline and reliability outcomes. Share progress regularly. Consistent visibility reinforces sponsorship and ensures that the initiative never quietly stalls.

Conclusion

SRE succeeds when organizations understand that it is not a role, not a toolset and not a renamed operations team. It is a structured, engineering-driven approach to reliability that requires leadership alignment, cultural transformation and measurable progress.

Organizations that overcome the plateau do so by starting small, demonstrating value early, empowering teams with training, creating shared KPIs, addressing internal blockers and tracking maturity continuously. SRE is a long-term investment — and for organizations that commit to it with clarity, transparency and discipline, the payoff is stability, customer trust and operational excellence.
November 26, 2025
Five Don’ts When Scaling DevOps

The DevOps market is expected to reach $50 billion by 2022. However, despite the growing market, many organizations are struggling to make the transition from the successful implementation of a DevOps project to scaling across an organization. Gartner anticipates that 75% of DevOps initiatives will fail to fully meet expectations through 2022. If organizations are to buck this trend, then they need to consider some of the common hurdles they will encounter as they embark on the path to scaling DevOps.

Making the transition from isolated project to the broad adoption of DevOps presents significant challenges that span culture, systems and technology. Before diving into scaling, organizations should consider the following pitfalls that have derailed others in their quest to embrace DevOps.

Don’t Start Without Resolving the Conflict Between IT and the Business

The key to setting yourself up for success is to establish goals before trying to scale. A critical hurdle to overcome is to reach consensus on the pace of software updates. IT teams traditionally want to continually release software as quickly as possible while the business prefers incremental change, with the goal of minimizing customer friction that frequently results from the constant software updates. Before trying to scale, organizations need to agree on a way forward that everyone accepts and works toward. Otherwise, the silos between teams will not be broken down. This requires leadership, especially the CIO, to take an active role. Without addressing this hurdle, it will be almost impossible to scale.

Don’t Expect Immediate Cost Savings with DevOps

Many are surprised as they try to scale DevOps that it doesn’t result in cost savings. It’s important to remember the DevOps mission is to deliver more reliable software at speed by increasing automation. By doing this at scale, the benefits to the broader business are significant as organizations are able to better serve their customers and compete more effectively in the market.

Don’t Forget About Environment Management

Environment management is another hurdle that occurs when scaling, and it’s tough to solve if you have a lot of complexity. Don’t think it’s just technology, especially if you have multiple customized legacy systems. These present a significant challenge when trying to scale DevOps, so don’t underestimate the time it will take and don’t give up at the first challenge you encounter. However, once you have solved this challenge you will be able to manage these systems more efficiently and with less risk.

Don’t Get Distracted by Tools

From a technology perspective, the plethora of tools available can be overwhelming. As you scale, don’t be distracted by playing with tools. Go back to your goals and focus your efforts on the solutions that help you achieve these rather than being distracted by what is new and cool. Don’t be fooled into thinking that by investing in the latest Jenkins tool it will help accelerate the adoption of DevOps. Having the latest and greatest automation toolset doesn’t ensure that you will be able to scale DevOps.

Don’t Underestimate the Cultural Change Required

Scaling DevOps requires a significant cultural shift for every organization irrespective of industry. It’s relatively easy to carve out a project and make progress on DevOps, particularly as most companies start with an area where the teams will be more willing to collaborate. Scaling requires significant cultural change that will take time, and you will encounter many setbacks as you undertake this transformation.

Blurring the boundaries between teams is the foundation for scaling DevOps. This transformation requires changing the dynamics of how operations and development teams interact and breaking down silos. Scaling is dependent on cultural change, and that’s when organizations tend to stumble as they encounter resistance and many efforts stall.

Scaling DevOps is not a simple endeavor that can be achieved overnight and you will encounter a myriad of challenges along the way. By taking into account these five common pitfalls, scaling is much more likely to become a reality rather than an elusive goal that remains out of sight.

— Antony Edwards

October 24, 2019
ShiftLeft & DevOps: A Narrative Within a Narrative?

I procrastinated watching the season finale of “Westworld” just because I ended up reading a day later how Dolores ended the episode! I don’t know who to blame: my inquisitiveness or that guy who couldn’t hold himself. It kind of feels stale when you know the ending.

Finally, I finished weeding through the multiple narratives across the episodes, and the flashback narrative merged seamlessly with the current one. That got me thinking about using that as an analogy and maybe understand whether the concept of ShiftLeft is really actually a “narrative within a narrative” of #DevOps.

Ok, so what is ShiftLeft?

I came across the term at my fav go-to source, @devopsy.kinsta.cloud, where Alan wrote on how much to Shift Left and its diminishing returns, and another very old article on the continuous testing approach, which primarily seeks to test early and often, to catch defects, yeah, early!

Then it was thrown at me in the context of identifying repeatable activities, often manual with consistent results, performed by the Support & Operations team, and moving that work left from Level-3 all the way to L-0. Empowering the help desk, I would say!

In both the scenarios, the underlying objective was to catch defects and or reduce life support activities early in the cycle (below) which costs more and more as we move up the food chain, which in turn makes a release and subsequent maintenance cheaper.

As Alan also referred in the same article to the IBM Study, it’s almost 100 times more expensive to fix an eventual production defect which cost about six times more if caught at Implementation stage or about 15 times more if found during testing. Thus, “Early identification and prevention can improve reliable software delivery” would be the mantra.

Now, to the crux of this article, Is ShiftLeft not what we aim to achieve via DevOps?

DevOps basically creates a collaborative, non-siloed cultural change to bring both Development and Operations together early in the game.

Throw in a bunch of tools to facilitate CI/CD, pull in the security guys early, expand automated testing coverage, include change and release—who are the catalysts, as I call these functions in my earlier article here—squeeze in a few monitoring tools and dashboards and voila! You have a complete and mostly successful DevOps team to dish out the most appetizing feast of quality software repeatedly.

A table for two (Dev & Ops) has become a party of six! Yaaay!!

So, from DevOps standpoint, ain’t we doing the same as ShiftLefting (If I may coin the word) with the resulting cost effectiveness, more efficiently?

We do when we as a team make shorter and frequent sprints; gain insight, not just on how to code better or leaner but also by learning from the masters in Operations who run that software on the infrastructure they monitor and support daily. Or perform the VA scan early, or push a scenario as unit test instead of regression, and/or raise flags on potential capacity challenges.

So again, isn’t DevOps team already doing that ShiftLefting as part of its charter?

There is a limit to moving things left, but then, if your organization is still doing wireframes under a waterfall or is in the process of setting up a DevOps team, then this approach could be a stop-gap arrangement, an eventual merging of a narrative within a new narrative.

But then my argument would be, Why stop-gap and why not a full frontal? Why not embrace the DevOps model, which comes preinstalled with all the ShiftLeft possibilities?

Even if we are aware how an episode ends, procrastinating raises the risk of being left behind in the race to deliver quality, cost-effective product quickly.

Technology is redefining businesses: Transportation is an app and soon probably will be driverless; banks are rebranding as tech companies in FinServ business; a fridge can reorder milk; trash cans can be Wi-Fi-enabled! Ah, the internet of things. Is Alexa listening?

My other relevant posts are here and here.

Thank you for the time.

— Abdul Salaam Khurram

May 17, 2017
CD 101 Podcast: The What, How and Future of Continuous Delivery
Now that we’ve arrived at Episode 4 of our CD 101 Podcast, let’s address some basic concepts—like the what and how of it all and the future.

Wait … perhaps we could—or should—have touched on these key topics earlier. Or not. At least not the future part? Anyway …

While this (mostly) backwards-looking orientation may seem a bit odd, I’d argue that we’re actually navigating the conversation on precisely the correct path. Let’s rewind for a moment to look at where we’ve come from.

Episode 1: We highlighted many of the fundamentals of this thing called CD, yet we did so from more of a conceptual and best-practices standpoint. While the ideas and processes involved do resonate in the real world, the topics we cover in this episode are bit closer to the water-cooler conversations we’re hearing about CD as it grows in practical adoption.

In Episode 2: We covered the whole how do you “realize agility” piece of the conversation. This is important and a precursor to some of these other basic questions. The entire process of digital transformation begins with getting agile and you can’t truly adopt continuous delivery without doing so; therefore, this was another good place to feed today’s discussion.

In Episode 3: We looked at the prospect of re-inventing the “Modern Software Factory” with agile development and continuous delivery. OK, so, perhaps we were getting a bit ahead of the basics here, but I’d maintain that this is an important piece to consider upfront that builds on these other building blocks. As with the topics covered in Episode 2, it is critical to understand the big picture challenges and benefits before you begin to get your hands dirty.

And now for some nitty gritty.

In Episode 4, we hear from Shamim Ahmed, CTO of Continuous Delivery Solutions at CA Technologies, as he answers the nine burning questions he most often hears in speaking to enterprise practitioners as they look to employ DevOps and Continuous Delivery practices in the real world.

So, while these previous conversations were material, this is a crucial set of topics to consider as you invoke your own strategy, including:
1. What is the difference between DevOps and continuous delivery?
2. What are the key impediments/obstacles to achieving speed/quality in CD?
3. How do we overcome these obstacles?
4. How do we get started on the CD journey?
5. What are the key top-level metrics you want to track in a CD program?
6. What org changes do we need to make to implement CD?
7. What the key capabilities we need to implement?
8. How do we integrate all the different tools we have in our environment?
9. How will the future of continuous delivery evolve?
OK, that last part is a bit more postulation on our part—though we like to think on the practical side, based on the answers to all these other important real-world adoption dynamics.

Tune in and hopefully learn a good deal about where your approach stacks up, and needs to evolve.

As always, you can find said Episode 4 of the Continuous Delivery 101 Podcast by:
- Listening to it on your computer on YouTube
- Downloading it from iTunes store
- Downloading it via the Podcast App by searching for “Continuous Delivery 101 podcast”
Enjoy!

— Scott Edwards
April 21, 2017
Why Financial Companies Love Continuous Delivery
The other day I was on the American Express website paying bills and browsing around the benefits and services afforded me when I ran across a “who we are” section. It read:

“We’re a global services company that provides customers with access to products, insights and experiences that enrich lives and build business success.”

Surprisingly, the term “financial” was missing from the description. This led me to wonder if other financial institutions are evolving how they think about themselves. Here are some other examples:
- Bank of America: “Here to help connect you to what matters most.”
- ING: “Empowering people to stay a step ahead in life and in business.”
- MasterCard: “As a technology company, we connect individuals, businesses and organizations around the world, creating greater opportunities for all.”
Financial Companies Love Their Customers

My unscientific assessment of various financial services companies suggests that they are centered on delighting their customers. They are transforming who they are by altering their customer engagement models and essentially becoming better software companies. MasterCard has even reclassified itself as a “technology” company. These companies are transcending the role of transaction engine to offer seamless, intuitive digital experiences for their customers.

And the proof is in the performance. According to Forrester’s Customer Experience (CX) Index, financial services firms, including retail banks, credit card companies, investment firms and auto and home insurers, are some of the top brands worldwide when it comes to CX.

You might think that large financial institutions would be digital laggards because of legacy infrastructure, regulatory compliance pressures and overall risk-avoidance. But you’d be wrong.

In another study, 81 percent of financial services firms said they are embracing digital to redefine their businesses, and 87 percent are on the DevOps bandwagon. Sixty-one percent even said they are disrupting their industry with advanced digital initiatives.

To stay competitive and improve their customer experience aptitude, financial services firms are undergoing significant digital transformation.

Getting the Pulse of Fintech Continuous Delivery Adoption

But how progressive are these firms in terms of their application delivery practices? Working with CA, Gatepoint Research recently surveyed more than 100 IT executives from financial services companies to take the pulse of where they are in continuous delivery adoption. Results can be found in this report and infographic.

First off, to see if these companies might be considered unicorns or stragglers, they were asked the total volume of monthly deployments in all environments. Forty percent fell at the low end with fewer than 50 deployments per month. Now, lower deployment numbers could mean that these are less agile organizations or that they have fewer applications in general. Somewhat correlative to lower deployment numbers, the survey found that 48 percent currently are not using an application release automation (ARA) solution. Without automation, it’s tough to scale release processes—particularly to keep up with agile development.

Moving up the spectrum, 41 percent are moderately prolific at 50-500 deployments per month, and then 15 percent are what I would consider rock stars with more than 500 (7 percent of those over 1,000). Those doing hundreds of deployments a month often have agile development teams and more modular applications. They likely have continuous delivery practices in place that push more frequent, iterative deployments left, helping higher-quality applications to move through the pipeline to production.

The primary application delivery goals for financial services firms for the next 12 months are to get better control of release processes, tools and environments; to reduce risk and failures; and to release applications more frequently. All of these needs typically stem from companies undergoing digital transformation—it feels more chaotic and disconnected, manual processes are breaking under the weight and there’s intense pressure to move faster.

Compliance was not a top goal, and the majority (83 percent) claim that their current release process is adequate to meet regulatory requirements. However, they did acknowledge that they could improve in terms of knowledge safekeeping and auditability of the release process.

The data certainly shows that financial services companies are adopting continuous delivery practices in some form and exploring solutions, including many open-source tools, to help them get the job done. They currently are focusing continuous delivery practices on tracking and reporting releases, planning and scheduling releases and automating test deployments. These practices ultimately help financial services companies to release high-quality applications anywhere at any time.

How Continuous Delivery Helps Fintech Win

Continuous delivery sits at the heart of many digital initiatives because of what it enables these companies to achieve for their customers:
- Delivering features and updates that customers need when they need them
- Delivering applications that meet performance and quality expectations of customers
- Delivering secure, compliant applications (for external and internal customers)
Continuous delivery enables continuous devotion to the customer experience.

Continuous Release: Fast Customer Response

With continuous delivery, you establish an application release workflow that automatically connects a developer’s update to parallel testing to staging and ultimately to production release. Because of the underlying end-to-end automation technology, these steps can happen quickly, seamlessly and with little to no manual intervention. Some might call it “push button release” or “zero-touch release.”

It’s a controlled, tracked, governed, collaborative process. Application stakeholders stay aligned as application changes traverse the pipeline. Your customers can have access to fixes, updates and new innovations in days instead of weeks or months.

Continuous Testing: Building in Quality

In contrast to the significant time penalties and shortfalls that can happen with manual testing, in the continuous delivery pipeline, testing is shifting left and happening in parallel. Hand-offs and feedback loops are automated and efficient.

Testing can happen earlier and without delay with the help of test environment simulation. Testing is on target through automatic test case creation, even from requirements. Testing is real-world with on-demand test data generation. And testing is rigorous with developers able to performance test apps at their end. The continuous testing that occurs as part of the process helps to build in quality and ensure top performance before reaching the customer.

Continuous Compliance: Audit-Ready Processes

Ensuring applications are compliant and secure is critical for your customers. It’s making sure customer information is safe and that application changes are tracked sufficiently for SOX or other reporting. It’s also about helping out those internal “customers” like auditors to prove compliancy and easily build reports.

An automated continuous delivery pipeline can track releases, apply role-based governance, orchestrate proper data masking, deploy security policy updates and provide an audit trail for application releases—who did what, when and why. All this data can be collected and reported easily, which saves time and effort for auditors. You essentially stay compliant and secure all the time.

Customer Satisfaction Through Automation

Financial services companies are laser focused on using technology to delight and retain customers. And continuous delivery is the application delivery practice that’s underpinning these efforts. The companies that are exceptional at this, with thousands of deployments per month, are using automation tools such as Application Release Automation (ARA). These tools are the backbone of continuous delivery, providing the automated orchestration, governance, tracking and reporting for your pipeline—development through production.

That’s why I’m not surprised that leading financial services companies make up a large portion of CA’s release automation customers, including Euroclear, GM Financial, ING, Jewelers Mutual and Western Union. Our customers put high value on delivering excellent customer experiences and are implementing modern software delivery methodologies, practices and associated tools to support their efforts. GM Financial recently said it is “the software company that does auto finance.”

If you are serious about customer satisfaction and staying ahead of nimble competitive threats in the market, you must get serious about end-to-end automation. It’s time to truly embrace the practice of continuous delivery to be able to consistently release applications that are progressive, always compliant and completely customer-satisfying.

— Patricia Johnson
March 2, 2017
Be Here Now – Agile and DevOps in the Current State of Synergy

If there’s one thing that our culture does not lack, it’s a litany of pithy catch-quotes meant to remind us to focus on the task at hand; yet, this often runs counter to our tendency to fixate on matters of the past and future.

While we are so often encouraged to “live in the moment” and “seize the day”, this is hardly an easy task, especially as related to any sort of emerging phenomenon that compels us to improve on historical missteps, and predict how things should change for the better.

Register today for the 3^rd Annual DevOps Virtual Summit.

With the methodologies of agile and DevOps the tendency is, of course, to do the same, harping on the inefficiencies of previous software delivery models and painting an elaborate portrait of how related workflows are being transformed overnight.

The simple truth is that it’s easy to get excited about concepts that hold such tremendous potential in recasting an increasingly critical vital set of processes, and lose track of where things actually stand.

To note, while a recent research project published by Coleman Parkes found that over 80 percent of organizations have adopted some manner of agile and DevOps practices, and see them as critical in transforming their internal software factories, only a third have adopted the methods on a broad scale.

Point being, we’re still pretty early.

That said, we in the business of helping organizations adopt related culture and tooling have gone to great lengths to encourage everyone that this change should be pursued with dogged intensity. We have sliced and diced the data to illustrate how those organizations at the forefront of so-called digital transformation, enabled by agile and DevOps, are realizing the results in the form of increased velocity.

The same research finds that “advanced” adopters of the two concepts are, in fact, seeing significant improvement in time-to-market, customer satisfaction and new business growth.

But research is just that, and often not completely aligned with real-world scenarios. Someone who takes the time to answer a survey about such matters, one could reasonably expect, is the type of person far more likely to be involved in agile and DevOps activities.

My personal conversations with everyday practitioners [aka other parents on the sidelines at my kids’ sports and social events, many of whom work in IT] tell me that we’re much more oriented to the “pockets of innovation” phase at present, than any sense of pervasive adoption.

So this begs the two-part question – where do we really stand, and what do I really need to care about?

The only reliable source of record in my mind is the perspective of people already doing the work, beyond what I can discern amid basketball games and middle school theater. Real-world practitioners are the voices of reason that allow us to “be here now” and address the specifics of practical agile and DevOps implementation.

Over the past several years, I’ve found one of the best sources of such input to be the customer panels available at industry conferences and on webcasts. When it’s time for me to sit down and crank out some related content, I often go back to these recordings to remind myself where the rubber actually hits the road.

On Tuesday Mar. 7, we’ll host just such an event, the 3^rd Annual DevOps Virtual Summit, where agile and DevOps leaders from organizations including CNN, GM Financial and United Airlines will share their thoughts on how this ongoing transformation is playing out, and where the remaining challenges lie.

Along with those experts, we’ll also hear from Dr. Nicole Forsgren, one of the leading researchers in the space who is in seemingly constant contact with people leading the charge and working in the trenches putting agile and DevOps into practice.

As a marketer, and previously as a journalist, everything that I know comes from direct interaction with those colleagues willing to share their hands-on experience garnered via doing this work every day.

Register for the event and join us to find out where agile and DevOps actually stand today.

— Matt Hines

February 22, 2017
CD 101 Podcast Episode 2: The Agile Enterprise
And we’re back with another episode of the “Continuous Delivery 101 Podcast.”

In Episode 1, we covered the three waves of IT disruption—and how these disruptions, combined with the move toward digital transformation, are drastically changing every industry.

This, of course, underlined how accelerating speed-to-market is clearly more important than ever before.

In this second episode, we talk about Agile methodologies with expert Dan Rice, who addresses how these practices can enable business strategies to be implemented at greater speed.

Listen closely and you’ll learn more about what Agile actually means across various teams, roles, product owners and scrum masters, along with related points on DevOps and CD tooling.

All of these topics are great food for thought as you think about how you can move to build software faster and with increased quality. Yet, if enterprises only focus on these issues, they aren’t tackling or talking about the real problem in their organization that Agile can solve.

It’s time to take the conversation beyond the team level and talk about how work flows to every involved team, enterprise-wide—specifically, about how initiatives can expand across multiple teams, how to manage shared resources and how to pull in other dependent teams.

For Agile to work, it has to expand universally and be ingrained further at program level, to understand precisely how work is coordinated and flows across every domain.

You can listen to Episode 2 of the “Continuous Delivery 101 Podcast” via:
- YouTube
- iTunes store
- Or by searching for it in the iTunes Podcast App under “Continuous Delivery 101 Podcast”
Thanks for tuning in to the “Continuous Delivery 101 Podcast.” We hope you’ll continue the conversation by posting your comments below or in the comments section on YouTube or iTunes.

Meanwhile, keep tuning in: We’ll be back soon with another episode!

— Scott Edwards
February 21, 2017
Culture Comes First in Bringing DevOps to the Mainframe
One of the most difficult challenges in engineering, oddly enough, isn’t technical: the challenge is culture transition management. In my 20-plus years of managing engineering teams worldwide, I’ve led teams through countless organizational adjustments and process improvements toward high-performance and quality, beginning with QA segregation to CMMI to ITIL, AGILE and SAFe.

Today, mainframe organizations have emerged as the focal point for enabling DevOps capabilities and practices. Why the mainframe? Well for starters, business critical applications rely on mainframe data and business components. These applications are mission-essential and that sustained innovation requires solution sets that deliver continuous testing, continuous delivery and continuous feedback on the mainframe platform.

But culture comes first.

Understanding Your Key Players

In conversations with our customers we’ve observed an interesting dynamic emerging within mainframe application development teams. Within these teams are experienced developers who were instrumental in creating the applications that helped make their companies so successful. Over time, many have become set in their ways, adopting a motto of, “If it’s not broken, why fix it?” Such developers are not interested in trying out new things, including programming languages and tools used by the modern-day programmer.

New to the scene are the millennials who have also taken up the mantle of enterprise software engineer. They are a bit more open-minded and bring a different programming language profile, including Java, .NET and C. These developers might be learning how to code APIs with the support of management, and have likely dabbled the basics of how to code iOS apps. Millennial developers are typically much more active online and, as a result, prefer to leverage Twitter and other social channels to stay informed with the development community.

United We Stand

Who, then, should be involved in the journey to realizing DevOps? The answer, of course, is both. Because we’ve heard it reinforced among our users we talk with in the CA Communities every day, at user groups and at prominent mainframe community events such as CA World and SHARE.

You know it, because you probably see it in your organization as well. There are experienced developers: people who have deep knowledge of the applications in place, business intelligence, database tables, cross-application dependencies, batch execution windows and the general experience of how things work on the z/OS platform.

Most importantly, they also know how to avoid breaking what’s working.

And there are the millennial developers: people who are curious to learn about new programming languages, platforms, people who, with the advent of Agile development, and open source have played with things, tested them and are using it to enhance their skill sets.

These people prefer to use modern user interfaces and tools to increase their productivity. Sometimes they might be tentative about making mainframe changes, not willing to risk their careers by breaking poorly documented code.

Culture – Have it Both Ways

While the interests of millennial and experienced developers may at times seem conflicting, both have pivotal roles to play in application development and will benefit greatly from the common sense practices of DevOps and agility that are coming to the mainframe platform. To survive and thrive, teams must unify to facilitate the change process. Most importantly:
- Code must be accessed and modernized at the speed of business. Enterprise developers, testers and architects cannot be afraid to go talk to the “black box” that is the mainframe team.
- Project managers can’t worry that a six-week turnaround for small changes will kill their hopes of meeting their delivery windows.
- The delivery team—QA, release management and operations—can’t afford to sit around waiting for simple deployment steps to happen: when we can automate and integrate to increase deployment frequency.
The promise of DevOps and agility on the mainframe is to fix this, and that’s why our engineering teams are actively building out solution sets that extend DevOps practices to the mainframe, including continuous testing, continuous delivery and continuous feedback.

Curious about what it will take to bring DevOps to the mainframe? Catch some tips and best practices from Forrester Research principal analyst Rob Stroud, or hear from the leaders driving change in their organization in our CA World 2016 Mainframe DevOps panel.

— Aline Gerew
January 31, 2017
Welcome to the Continuous Delivery 101 Podcast

No matter what industry you’re in or how old your business is, your software often determines your success in today’s application economy.

Applications are the face of your business—both the way it performs and the speed with which you can incorporate new ideas and innovations, driven by the efficiency of your software development life cycle—determines whether your company can survive in this competitive market.

Software doesn’t just support the business today, it drives the business—and your organization’s livelihood in this application economy comes down to your ability to quickly deliver world-class capabilities. As a result, more organizations than ever are turning to the practice of continuous delivery (CD) to improve their ability to plan, build, test and release applications to market.

With this increased focus on continuous delivery methodologies and practices, we’ve established a new podcast that highlights the importance of utilizing CD, along with adoption techniques and other best practices.

Dubbed “Continuous Delivery 101,” the series features some of today’s leading experts in the field discussing where they’ve seen CD success, across some of the world’s top organizations and across multiple industries.

The first episode in this series covers CD fundamentals and the software evolution that has made continuous delivery so critically important.

Beginning in the ‘60s, this first wave of this software evolution saw mainframe systems brought in to automate business tasks. A second wave saw the emergence of ERP/CRM-based processes, so we could improve how we run contact management and transaction processes. Today we’re in the third wave, which started with the widespread adoption of mobile and web technologies, with all of these paradigms intersecting in perfect convergence.

Businesses that have mainframe and distributed systems, that have CRM and ERP system, that have web fronts and mobile apps, are utilizing these continuous delivery tools to innovate faster than ever before. These organizations are being forced to reinvent how they communicate with customers and how they deliver goods and services to stay relevant in the market. This third wave, where business is now driven by IT, is the biggest disruption that we’ve seen.

To hear a lot more on this topic, check out the first episode of the Continuous Delivery 101 podcast via YouTube or the iTunes store, where you can find it on the Podcast App by searching for “Continuous Delivery 101 podcast.”

Software delivery, fueled by CD, is evolving at a furious pace. Stay tuned for more expertise and best practices.

— Scott Edwards

January 18, 2017