Read time: 14 minutes
We are at a crucial time in this new agentic AI era.
One where the hype is beginning to fade, and things are starting to break. People have realized they can’t vibe code everything because it isn’t working six months later. People are also realizing that maybe LLMs and AI harnesses (e.g., Claude Code/ Cowork, Codex, etc.) aren’t always fit for purpose
So it felt like the opportune time to take you back to basics.
Because there are two foundational disciplines that will eventually determine whether anything you build (with or without AI) actually works: DevOps and DataOps.
I’ve been wanting to write about these two terms for a long time (mostly from a selfish perspective to conduct a deep dive into best practices).
Unfortunately, both are such interesting disciplines that are very misunderstood in the market. They get thrown around as buzzwords or ingrained into a product (”we do DataOps” seems to be a pretty common marketing phrase).
But in reality, they both operate as disciplines, applied at two different layers: first to software, then to data. And understanding what they actually are (and why they exist) matters a lot right now, because the next layer is starting to emerge (AgentOps, which I will write about next week), and the teams that skipped these software and data fundamentals are going to realize where they went wrong.
Let’s dive in!
What DevOps Actually Is (And Why It Still Matters)
To most people, DevOps is a term that basically means software engineering. Even to people in the data field, it is just an engineer who knows more about software than anybody on the team.
But when you look into it further, DevOps is the amalgamation of the two main areas for building anything, whether it be software, data tooling, or AI solutions. It is the discipline responsible for ensuring that things are built and run sustainably.
To understand why it exists, you need to understand the problem it fixed. Before DevOps was a popularized practice/ role, software organizations were split into two groups with different incentives. Developers were rewarded for building things quickly and shipping changes efficiently. Operations teams were rewarded for keeping the systems stable.
Unfortunately, as data and tech people know, every change is a threat to stability; therefore, developers would build something, pass it off to operations. Then, when something broke in production (which is inevitable), reconciling the blame and the solution between the two teams becomes incredibly difficult.
My whole career has been in an era where DevOps is a normalized term. So I was really interested to look back and see that there was a turning point in software where organizations figured out how to bridge the gap between these two teams.
The term was coined around 2009, but, as with anything in tech, it grew out of problems described by engineers on internet forums. An early example of success was Flickr, which shipped to production more than 10 times a day because its developers and operations people worked as one team with shared tooling and responsibility. The leader of each of those teams gave a conference talk in 2009 that was quite famous in DevOps circles and helped popularize the term. The focus was on faster, safer deploys with tighter cooperation, backed by the higher level of shipping features that other companies couldn’t match.
And that, along with its growing applicability and success, led to DevOps becoming more commonplace. Meetups, adoption in larger companies, and new role titles continued to evolve the domain into what it is today, where the whole software lifecycle is around building a better development culture.
So what does the discipline actually involve? Well, the actual process contains each of the components named above in the infographic. But it is the principles that really make DevOps a crucial capability in your dev teams:
Ship small and often – The biggest change was making software development smaller and more manageable. Big releases are inherently risky because they bundle hundreds of changes, and when something breaks, you don’t know which change did it (a huge problem with vibe coding right now). Small, frequent releases mean each change is easy to diagnose and less likely to break in production.
Automate the path to production – This is where CI/CD comes in: continuous integration (every code change is automatically merged and tested against the rest of the codebase) and continuous deployment (the tested change moves to production through an automated pipeline). CI/CD reduces the risk of introducing bugs, enables faster feedback loops, and provides visibility for everyone working on it.
Version everything – This idea is now commonplace with Git, where you can view every change to code (and eventually to infrastructure itself) as it is tracked in version control. This provides visibility into what changed, when, and by whom, and lets you roll back if something breaks. This underscores the CI/CD principle.
Own what you ship – Developers used to hand off their work to a separate team and walk away after it went to production. This changed with DevOps, and now the team that writes the code also operates it in production and answers for it when it breaks. This idea of ownership within a closed feedback loop makes sure outputs are better structured to survive inevitable issues.
Optimize for customer-centricity – Engineering teams naturally drift toward technical perfection when building. DevOps focuses on user needs, specifically by releasing small batches, observing how they're used, and letting that determine what gets built next.
Design for the end-state – This also feeds into where you are building towards. By shipping in small increments, you break down the problem and design for where the system is heading for user interaction when it is productionized. Planning for expected load, failure modes, and how it connects to everything around it helps create a system that actually works in the long-run.
Observability, monitoring, testing & security – I’ve lumped a few ideas into this principle. You have to see what is happening and protect against breaks simultaneously. Automated tests catch bugs before they ship; monitoring and observability (logs, metrics, and traces) tell you how the system is behaving in production; and security gets built into the pipeline from the start. These bits are the things non-DevOps engineers often forget, and are honestly why I love working with software engineers.
Essentially, it comes down to doing software development in a more structured, collaborative, automated, and customer-centric way. Is it mind-blowing? Not really; it is pretty straightforward and closely mimics many agile principles that business teams obsess over. But the point is that a culture built on DevOps principles doesn’t just build, but builds with purpose, structure and direction that often gets overlooked by junior developers.
And this approach works. The DORA research program (DevOps Research and Assessment, which builds the annual State of DevOps reports) sought to quantify this and found that the best teams apply these principles to be both fast and stable. This is underscored by four metrics: how often you deploy, how long it takes for a change to reach production, how often changes fail, and how quickly you recover. This idea has evolved with AI, but these four things are still fundamental to best practice software development
I’ve worked with DevOps engineers, and sometimes they seem slow, very methodical, and overly prescriptive, but I’ve also seen solutions built without these principles.
What ends up happening is a lot of breakdowns, a lot of rewrites, and often a retreat to the basic foundations (of DevOps principles).
And this is why DevOps will never go away; while we are obsessed with building as non-technical individuals, you need to think of these things if you want your builds to become maintainable.
The Emergence of DataOps
I’ve worked in a lot of data teams, and the one thing I can tell you is that ticket-based operations, ad hoc solutions and organizational silos are extremely common.
It basically leads to a culture of chaos. From my perspective, a big reason for this is that data was an add-on to business analytics; it was funded for its data science and analytics capabilities, and its success was reliant on the business teams using its outputs. This led to a lack of investment in the foundations and to the prioritization of outputs, tools, and ad-hoc request approaches that business teams were comfortable giving.
On the other hand, when you think about software, business teams avoid overstepping because they know they don’t understand the domain and that if something breaks, everybody is screwed.
So after a decade or so of fumbling around, DataOps emerged.
Essentially, DataOps is the DevOps approach pointed at data where you apply the same rigour (e.g., versioning, testing, automation, monitoring) to the pipelines and datasets that feed analytics. The term was coined by Lenny Liebmann in 2014, the DataOps Manifesto formalized it in 2017 with 18 principles (it has over 20,000 signatories now), and Gartner put it on the Hype Cycle for Data Management in 2018. So this idea has been around for a while, though in my opinion, not as popular or massively adopted.
While DataOps expands on DevOps, it operates in a different environment. Data is not software. Data solutions are built on an ongoing, continuous stream of information coming from multiple sources that impacts downstream system or solution viability. This inherently makes it harder to apply DevOps principles. And that’s without even mentioning all the other issues that come from the data industry, like misguided organizational structures, a lack of direction, or source system quality, etc.
This made the need for DataOps that much more important. Teams realized there was a break between the initial build of data tooling and its maintenance. A lot of this came back to poor foundations and team silos, things that DevOps helped fix within the software realm. However, at the same time, some key realities need to be considered for any team thinking about DataOps:
Data is continuous – Code changes when a developer changes it. Data will change whether you like it or not. Therefore verifying quality constantly (as things are in operation) is essential. This is something most organizations don’t fully understand, leading to a huge underinvestment in Data Governance or Quality teams.
Data can’t be controlled – While code is primarily written by your team (and now AI…), your data comes from source systems, vendors, partners, and customers. You don’t control these sources, leading to breaks or changes that you can’t foresee. Guarding these system changes is where Enterprise Data Architecture comes in, and is one reason a lot of AI POCs fail (because they don’t even consider that a data source system might change a field format or table, therefore breaking every dashboard downstream).
Data decays – This reality is the most underappreciated. Most code that worked yesterday works today (there are exceptions I know). But data doesn’t follow the same principle. It will become stale, incomplete or the definitions might change. This is why most business people “don’t trust the data,” one of the biggest cultural blockers in the industry.
So DataOps keeps the DevOps rigour and structure, while adding the components to handle unique data-related realities:
To be honest, this is why I think so many data vendors are trying to sell themselves as DataOps solutions: they frame their technologies as able to address these realities with DevOps principles in mind. Much of this began with data observability, monitoring, contracts, and other data quality components. Now we’re seeing the evolution toward a broader data warehouse or platform play (like Databricks or Snowflake) as development and operations merge in the data solution space. To be fair, it was the same evolution/ rationale that led to DevOps.
I’ve written about each of these ideas before in my data quality series last year, so I don’t want to spend too much time reiterating them.
The big thing to think about in DataOps is: How can we make it more structured and predictable, like DevOps?
Data professionals spend too much time working in an ad hoc manner, which is why DevOps makes so much sense to embed in the underlying ways of working or to build into the first principles of developing data solutions. Teams just need to understand the differences between the two, otherwise it won’t produce the benefits they are looking for.
Why Knowing This Matters For EVERYBODY
I’m a data strategist. I don’t usually code (although now I code a ton with AI as I’m running an independent consultancy), so why should I care about DevOps and DataOps?
Well, the simple answer is that everything you build or develop (even things that aren’t code or software) has a component of AI in the process. And the most important thing to get right in that world is the planning and structuring of your solution.
Because too many people are building right now without considering development and maintenance. Even if you are a product person or are dabbling in tools like Lovable or Base44 or creating things via Claude Code or Codex, you need to understand these different principles.
If you enjoy these infographics, please do share these/ the article! It means a lot and I want this type of thinking to reach everybody possible!
This is where DevOps lays the foundations:
Build in a Modular Fashion – The most common mistake I see in AI-built solutions (and non-AI-built ones) is a single monolithic build stitched together, where everything depends on everything else within a few scripts or files. So when one piece breaks, the whole thing breaks (and it becomes harder to find the issue). Building in small components is DevOps 101, and it needs to be the first thing people incorporate into how they work if they are going to build.
Versioning in the AI World – Maintaining logs on what and how you are building is super helpful in today’s world. Think prompts, config files, scripts, everything going into your build can/ should be saved somewhere where you can go back to. Overall, it is the mentality/ culture of creating the habit of tracking what changed and when, so that when something breaks (or when a change makes things worse), you have a working version to return to. This is where Git is so important/ necessary.
Testing Needs to Be Standardized – This is more of a mentality thing, as non-data people aren’t used to rigorous testing. Define what “good” means before you build, and turn those into checks that run whenever anything is changed. AI can write those tests alongside the build, but you need to establish your standards.
Ensure Products/ Solutions Have a Proper Architectural Foundation – AI makes it super easy to build anything without a proper plan or architecture. Building out a plan/ blueprint needs to be part of how every worker thinks moving forward. Things like what data the solution needs, where the logic lives, how the output reaches the person using it, and even what it costs to run. Start with the architecture and plan the tool build; retrofitting a foundation under something that already exists is way more expensive than designing it upfront.
Customer Centricity When Building – Building is now so fast that it’s easy to produce things nobody asked for. This is where you have to measure simplicity vs. complexity, and ensure what you are building adds to the end user experience and solves their need rather than creates complexity. Then release small and watch how it actually gets used. Adjust as needed.
After you’ve used these principles in your planning for the software, layer on the relevant DataOps concepts/ thinking to ensure the data quality matches up:
Map Your Data Workflows – To trust the solution, you need to trust the data. So it makes sense to take some time to draw the flow of data: which sources feed it, what transforms happen along the way, and what is the data/ decision output. I find that a visual artifact really helps stakeholders understand how data gets them the outputs they need.
Align on Data Definitions – This is one of the most visible problems within data operations and goes back to the idea of having a semantic/ context layer. When setting up your solutions, agree on the key terms/ definitions and what they actually mean so that your solution (and any AI agents hooked up to it) is working with the right metrics.
Understand the QA/Testing Required – This is different from the dev/maintenance tests for your build; it tests the data quality within the tool rather than whether the tool itself works. Incorporating continuous data checks (e.g., is the data fresh, is it complete, are the values in sensible ranges) within solution operations prevents them from becoming disused due to a lack of trust/ relevance. When mapping out the data QA/ testing, decide what happens when a check fails (e.g., who gets told, what stops running, what to do about it). Honestly, the siloed nature of technology and data teams has often led to this being overlooked as a principle and is one reason you see a lot of tools that work but use the wrong information.
Think Holistically About Data – I feel like I say this all the time, but DataOps as a domain has continued to expand in scope. DataOps (especially combined with DevOps) is a wide ecosystem of interactions and relationships. For example, the data you’re using comes from systems other people own, is used by other teams, and relies on definitions you didn’t write. Before you build, consider these things and incorporate them into your planning.
This isn’t an exhaustive list of suggestions or things to keep in mind, but it’s my version of what really matters, and what to always keep in the back of your mind. As roles come together, product managers, business stakeholders and even executives should have some sort of understanding for these types of things.
If embedded properly, the organization instills a culture of structured development, requirement gathering and considered execution. I will do further articles on key terms within the DevOps/ DataOps world (e.g., CI/CD, agile, Infrastructure-as-Code, etc.), but for now, hopefully this gives you a sense of what these two domains are and how to think about them in the wider world.
Next Time We Explore AgentOps
As you can probably tell by what you’ve read so far, DevOps and DataOps are more important than ever. But we are also entering a new era, one defined by Agentic AI.
Agentic AI has been a buzzy term for a while. And for a while, it didn’t live up to the expectations set by SaaS vendors and their marketing campaigns. Embedded AI programming changed that. Dev time has sped up exponentially, and teams are more empowered to build than ever, even product or non-dev people.
But at the same time, people are getting smarter and more structured in how they operate AI agents, especially if they want the ROI that companies expect. This is a key reason as to why I wrote about DevOps and DataOps at this industry junction.
And with AI Agents comes the emergence of a new term: AgentOps/ AgenticOps (the jury is still out on which one will stick).
An AI agent is software that operates on data in a continuous, autonomous way to accomplish a task specified by a prompt. The combination of data and software means AgenticOps is the direct descendant of both DevOps and DataOps. It needs everything DevOps figured out about shipping and running software reliably. It needs everything DataOps has figured out about keeping continuously changing data trustworthy. At the same time.
Oh and it has to contest with the fact that non-technical people will be dabbling in the domain.
So, before we jump into it next week, know that the teams that have actually instilled these two foundational disciplines will have a serious head start in Agentic AI. And the teams that skipped the foundations are going to have a much tougher time operationalizing Agentic products in this new AI world.
So until then, have a great weekend and see you next Sunday!
Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!
Really solid breakdown of why DevOps and DataOps are more than just buzzwords. The focus on strong foundations, automation, testing, and data quality is especially relevant as teams move toward AgentOps.
What you're describing has a shape, and I want to name it for you. Every DevOps principle you listed, ship small, version everything, own what you ship, is an engineering discipline for one thing: keeping a system's characteristic structure stable under continuous perturbation. There's a formal way of saying this. In topology, a trajectory persists when its core features survive bounded noise, and the metric that measures this is called a bottleneck distance. You're describing applied homotopy: how to build things whose identity holds across the rupture of production, across the fact that "data is continuous," "data can't be controlled," "data decays." That triad isn't a data problem so much as the exact perturbation profile the formalism was built for. You've already got the instinct. The mathematics is just the instinct made visible.
— Iman and Darja