With more than seven years spent inside the data operations of large healthcare and financial organizations, Velangani Divya Vardhan Kumar Bandi has watched the discipline of data engineering shift from a back-office function into the foundation that decides whether an AI initiative succeeds or quietly fails. He built pipelines at CVS Health, worked on real-time risk and analytics systems at SoFi, and handled regulated healthcare data at Ascension Health before founding NB Alpha Omega, a boutique data and AI consultancy serving healthcare and financial services clients.
He holds Google Cloud Professional certifications in both data engineering and machine learning engineering, and his research on self-optimizing data pipelines applies machine learning to the infrastructure itself rather than only to the applications running on top of it. In this interview, Vardhan discusses what enterprise scale really demands, why most machine learning projects never leave the notebook, and where he believes data engineering is headed over the next decade.
What Enterprise Scale Actually Demands
Vardhan is direct about the gap between how data engineering is taught and how it works inside a large regulated organization. The hardest part, he argues, is rarely the technology.
Working inside organizations like CVS Health, SoFi, and Ascension Health taught me that enterprise data engineering is completely different from what most people see in tutorials or certifications. The biggest realization was that technology itself is rarely the bottleneck. The real challenge is building systems that can handle scale, governance, compliance, reliability, and business expectations at the same time.
The CVS Health Standard for Data Quality
At CVS Health, that meant treating data quality as an operational safeguard rather than a technical nicety. A pipeline that moves records is trivial, he says; a pipeline that moves them defensibly is the actual work.
Building a pipeline is easy. Building a pipeline with hundreds of validation rules, audit controls, reconciliation mechanisms, PHI protection, lineage tracking, and regulatory compliance while processing millions of records daily is where enterprise engineering begins. Every transformation has to be explainable and traceable, because downstream teams rely on that data for operational and strategic decisions.
What SoFi Taught Him About Technical Debt
His time at SoFi sharpened a different set of instincts around latency, resilience, and the long shadow of early architectural choices. Financial systems, he notes, punish shortcuts quickly.
When you are dealing with financial transactions, customer behavior, credit risk models, and streaming systems, latency, resiliency, and observability become non-negotiable. The architecture decisions made on day one can either support growth for years or become technical debt that slows down the entire organization.
Treating Pipelines as Products
The lesson that reshaped his thinking was to stop treating pipelines as internal plumbing and start treating them as products with real consumers. As a founder and CEO today, that framing drives how he builds.
Data engineering is actually a product. At enterprise scale, pipelines should be treated as products with SLAs, reliability metrics, adoption goals, and continuous improvement cycles. The consumers of the data are effectively your customers. Enterprise engineering is not about moving data. It is about creating trusted decision-making platforms that operate at scale for years while adapting to changing business needs.
Why Machine Learning Projects Stall Between the Notebook and Production
Vardhan estimates that building a model is a fraction of the real work, and that most teams misjudge where the effort actually lives.
Organizations underestimate the gap between building intelligence and operationalizing intelligence. Building a model inside a notebook is probably 20 percent of the effort. The remaining 80 percent is integrating it into business workflows, data ecosystems, governance frameworks, and user adoption.
The 80/20 Problem
A model with 95 percent accuracy is useless if data pipelines are unstable, business KPIs are undefined, or nobody trusts the output.
Testing Whether AI Should Be Built at All
His approach starts before any code is written. Rather than framing work as an AI project, he frames it as a business product that happens to have AI inside it, and he applies a simple test to decide whether it is worth building at all.
The systems I have built were never approached as AI projects. They were approached as business products with AI embedded into them. The test I apply is simple: if AI disappears tomorrow, will this product still solve a business problem? If the answer is no, we do not build it.
Measuring Success After Deployment
That discipline extends to how success is measured. From the first day of a build, Vardhan insists on operational metrics rather than model scores, and he treats deployment as a beginning rather than an ending.
We establish measurable KPIs from day one, tracking things like turnaround time, matching accuracy, productivity gains, and user adoption rather than model metrics alone. For us, deployment is actually the starting point. Once the system enters production, that is when continuous learning begins. The companies that win are not necessarily the ones with the smartest models. They are the ones who repeatedly convert business pain points into reliable, scalable systems that people trust and use every single day.
Choosing a Cloud Platform Is a Business Decision First
Despite holding Google Cloud certifications and shipping across AWS, Azure, and Databricks, Vardhan refuses to lead a client conversation with the platform. He starts with the problem instead.
I do not believe in cloud loyalty. I believe in architectural pragmatism. When an organization asks whether they should build on AWS, Azure, GCP, or Databricks, my answer is always the same: tell me the business problem you are trying to solve for the next five years.
A Framework for the Decision
Over years of building across healthcare, finance, and consulting, he developed a repeatable framework for the decision, weighing where a client’s data already lives, how mature the organization is, whether it has the foundations AI actually requires, and how heavy its regulatory burden is.
The first dimension is data gravity. Moving petabytes of data between clouds because a technology is trending is an expensive mistake. The second is organizational maturity, because sometimes the best technology is not the most advanced one; it is the one the organization can successfully operate and govern. Then there is AI readiness, talent availability, and regulatory complexity. In healthcare and finance, security, auditability, and data residency often matter more than raw technical capability.
What Each Platform Actually Does Well
He is deliberate about avoiding vendor lock-in, and he sees each platform as strong at something different rather than universally better. Databricks, in his view, is less a rival to the major clouds than a layer that spans them.
Every cloud platform is exceptional at something. AWS excels at breadth and operational scale, Azure at enterprise integration, GCP at data, analytics, and AI innovation, and Databricks at bringing data engineering and machine learning workloads together. The real differentiator is not choosing the right cloud. It is choosing the right architecture independent of the cloud.
Applying Machine Learning to the Infrastructure Itself
Vardhan’s research grew out of a contradiction he kept noticing inside enterprises: sophisticated models running on top of infrastructure managed by static rules and manual guesswork.
We were always using machine learning to predict customer behavior, patient outcomes, fraud, or revenue, but the systems powering those models were still being managed using static rules and human assumptions. I kept asking myself a simple question. Why are we building intelligent applications on top of infrastructure that is fundamentally unintelligent?
From Static Rules to Self-Optimizing Systems
That question became his work on self-optimizing cloud data pipelines, published on ResearchGate, where machine learning models observe a system’s own behavior and adjust it over time. He began to think of data platforms less as fixed architecture and more as something closer to a living system.
Instead of engineers constantly tuning pipelines manually, we built systems where machine learning models observed historical execution patterns, resource consumption, failure patterns, latency trends, and cost behaviors to make decisions around autoscaling, scheduling, and resource allocation. It was intentionally designed to be portable across AWS, GCP, Azure, and IBM environments.
Why Peak Performance Is the Wrong Goal
The most useful finding was counterintuitive: chasing peak performance often made systems worse, because organizations were paying constantly for capacity they needed only rarely.
Most organizations are unknowingly over-engineering their systems. They provision resources for worst-case scenarios that occur maybe 5 percent of the time while paying for them 100 percent of the time. The models taught us that the optimal state is not maximum speed; it is dynamic equilibrium between cost, latency, reliability, and business criticality.
Toward Cognitive Data Engineering
The research also reframed data quality as an infrastructure signal, not just a business concern, which pushed his work toward what he calls cognitive data engineering and a view of AI systems as a single closed feedback loop.
Poor quality data was not just a business problem. It directly impacted compute utilization, orchestration delays, and operational costs. I no longer see data engineering, MLOps, and AI as separate functions. The future is building autonomous data ecosystems where systems continuously observe themselves, learn from themselves, and improve themselves. We are moving from data pipelines to cognitive infrastructure.
Designing Compliance Into the Architecture
Vardhan pushes back on the common complaint that compliance slows engineering teams down. The real drag, he says, is architecture that was never planned for it.
I disagree with the idea that compliance is a tax on velocity. Poor architecture is the real tax on velocity. If HIPAA, financial audit trails, or governance requirements are introduced at the end of a project, they will always slow teams down because engineers are forced to redesign systems that were never built to support them.
His answer is to make governance a default property of the platform rather than a task each team repeats. Controls like classification, encryption, access management, lineage, and audit logging should be inherited automatically.
I design systems with governance by default, where data classification, encryption, tokenization, role-based access control, lineage, and audit logging are embedded into every stage of the data lifecycle. Engineers should not repeatedly build compliance mechanisms from scratch. Every pipeline should already have those capabilities before any business logic is even developed. In regulated industries, the product is not just data or AI. The product is trust itself.
The Skill Formal Training Keeps Missing
When mentoring early-career engineers, Vardhan focuses on a capability he says degree programs and bootcamps rarely teach: the ability to see past a single component to the whole system around it.
Degree programs and bootcamps do a great job teaching Python, SQL, machine learning, and cloud technologies, but they rarely teach engineers how to think beyond their own component. Many engineers optimize for becoming great coders, but organizations do not pay for code. They pay for solving business problems at scale.
He coaches them to trade a narrow build-the-model question for a set of harder ones about context, consequences, and value.
I push engineers to stop asking how to build a model and instead ask what happens before it receives data, what happens after it produces an output, who consumes it, how success is measured, and what the risks are if it fails. An engineer who understands the entire ecosystem will always be more valuable than someone who only understands a single technology stack. Over the next decade, systems thinkers will become significantly more valuable than tool experts.
Overhyped Models, Underrated Foundations
Asked what the field is fixated on versus what it neglects, Vardhan does not hesitate. The attention on agents and new model releases, he argues, distracts from the unglamorous work that actually determines whether AI succeeds.
AI agents and the constant race toward newer models get far more attention than they deserve, while data foundations and operational intelligence are still heavily underestimated. In my experience, 70 to 80 percent of AI failures have nothing to do with the model itself. They come from fragmented data, poor governance, weak lineage, and disconnected business processes. An organization does not have an AI problem. It has a data maturity problem disguised as an AI problem.
What Deserves More Attention
In his view, it is the connective tissue of a mature data ecosystem, along with a stronger tie between engineering work and the business outcomes it is supposed to produce.
The future of data engineering is moving away from pipeline-centric thinking toward ecosystem-centric thinking. A beautifully engineered pipeline means very little if nobody can explain how it improves revenue, reduces risk, or accelerates decision-making. The future winners will not be the companies with the biggest models. They will be the ones with the strongest data foundations. Eventually, every company will have access to AI, but not every company will know how to operationalize intelligence at enterprise scale.
Across enterprise pipelines, published research, and the consultancy he now leads, Vardhan returns to a single conviction: that durable systems are built for the organizations and people who depend on them, not for the technology of the moment. It is a view shaped by years inside regulated environments where reliability was never optional, and one he now brings to the healthcare and financial services clients that turn to NB Alpha Omega to make their data genuinely usable.
Marcus Whitfield writes about developer tools, programming languages, and the software trends shaping how engineers build. Before joining DevX, he spent five years as a full-stack developer and two more running a small dev-tools newsletter that topped 10,000 subscribers.
