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.
One thing you're not making explicit in this piece for either DevOps or DataOps, and it's critical for Agents, is the management of infrastructure as code and the mgmt of data as code.
Prior to DevOps most infrastructure teams manually deployed and updated servers. Want a new service, then Matt needs to go rack a new box. With server virtualization and IaC tools we could now manage compute and storage the same way we manage applications.
The parallel in DataOps is we used point and click tools to build data transformation and cleansing pipelines with tools like SSIS, Informatica, and Alteryx. With DataOps tools like Coginiti or dbt we started doing that work in a code first way that was modular and versionable.
Code first is critical when it comes to agents because they can read and generate code, whether that's infra code or a CoginitiScript data pipeline.
I mentioned this in my LinkedIn comment too, but I really appreciate this perspective, Matthew.
I've slightly updated the piece to include this in, and I will do another article on Infrastructure as Code/Data as Code, just like I promised to do another one on CI/CD. That said, I'll mention your comment, dialogue and some further commentary around it in a bit more detail in my AgenticOps article next week. Thanks again for the feedback, love hearing from the experts!
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
One thing you're not making explicit in this piece for either DevOps or DataOps, and it's critical for Agents, is the management of infrastructure as code and the mgmt of data as code.
Prior to DevOps most infrastructure teams manually deployed and updated servers. Want a new service, then Matt needs to go rack a new box. With server virtualization and IaC tools we could now manage compute and storage the same way we manage applications.
The parallel in DataOps is we used point and click tools to build data transformation and cleansing pipelines with tools like SSIS, Informatica, and Alteryx. With DataOps tools like Coginiti or dbt we started doing that work in a code first way that was modular and versionable.
Code first is critical when it comes to agents because they can read and generate code, whether that's infra code or a CoginitiScript data pipeline.
I mentioned this in my LinkedIn comment too, but I really appreciate this perspective, Matthew.
I've slightly updated the piece to include this in, and I will do another article on Infrastructure as Code/Data as Code, just like I promised to do another one on CI/CD. That said, I'll mention your comment, dialogue and some further commentary around it in a bit more detail in my AgenticOps article next week. Thanks again for the feedback, love hearing from the experts!