Enabling and Governing at the Intersection of Data and AI

Part I: Enterprise Productivity

Intro

AI relies on data, yet enterprises still struggle with fragmented metadata, lack visibility into interconnected digital assets, disconnected governance, and siloed operations. The rise of LLM, AI Agent automation, and real-time analytics has made these issues even more pressing.

First, the increasing complexity of the “Modern Data Stack” continues to plague Data and AI engineering iterations. Second, DevOps principles like CI/CD, observability, and cross-functional alignment have driven success in software development, but simply mirroring them in DataOps, MLOps, and LLMOps is ineffective.

This article will analyze the current enterprise Data and ML/AI landscape, and evaluate strategies to unify data and AI operations with governance and enablement.

Who should read this?

• Enterprise AI & Data Leaders who need input to align AI/ML with Data strategy
• ML Engineers, Data Architects, Data Engineers who intend to implement scalable and unified workflow
• Product Managers who care about balancing between productivity enablement and guardrail governance in the intersection of Data and AI

If you’re looking for insights into AI for general users, stay tuned for Part II, ‘AI for Everybody’ (coming in Q2).

Let’s jump in. Below the ToC can help you navigate the long post.

The Enterprise Data Landscape
The Enterprise ML/AI Landscape
Patterns of Problems
The Path Forward

The Enterprise Data Landscape

The Enterprise Data landscape is relatively mature but not without growing pains. Data remains strategically critical, especially as emerging AI capabilities push for more. We’ll explore persistent and new challenges in data operations and lay out rationales for a central management strategy that can offer transparency, unification, and trusting experiences.

Horizontal operation-to-analytic data flow streamlined despite fragmentation.

Enterprises have become adept at deploying mature, scale-ready data technologies to address various needs (e.g., transactional, analytical, observability, etc.). Data movement and aggregation/materialization technologies (streaming or batch) have come a long way and have become reliable in ensuring high consistency and low latency lateral movement. Despite the deepening fragmentation from the “Modern Data Stack,” horizontal tabular data movement via technologies like CDC, ETL, reverse ETL, etc., is largely a solved problem.

Two centers of gravity have emerged around the operational data stores and the analytical data lake. Additionally, the widespread adoption of data movement created a third gravity center. In many large enterprise deployments, metadata siloing occurs within each gravity well*, typically associated with respective control and data planes. For instance, metadata that governs transaction schemas, indexing, and business entity-relations may be maintained within the operational data store’s control plane. In contrast, metadata related to data transformations, query performance, historical aggregations, and metrics lifecycle is kept separately in the analytical data lake’s control plane. Additionally, metadata about producer-consumer contract and schema evolution rules are stored in the data movement control plane.

*Gravity well refers to the abstract idea that relevant data and its metadata often gravitates towards the vertical infrastructures that suits the use case the best and easiest to store. Specifically in our case, we are referring to the operational, analytical, and data movement vertical infrastructures boundaries. In many enterprises, these gravity wells can form around organization boundaries.

The “Path of Least Resistance” rule suggests that metadata tends to gravitate toward the system where it is easiest to manage. Although enterprises urgently need data lineage to enable and safeguard fast changes, a central management solution still struggles today due to the silo. Just to name a few: complexity caused by inconsistent metadata propagation across gravity wells, unpredictable schema changes, and limited lineage visibility, which force reliance on tribal knowledge.

Takeaway: Enterprise metadata management should span the gravity wells of operational, analytical, and data movement. However, central metadata and lineage management lag behind despite streamlined horizontal data movement.

Vertical composability accelerates ML/AI adoption on existing Data Infra.

The Composable Data Management movement is gaining traction. Open-source standardizations are emerging across languages, logical intermediate representations, optimizations, physical compute and storage engines, and hardware (CPU, GPU, FPGA, ASIC) layers. The composable architecture enables use cases to decouple business intent from operational complexity, enabling abstractions for more productive automation and optimization.

Enterprises need AI-ready data infrastructure, but today’s data stacks are fragmented. Composable architectures solve this by unifying diverse execution engines under standardized APIs.

Key benefits of vertical composability:

• Declarative interfaces simplify AI workloads. Python & SQL APIs (e.g., Ibis, SqlGlot, RAPIDS, PixelTable, Daft, Rift, etc) reduce friction between ML engineers & data infrastructure.
• Query-engine interoperability removes vendor lock-in without rewrites. Open standards like Substrait, Velox, Gluten allow seamless Data/AI/ML execution across Spark, DuckDB, Flink, Presto, or other hardware (e.g., GPU).
• Unified orchestration accelerates AI deployment. Instead of isolated workflows, tools like Metaflow & Flyte provide cross-domain coordination across ML & data pipelines.
• New optimization opportunities arise where no individual engine can. If interested, please check out Optimizations Across a Composable Data Fabric[3].

Example: Instead of rewriting SQL queries for each engine, enterprises can use Ibis + Velox to execute AI workloads seamlessly across platforms without modifying business logic.

This movement sets the stage for a central coordination layer between use case declarations (e.g., codes and configs) and the diverse execution environments. A side benefit is that it provides a natural place to bridge metadata across gravity wells for governing entity lifecycles and lineages. A high-level diagram below shows the interactions in a realistic enterprise scenario.

Takeaway: The emergence of vertical composable data infrastructures sets the stage for a central coordinator layer to “enable” new use cases/user intents and “govern” platform operations.

Enterprises still demand end-to-end transparency.

Can you imagine a cross-country road trip with only a broken map? This is how many enterprises operate today. We’ll examine some example personas and use cases. I encourage the readers to scan through and think about how the current metadata silos and incomplete visibility reduce the potential impact.

• Legal/Data governance: desires real-time PII lineage tracking and column-level auditing to understand the risk/impact of an emergency model rollout.
• FinOps: needs quarterly data utilization insights to reason through cost optimization strategy across complex ETL chains.
• SWE/Data Engineers: need to search and discover dataset metadata and the corresponding code/config context to make effective design decisions. Today, tribal knowledge slows down teams.
• Data Scientists: need to query insights into dataset statistics (quality, performance, volume, etc.) and understand how dataset and/or model versions correlate to experiment results.
• Analysts: use natural language for semantic search to find relevant and accurate data context.
• AI Agents: retrieve data asset context and corresponding tools available in the current environment.

The shared pattern here is that all the conceptual enterprise entity assets, such as code/configs, datasets, models, services, and toolings, are all intrinsically correlated and continuously evolving. Without the big picture knowledge graph, siloed partial maps can only help with local optimal decision, but at the cost of losing out on the global optimal.

Having a central catalog that manages entity-relationship across the entire enterprise landscape is powerful. It can unlock any of the fore-mentioned use cases and more! LinkedIn’s DataHub is such a catalog that maps out data assets across silos. Leveraging entity-relation mapping for lineage tracking helps the company maintain transparency and enforce data contracts.

The diagram below shows a more complex but realistic entity mapping of a company that relies on data, ML models, and DevOps practices.

Takeaway: Enterprises desire to map out the full asset landscape for two main categories of use cases: Enablement, which enables builders to build, and Governance, which safeguards corporate functions.

Near-real-time freshness is becoming the norm as staleness degrades user trust.

Users rely on timely, accurate information to move quickly. Bad user experiences would hurt trust and inevitably push users to go around to the source, leading to siloing again.

Most modern catalog systems rely on reactive metadata collection. Metadata is either pushed from orchestration/schema systems or crawled/pulled from specific engine integration. While this works for many “happy path” scenarios, the indirection leads to potential metadata staleness and divergences from the source of truth. Murphy’s law applies.

Additionally, the hard truth is that if metadata only flows passively, the metadata catalog acts as an “observer” role, making it less authoritative in exerting environmental changes and being “in control” of governance and enablement activities.

Metadata silos correspond to the gravity wells, further challenging the role of governance and enablement as a mere “observer.” Each silo may have its unique failure modes that impact user experience consistency. For example, inadequately coordinated breaking product schema changes may bring down an analytical dashboard or a ML inference service. Today, it’s challenging when the change needs to propagate across gravity wells quickly enough, when information is stalled or relies on human speed. The current enterprise collaboration process is prone to human errors (e.g., unvalidated bad changes across silos) and suffer from a lack of near realtime change management across silos (e.g., impact report for every pull request, reactive alerts based on mutual contractual obligations between producers and consumers, etc).

These challenges are complex but not unsolvable. For now, let’s focus on a technical solution. It’s not hard to conclude that evolving the traditional metadata catalog from a passive “observer” into an active “facilitator “ has benefits. A reasonable approach is declarative reconciliation[4]. Some readers may notice that we have already alluded to this approach in Figure 3.

A success example is Alibaba Cloud, which has championed declarative application management in the cloud. This technical strategy enabled near-real-time freshness and nicely stitched DevOps principles into a pragmatic approach. We can further align the declarative reconciliation approach with the composable data architecture pattern to decouple user intent and underlying execution with tools such as gitops. This approach provides flexibility and allows engineers to choose between cost, freshness, and correctness (e.g., pick streaming engine vs batch engine).

Figure 3 can be a good starting point, but I’ll use two sequence diagrams to flush out more details.

It’s worth noting that this idea is not new. Shirshanka, CEO of DataHub (a prominent data catalog player), shared many similar ideas in his talk “Building a control plane for data”[5]. Given the increasing enterprise challenges, it’s time to adopt and promote the vision.

Takeaway: The conventional “observer” positioning of the Enterprise Metadata catalog, compounded with technology fragmentation and organizational gravity wells, slows the catalog in fulfilling the “enablement” and “governance” values. An alternative is to evolve the traditional catalog into a declarative central management layer.

Now that we have examined many challenges in the data landscape, let’s switch gears and explore how these challenges further manifest and correlate with the enterprise ML/AI landscape. When reading the subsequent sections, remember that composable data, declarative reconciliation architectures, and a push for near-real-time capabilities align well with the enterprise ML/AI operation needs. Pay closer attention to emerging trends such as feature stores, real-time evaluations, continuous training, etc. Let’s jump in.

The Enterprise ML/AI Landscape

Data and models go hand in hand, but today many artificial boundaries slow down the feedback loop. This section explores how Data/ML feedback loops, unstructured data management, and the rise of AI agents are reshaping enterprise operation strategies.

Data-to-ML feedback loops need more comprehensive central tooling.

Traditional ML models rely on computed features as inputs to inference services. Features are typically computed in batch or streaming pipelines depending on the freshness requirements. Fresher features typically get better prediction results. Pre-computed features are stored in KV for fast inference time retrieval. A redundant copy is often stored in the data lake in tabular form (for different access patterns such as training), along with computed labels (i.e., ground truth) and logged predictions. Collectively, these data serve model training, evaluation, and performance monitoring purposes.

Production ML data processing, such as feature engineering, resembles data pipelines. They share the same data visibility, search/discovery, governance, and management needs. Production ML also requires similar engineering practices to track experiments, model/data versioning, inference service deployments, and workload (e.g., training) scheduling.

Effective ML systems rely on a tight-knit data-to-model feedback loop, which enables continuous model updates to improve business metrics. As a result, experimentation lineage, versioning, and deployment metadata are critical for data science Root Cause Analysis and feature impact understanding.

In practice today, Data Engineering focuses on data pipelines, ETL, and data governance while Machine Learning Engineering focuses more on model training, deployment, versioning, monitoring, and feature engineering. The overlapping intersection between the two fields is growing and converging on a few fronts:

• Transparency in lineage, versioning, and various entity relationship (see figure 4).
• Establish a holistic model, data, and deployment contract to formalize agreement between producers and consumers, enforce data quality, SLA, rollout strategies, and change/notification expectations.
• Better workflow coordination that spans across data and ML silos.

Takeaway: Accelerating Data and ML/AI feedback loop requires more transparent and holistic Data+ML operational practices.

The emergence of unstructured data processing with foundational models adds additional challenges.

The recent development in foundational models (e.g., LLM) and agentic applications pushed a spike (and very likely sustained need) in the processing of unstructured data (e.g., PDF, text, audio, and video) into embeddings for RAG, similarity search, and AI agent use cases.

On the data platform side, this trend will materialize on two fronts:

First, enterprises need unstructured data ingestion.

1. Support new data types (audio, video, text, PDF) and make it easy for ingestion via a user-friendly API/UX. (e.g., Daft, Pixeltable, etc., are already spearheading this direction).
2. Add storage types (e.g., vector, embedding, knowledge graph, block stores) in the mix and track lineage accordingly.
3. For different unstructured types, register and associate transformation capabilities (e.g., audio -> transcription -> chunking -> embedding, or video -> frame extraction -> dedup -> embedding) and work with orchestration, compute, and inference infrastructure at scale.
4. The emergence of embedding stores, knowledge graphs, and coordinated transformations paves the way for DataOps and LLMOps convergence.

Second, applications, agents, or models need a more comprehensive and reliable context. Unlike structured tabular data, which shares metadata across all its rows at the table (or stream) level, e.g., schema, owner, and PII columns. Each piece of unstructured data (analogously to each row in a table) will require its own context and entity relationship metadata. For example, an ingested audio recording will need to capture basic metadata such as timestamps, tags, and point to a transcribed text file on S3 (via a transcription transformation), then point to multiple sequenced entries in an embedding store (via embedding model inference transformation) that each capture an encoded paragraph. Each of these may point to a node in a graph database to capture additional metadata such as speaker relationship. Storing all these metadata would enable ranking algorithms in a semantic search or RAG scenario. As a result, the volume of unstructured data metadata can be explosive, and we shall pay close attention to scaling bottlenecks for such use cases.

Takeaway: Enterprise Data Platforms must handle unstructured data. New silos will likely appear, but enterprises that can see around the corner will be more competitive longer term.

AI agent automation needs context protocol and can benefit from more granular access control.

Experts speculate that AI agents will revolutionize SaaS and productivity. I wholeheartedly agree, but I’d like to analyze what’s missing to enable this future. Let me break it down.

Governance: AI agents will revolutionize data discovery, automation, and enterprise productivity. However, their unstructured, free-form execution makes them risky unless tightly governed. A possible governance model may look like:

• Zero-Trust Access Control: AI agents should follow least privilege principles and integrate into enterprise IAM systems (e.g., OAuth, RBAC, Zero Trust), with its human counterpart registered as guardian. When the agent is outside secure perimeters, enforce Trusted Execution to avoid data leakage.
• Human-in-the-loop Approvals: AI-driven actions on sensitive data (e.g., finance, HR) should require multi-stage approval flows before execution.
• Enterprise-Grade Auditing: AI agents should operate as individual identities, with traceable records of queries and responses to ensure compliance.
• Granular and gating access control: Early adopters prefer more granular access control until the agent-to-environment interactions prove themselves (e.g., minimal hallucinations or consistently satisfying goals).

Enablement: Like humans, AI agents must perceive their environment, use available tools, and evaluate outcomes to achieve their goals. Hence,

• Access to search and discovery capabilities. Both AI and Human agents require search and discovery capabilities to navigate the enterprise map, understand entity relationships, and grasp the context.
• Access to tooling context. Both AI and Human agents must discover what tools are available to interact with the data platform (e.g., API documentation, capability limitations, deployment workflow, and how to engage with support workflow if needed). Anthropic’s Model Context Protocol offers a good start but is nowhere near production readiness in an enterprise environment. Be aware that tribal knowledge will likely be the biggest blocker for both, but it will undoubtedly impact AI more than humans. So, building for an AI future would require us to solve challenges for humans first.
• Agent-to-environment feedback loop. Both AI and Human agents need to be able to observe the impact of their actions in the environment and measure against their goals for a feedback loop. Metrics, experiments, and a data-driven decision culture become critical.

Takeaway: In short, if enterprises’ challenges in search, discovery, productivity, and governance remain unsolved for human users, AI agents will inherit these inefficiencies. Addressing these foundational issues is critical to enabling human and AI-driven data operations.

Operations are converging across Dev, Data, ML, and LLM.

The DevOps movement (2009–2015) emerged to break down silos between development and operations during the cloud era where microservices was the norm, emphasizing CI/CD, automation, and infrastructure as code.

The DataOps (2017–2018) emerged as organizations struggled with reproducibility, automation, and monitoring of data pipelines. The goal was to bring DevOps-style agility and automation to data engineering, ETL, and data governance.

The MLOps (2018–2020) emerged as ML became more operationalized, focusing on model training, deployment, versioning, monitoring, and retraining. Kubernetes, TensorFlow, and MLFlow contributed to many standardizations that attempted to bring DevOps principles over.

The LLMOps (~2022-present) focuses on operation supports to scale, fine-tune, deploy, and monitor LLMs efficiently. W&B, Hugging Face, and others formalized operational workflows in prompt engineering, fine-tuning, inference optimization, etc.

Each step in this evolution arose as organizations needed more specialization beyond traditional DevOps for Software Engineering. By the time AIOps (ML, LLM) came into the picture, it was solving challenges that DevOps never had to consider, such as model drift, prompt evaluation, and GPU orchestration at scale. However, many principles, such as metric-driven decisions, CI/CD automation, experimentation, observability, and fast operation feedback loop are foundational.

While there is value in specialization, the furthering silo is slowing teams down and preventing enterprises to reach global optimal (e.g., cost optimization, lineage visibility, privacy governance, and more).

We are also seeing industry trends showing signs of convergence.

• DataOps + MLOps. Feature stores like Feast and Tecton were developed to ensure consistent feature computation and reproducibility across training and inference. In parallel, LandingAI’s Data-Centric AI[6] approach exemplifies broader efforts to bridge DataOps and MLOps.
• DevOps + MLOps. ML model observability and automated rollback mechanisms (e.g., Arize AI, Evidently AI, Fiddler AI, Elastic etc.) are examples of unifying DevOps and MLOps.
• DevOps + MLOps + LLMOps. Unified orchestration frameworks (e.g., Metaflow, Flyte, Prefect) integrate data, ML, and AI pipelines. A recent example from Netflix [7] shows similar GitOps practices to version control configs, declarative deployment, and automated flow deployments. It demonstrates how a unified central layer can streamline deployment and management of diverse workloads, ranging from traditional analytics to ML personalization.
• DataOps + LLMOps. Vector databases & knowledge graphs aim to unify DataOps and LLMOps.

While separating DevOps, DataOps, MLOps, and LLMOps may remain viable in the short term, there is an increasing need to address painpoints from silos. Enterprise engineering operations will gradually converge, incentivizing integration with governance capabilities that span these specializations in a central supporting layer.

A central governance and enablement management layer could work if:

1. A new abstraction relational model unifies how data, ML models, and LLMs are managed.
2. Cross-functional teams adopt shared operational standards (e.g., DORA principles).
3. A trusted central user experience provides accurate, fresh context and security for human and AI agents.
4. Central user experience does not slow down local innovation.

Takeaway: While DevOps, DataOps, MLOps, and LLMOps have emerged as specialized domains, the trend is toward convergence. This convergence demands a central governance and enablement layer that can manage the unique challenges of each domain while optimizing for global goals like cost and lineage visibility.

Patterns of Problems

Congrats on getting this far! Let’s summarize the recurring painpoint patterns just to refresh the memory. Feel free to skip this section if you feel like having a good grasp already.

1. Siloed Metadata: Fragmented across operational, analytical, and movement layers, hindering end-to-end lineage.
2. Disjointed Operation Practices: DataOps, MLOps, and LLMOps remain isolated, limiting efficiency and automation. Engineering operations demand a unified governance and enablement approach while maintaining local decision velocity.
3. Opaque Visibility: Lack of unified code/config, data, model, and service mapping slows governance and decision-making.
4. Staleness: Metadata catalogs act as passive observers, causing freshness and reliability issues.
5. Slow Data-ML Feedback: Poor versioning, lineage, and tracking across the data-model chasm slows down model iteration cycles.
6. Scaling Unstructured Data: LLM-driven workflows will create massive metadata and processing challenges.
7. Agents Need Structure: Agents, both human and AI, lack structured discovery, security, and observability. Tribal knowledge still slows down collaboration.

Conclusion: To improve productivity and future AI adoption, enterprises must unify metadata management, enable real-time governance, and integrate AI/ML/DataOps workflows into a central management layer.

The Path Forward

Step 0: Audit your Enablement & Governance Maturity

• Map your metadata silos
• Map out gaps in the entity-relationship knowledge graph
• Identify governance and enablement operation gaps (e.g., real-time lineage, AI security, automation, PII management, etc)

Step 1: Start cultivating a central enablement and governance layer

What is this central enablement and governance layer?

Instead of treating governance as an afterthought, enterprises need a real-time, structured governance and enablement layer that bridges data, ML, and AI operations.

The central layer is NOT another metadata catalog or MLOps framework. It’s a systematic approach to managing data, AI, and operational workflows across silos.

How does it differ from existing solutions?

• Unlike metadata catalogs that passively track lineage, this layer enforces real-time governance of entity changes (code, config, dataset, model, experiments, etc.), ensuring AI/data workflows meet communication, compliance, security, and operational efficiency goals.
• Unlike MLOps tools (e.g., MLflow, Flyte, or Metaflow), which focus on AI pipelines, this layer ensures cross-domain governance spanning DataOps, MLOps, and LLMOps using contracts between producers and consumers.
• The intent is to integrate, not replace, existing orchestration tools (e.g., Airflow, Prefect, Kubeflow).

What is this layer responsible for?

• Capture entity metadata across the entire enterprise landscape, and power the search and discovery experience. The experience should be convenient, fresh, accurate, and trustworthy for various personas such as SWE, MLE, Analysts, executives, finance, and operations. (Figure 4)
• Capture entity-relationships across silos and collect dispersed context that existed as tribal knowledge to power security and compliance needs. (Figure 4)
• Connect user-authored code/config, facilitate DevOps operations, and apply guardrails. (Figure 3, Figure 6, Figure 7, and Figure 11)
• Define, monitor, and enforce entity contracts to ensure data, model, and deployment quality and align producer and consumer expectations. Well-executed contracts clarify expectations, a path to risk mitigation, operation efficiency, accountability, and trust.

Data contracts can include accountable owner, data quality assertions (SLAs) and monitoring, schema evolution, business/regulatory rules, data constraints (null check, acceptable range), and consistency guarantees, delivery semantics (at least once, at most once, exactly once) and freshness guarantees.

ML contracts can include accountable owner, model quality assertions (SLAs), model input constraints (feature, preprocessing, type, shape), output interpretation guidelines, training data rules, test split requirements, versioning, lifecycle rules, model degradation threshold and rollback/failover rules, retraining and refresh cadence, bias detection, model explainability requirements, stakeholder communication expectations etc.

LLM/Agent contracts can include accountable owner, LLM/Agent quality assertions (SLAs), input/output guidelines, model evaluation criteria, versioning, revision history, tolerance for hallucinations, training/fine-tuning dataset lineage backtracking, provenance tracking, prompt lineage, security clearance, and generated content governance strategy such as watermarking, embedding/vector guidelines, style and standard guidelines etc.

• Define context protocols for dataset, model, and tooling so that human and AI agents can automate discoveries and make changes.

Consider culture and organizational change management.

Introducing a central layer is difficult as it may slow innovation or face resistance without a change mindset. Considering the organizational culture and change management aspects is wise when rolling out such a central strategy. There is a lot here and warrants a separate blog post. But in short, cultivating a culture where responsibility and freedom are two sides of the same coin is essential. Additionally, figuring out the right team behavior, automation requirements, lean process, metrics, and communication strategy that fits your organization will be pivotal for its success. Depending on your organization’s culture, a successful execution will require top-down (leaders) and bottom-up (peers) support. Figure out the value prop both ways, and use concrete numbers in context to make your case.

Step 2: Use AI for Governance

This central layer is perfect for introducing AI agents for value-add automation.

• Use AI agents to crawl, collect dispersed context, and interact with human stakeholders to ensure accuracy.
• Use AI agents to automate the detection of issues, especially at the boundary of org/tech silos, and surface them before they become problems.

Step 3: Governance and Enablement for AI

• Build context description protocol to enable human and AI agents to discover environmental changes.
• Build DevOps and security integration to manage blast radius when things go wrong.
• Controlled rollout applied for AI agents to manage risk.

Congrats on crossing the finish line! I’d love to hear your comments and feedback!

I’d also like to express my gratitude to everyone who has spent time reviewing the initial draft and giving feedback. Thank you! Sharon Xie, Lei Zhang, Scott Shi, Shinji Kim, Shirshanka Das.

References

[1] Taleb, N. (n.d.). The red queen effect: Avoid running faster to stay in the same place. Farnam Street. https://fs.blog/the-red-queen-effect/

[2] Pedreira, P., Erling, O., Karanasos, K., Schneider, S., McKinney, W., Valluri, S. R., Zait, M., & Nadeau, J. (2023). The composable data management system manifesto. Proceedings of the VLDB Endowment, 16(10), 2679–2685. https://doi.org/10.14778/3603581.3603604

[3] Xu, Z. (2023, October 8). Saving millions with 5-minute streaming SQL techniques & future-proofing an optimized composable data ecosystem. Data Engineer Things. https://blog.det.life/5-minute-practical-streaming-techniques-that-can-save-you-millions-6d6b49400308#2da1

[4] Alibaba Cloud. (June, 2020). Fundamentals of declarative application management in Kubernetes. Alibaba Cloud Blog., from https://www.alibabacloud.com/blog/fundamentals-of-declarative-application-management-in-kubernetes_596265

[5] Das, S. (March, 2023). Building a control plane for data [Keynote presentation]. Data Council. DataCouncil., from https://www.datacouncil.ai/talks/building-a-control-plane-for-data

[6] Landing AI. (n.d.). Data-centric AI. https://landing.ai/data-centric-ai

[7] Berg, D. J., Casler, D., Cledat, R., Huang, Q., Lin, R., Pow, N., Sonmez, N., Srikanth, S., Wang, C., Wang, R., & Yu, D. (2024, December 20). Introducing configurable Metaflow. Netflix TechBlog. https://netflixtechblog.com/introducing-configurable-metaflow-d2fb8e9ba1c6