Skip to main content

3 Essentials for Agile Operations

Pete Waterhouse

For decades IT operations has been viewed as something of a back-office technology function; the IT engine room. That’s not wrong since the applications under control have generally been large monolithic systems of record designed to automate internal business processes. These systems have been inherently complex and tightly-coupled, so changing them has been difficult, time consuming and costly. As such, our operational mindset has remained firmly focused on maintaining reliability and avoiding risk at all costs – even if that means holding back releases and ticking off our colleagues in development.

Not anymore.

Now, business success is not only dependent on assuring the reliability of internal business processes, but also by leveraging mobile computing and the cloud for more ‘experience-centric’ customer engagement. Now, software has the potential to forge new business models and disrupt markets, meaning change intolerance and aversion makes way to experimentation and innovation. The net-net of course is faster more iterative application development, newer highly scalable architectures, and a far more diverse set of applications – some of which will be standalone, while others will be integrated within our existing business process fabric.

So against this backdrop, what are main reasons the IT operations discipline must adapt to support the application-driven imperatives of the business and what characterizes a successful agile operations transformation? It boils down to delivering on three essential requirements – speed, quality and scale.

In Pursuit of Quality

Since the applications now being developed are far more customer-centric, service quality will be assessed at many more points of engagement. Consider a web/mobile airline booking system for example. This might be comprised of ten or more discrete services (e.g. booking flight, checking baggage, choosing seats, ordering meal, scanning boarding pass, car rental etc.). Every one of which constitutes a point of interaction where quality in the form of an optimum experience has a direct correlation to customer retention and business gain.

The traditional approach would be to wait for each of these applications to reach production and then initiate monitoring. Yet this is problematic since any problems now have a significantly greater impact on the business and in all likelihood will require developers to fix them. The result – greater conflict, more technical debt and lost business.

A far more agile approach is to incorporate monitoring earlier in the software development lifecycle. This involves collaborating with development to replicate the deep analytics and traceability insights normally gained in production and applying them in a development and testing context. Through this, the immediate gain is stopping defects leaking into production, but there are more lasting benefits too.

Firstly, development has much earlier visibility into quality requirements before the system goes live and can enact any necessary refactoring strategies.

Secondly, key insights gained through transaction monitoring can be shared with the operations team, so they can immediately establish metrics and performance KPI’s against which the production environment can be measured.

Finally, and in true DevOps fashion, this approach creates tighter feedback loops so that everyone knows who the app is serving, what experience is expected, and where changes impact performance – continuously.

The Need for Speed

With business now being driven by a complex mix of highly experiential software services, it’s essential that any problems are detected and resolved at a pace that matches the speed of delivery. This however is difficult because monitoring systems generally lack the ability to provide uninterrupted transaction level visibility.

Some toolsets for example provide rich mobile analytics (usage, behavior, crashes) which is all great. But what happens when the success of a new national mobile app based sales promotion depends on the successful recording against a backend database and requires no network latency at peak times. Without end-to-end visibility that can follow transactions across all apps and infrastructure and that provides insight into the underlying causes for failure, no realistic service levels can be established with the business.

Scaling the Summit

Embracing newer horizontally scalable architectures is the way leading innovators are future proofing their businesses. Combined with microservice style development these architectures facilitate more rapid deployment of independent business services. Services that truly harness the cloud by dynamically scaling resources.

Taking advantage of this means monitoring must become equally future proof by scaling in tandem. However attractive from an architectural perspective, these applications will introduce greater complexity, more interdependencies, newer tech like NoSQL and document-based data stores (e.g. Cassandra and MongoDB) and initiate complex system behaviors due to their highly distributed nature.

The old approach of teams maintaining their own sets of specialized diagnostic tools over infrastructure that falls within their own silo is no longer sustainable. Now, more unified monitoring approaches must provide cross-functional teams with fast visual comprehension to reveal what matters versus what can and should be ignored. Additionally, change analysis to more rapidly isolate problems increases in importance, since the resources underpinning cloud-native applications will unexpectedly shift based on demand, cost and lifecycle.

New applications and architectures supporting more transformative digital business demand IT operations must become as agile as development.

Hot Topics

The Latest

Two years ago, almost every customer conversation about AI started with the same questions: Which model should we use? What can it do? Is it ready for the enterprise? Today, those discussions have moved on. CIOs are far more interested in how to govern AI, integrate it with existing systems, prepare their workforce and make it part of everyday operations. The challenge is no longer to prove that AI can deliver value. It's instead about how to embed AI into the business in a way that's secure, scalable and delivers measurable outcomes ...

 

Two things happened to production incidents between 2023 and now, and they did not happen at the same speed. The first is that a class of dependency that barely existed three years ago now accounts for one incident in ten. Incidents disclosed by AI model and AI application providers rose from 1.7% of all disclosed unplanned incidents in 2023 to 10.7% in 2026 year to date, roughly a sixfold rise; that counts only incidents at AI companies themselves, so the true share is higher. The second is that the time to close an incident has not come down ...

When an AI assistant gives an incomplete or incorrect answer, teams often blame the model. They adjust prompts, switch models, increase context windows or test a new retrieval strategy. However the model may not be a problem. In many enterprise AI workflows, the problem begins inside the document-ingestion pipeline ...

If you talk to any security or observability teams right now, they're all fighting the same fire: their tooling was built to ingest X, but their sources are pumping Y and soon to be doing Z. The knee-jerk reaction is always the same: we need more platform. However, this reaction is wrong. Let me explain why, because the solution to this problem is foundational, not financial. Instead of hurling yet more money at the problem, make sure you've done what's needed upstream ...

Rapid AI adoption and the unique ways AI workloads operate is redefining the scope and structure of what these teams must deliver. This shift is forcing organizations to rethink how they manage scale, automation, and control, according to The State of SRE and Platform Engineering 2026, a new report from Dynatrace ...

AI is usually talked about as a software tool, but it also depends heavily on the network behind it. Whether a company is using AI for chatbots, automation, monitoring, analytics, or employee support, all of that information has to move across the network in a reliable and secure way. That means AI is not just an application decision. It is also an infrastructure decision. Before organizations rush into AI, they should ask a simple question: Is our network ready to support it? ...

Enterprise AI often lacks governed access to where business processes actually execute. Without that access, AI agents may be able to reason, but they cannot operate reliably across enterprise workflows. For AI agents to effectively carry out workflows, they will require integration-layer context and controls. Organizations can implement these prerequisites by providing AI with managed access to the middleware layer ...

Enterprise networks rarely behave the same way for very long. A routing adjustment in one region may unexpectedly alter application performance in another. A cloud migration may introduce hidden dependencies that go unnoticed until an outage occurs. All the while, the network is managed by several different teams, each of whom use different tool sets — and as a result, have different views of the network ... There’s usually an engineer who remembers why traffic fails over a certain way between sites, or which transparent firewall was added where. The problem is that human memory cannot scale alongside enterprise-scale networks ...

Ask an infrastructure team how confident they are in their ability to govern AI, and most will tell you they've got it handled. A recent survey of 406 IT decision-makers and platform engineering leaders found 86% expressing exactly that confidence. Ask the same group whether they have a formal written AI governance policy, and the number drops to 30%, according to Spacelift's Infrastructure Automation Report ...

In MEAN TIME TO INSIGHT Episode 27, Shamus McGillicuddy, EMA VP of Research, Network Infrastructure and Operations, and Parker Hathcock, EMA Research Director covering IT Service/Operations (ServiceOps), discuss observability unification in modern IT operations ... 

3 Essentials for Agile Operations

Pete Waterhouse

For decades IT operations has been viewed as something of a back-office technology function; the IT engine room. That’s not wrong since the applications under control have generally been large monolithic systems of record designed to automate internal business processes. These systems have been inherently complex and tightly-coupled, so changing them has been difficult, time consuming and costly. As such, our operational mindset has remained firmly focused on maintaining reliability and avoiding risk at all costs – even if that means holding back releases and ticking off our colleagues in development.

Not anymore.

Now, business success is not only dependent on assuring the reliability of internal business processes, but also by leveraging mobile computing and the cloud for more ‘experience-centric’ customer engagement. Now, software has the potential to forge new business models and disrupt markets, meaning change intolerance and aversion makes way to experimentation and innovation. The net-net of course is faster more iterative application development, newer highly scalable architectures, and a far more diverse set of applications – some of which will be standalone, while others will be integrated within our existing business process fabric.

So against this backdrop, what are main reasons the IT operations discipline must adapt to support the application-driven imperatives of the business and what characterizes a successful agile operations transformation? It boils down to delivering on three essential requirements – speed, quality and scale.

In Pursuit of Quality

Since the applications now being developed are far more customer-centric, service quality will be assessed at many more points of engagement. Consider a web/mobile airline booking system for example. This might be comprised of ten or more discrete services (e.g. booking flight, checking baggage, choosing seats, ordering meal, scanning boarding pass, car rental etc.). Every one of which constitutes a point of interaction where quality in the form of an optimum experience has a direct correlation to customer retention and business gain.

The traditional approach would be to wait for each of these applications to reach production and then initiate monitoring. Yet this is problematic since any problems now have a significantly greater impact on the business and in all likelihood will require developers to fix them. The result – greater conflict, more technical debt and lost business.

A far more agile approach is to incorporate monitoring earlier in the software development lifecycle. This involves collaborating with development to replicate the deep analytics and traceability insights normally gained in production and applying them in a development and testing context. Through this, the immediate gain is stopping defects leaking into production, but there are more lasting benefits too.

Firstly, development has much earlier visibility into quality requirements before the system goes live and can enact any necessary refactoring strategies.

Secondly, key insights gained through transaction monitoring can be shared with the operations team, so they can immediately establish metrics and performance KPI’s against which the production environment can be measured.

Finally, and in true DevOps fashion, this approach creates tighter feedback loops so that everyone knows who the app is serving, what experience is expected, and where changes impact performance – continuously.

The Need for Speed

With business now being driven by a complex mix of highly experiential software services, it’s essential that any problems are detected and resolved at a pace that matches the speed of delivery. This however is difficult because monitoring systems generally lack the ability to provide uninterrupted transaction level visibility.

Some toolsets for example provide rich mobile analytics (usage, behavior, crashes) which is all great. But what happens when the success of a new national mobile app based sales promotion depends on the successful recording against a backend database and requires no network latency at peak times. Without end-to-end visibility that can follow transactions across all apps and infrastructure and that provides insight into the underlying causes for failure, no realistic service levels can be established with the business.

Scaling the Summit

Embracing newer horizontally scalable architectures is the way leading innovators are future proofing their businesses. Combined with microservice style development these architectures facilitate more rapid deployment of independent business services. Services that truly harness the cloud by dynamically scaling resources.

Taking advantage of this means monitoring must become equally future proof by scaling in tandem. However attractive from an architectural perspective, these applications will introduce greater complexity, more interdependencies, newer tech like NoSQL and document-based data stores (e.g. Cassandra and MongoDB) and initiate complex system behaviors due to their highly distributed nature.

The old approach of teams maintaining their own sets of specialized diagnostic tools over infrastructure that falls within their own silo is no longer sustainable. Now, more unified monitoring approaches must provide cross-functional teams with fast visual comprehension to reveal what matters versus what can and should be ignored. Additionally, change analysis to more rapidly isolate problems increases in importance, since the resources underpinning cloud-native applications will unexpectedly shift based on demand, cost and lifecycle.

New applications and architectures supporting more transformative digital business demand IT operations must become as agile as development.

Hot Topics

The Latest

Two years ago, almost every customer conversation about AI started with the same questions: Which model should we use? What can it do? Is it ready for the enterprise? Today, those discussions have moved on. CIOs are far more interested in how to govern AI, integrate it with existing systems, prepare their workforce and make it part of everyday operations. The challenge is no longer to prove that AI can deliver value. It's instead about how to embed AI into the business in a way that's secure, scalable and delivers measurable outcomes ...

 

Two things happened to production incidents between 2023 and now, and they did not happen at the same speed. The first is that a class of dependency that barely existed three years ago now accounts for one incident in ten. Incidents disclosed by AI model and AI application providers rose from 1.7% of all disclosed unplanned incidents in 2023 to 10.7% in 2026 year to date, roughly a sixfold rise; that counts only incidents at AI companies themselves, so the true share is higher. The second is that the time to close an incident has not come down ...

When an AI assistant gives an incomplete or incorrect answer, teams often blame the model. They adjust prompts, switch models, increase context windows or test a new retrieval strategy. However the model may not be a problem. In many enterprise AI workflows, the problem begins inside the document-ingestion pipeline ...

If you talk to any security or observability teams right now, they're all fighting the same fire: their tooling was built to ingest X, but their sources are pumping Y and soon to be doing Z. The knee-jerk reaction is always the same: we need more platform. However, this reaction is wrong. Let me explain why, because the solution to this problem is foundational, not financial. Instead of hurling yet more money at the problem, make sure you've done what's needed upstream ...

Rapid AI adoption and the unique ways AI workloads operate is redefining the scope and structure of what these teams must deliver. This shift is forcing organizations to rethink how they manage scale, automation, and control, according to The State of SRE and Platform Engineering 2026, a new report from Dynatrace ...

AI is usually talked about as a software tool, but it also depends heavily on the network behind it. Whether a company is using AI for chatbots, automation, monitoring, analytics, or employee support, all of that information has to move across the network in a reliable and secure way. That means AI is not just an application decision. It is also an infrastructure decision. Before organizations rush into AI, they should ask a simple question: Is our network ready to support it? ...

Enterprise AI often lacks governed access to where business processes actually execute. Without that access, AI agents may be able to reason, but they cannot operate reliably across enterprise workflows. For AI agents to effectively carry out workflows, they will require integration-layer context and controls. Organizations can implement these prerequisites by providing AI with managed access to the middleware layer ...

Enterprise networks rarely behave the same way for very long. A routing adjustment in one region may unexpectedly alter application performance in another. A cloud migration may introduce hidden dependencies that go unnoticed until an outage occurs. All the while, the network is managed by several different teams, each of whom use different tool sets — and as a result, have different views of the network ... There’s usually an engineer who remembers why traffic fails over a certain way between sites, or which transparent firewall was added where. The problem is that human memory cannot scale alongside enterprise-scale networks ...

Ask an infrastructure team how confident they are in their ability to govern AI, and most will tell you they've got it handled. A recent survey of 406 IT decision-makers and platform engineering leaders found 86% expressing exactly that confidence. Ask the same group whether they have a formal written AI governance policy, and the number drops to 30%, according to Spacelift's Infrastructure Automation Report ...

In MEAN TIME TO INSIGHT Episode 27, Shamus McGillicuddy, EMA VP of Research, Network Infrastructure and Operations, and Parker Hathcock, EMA Research Director covering IT Service/Operations (ServiceOps), discuss observability unification in modern IT operations ...