Previously: Part 3 made the case for Qlik Cloud Analytics as the platform that keeps domain teams small, fast, and in full control of their own pipeline. This part addresses the objection that follows naturally from that argument: does a domain team that builds its analytical environment in Qlik paint itself into a corner as the organization’s data maturity grows?
Written by Phuoc Tran Minh
The Legitimate Objection
Every technically sophisticated reader who has followed this series to Part 4 has a version of the same concern, and it is a fair one.
The Pragmatic Mesh model argues for small domain teams owning their analytical environment end to end. In Part 3, that environment was Qlik Cloud. But large organizations are not collections of isolated domains. At some point, Finance needs to join their revenue data with the Marketing team’s customer acquisition data. The enterprise data team needs to understand what logic the Sales domain has applied to their pipeline numbers before they publish the consolidated forecast. The data science team needs access to the clean, curated datasets that the domain teams have built, in a format their tools can actually consume.
If each domain team is operating in its own Qlik environment, and Qlik’s native format is a proprietary binary, does the Pragmatic Mesh model just recreate the silo problem at a smaller scale?
Does starting with Qlik mean being stuck with Qlik? Not at all, due to many recent improvements in Qlik and open standards like Parquet and Iceberg.
Parquet: The Open Handshake
Apache Parquet is an open-source, columnar storage format that has become the closest thing the modern data ecosystem has to a universal language. Snowflake reads it. Databricks runs on it. Apache Spark processes it natively. AWS, Azure, and Google Cloud all support it as a first-class format. It is the file format that data pipelines, data lakes, lakehouses, and machine learning platforms all agree on.
Qlik Cloud can export data directly to Parquet. This means the curated, business-logic-enriched datasets that a domain team builds in Qlik — the clean sales data with correct product hierarchies and attribution rules, the customer segmentation with AI-enriched classifications, the financial metrics with the right aggregation logic — can be written to a shared data lake in a format that every other tool in the enterprise can read without any translation layer.
The domain team is not locked into Qlik for their data outputs. They choose Qlik because it makes their development fast and their models powerful. But they can easily make data products available to the enterprise in a format that imposes no dependency on Qlik at all. The Finance team’s Snowflake queries can read the Sales domain’s Parquet files directly. The data science team’s Python notebooks can load them without a Qlik licence. The enterprise data platform can ingest them into its central data lake without knowing anything about how they were produced.
Data Product REST API: The Lighter-Weight Alternative
Parquet is the right answer when the consumer is another data pipeline, a data science notebook, or a lakehouse query engine. But not every cross-domain data exchange is a bulk file transfer. Sometimes what a downstream system needs is a governed, on-demand query against a specific dataset: a business application pulling current KPIs, an AI agent retrieving validated figures for a response, a downstream dashboard refreshing a single metric.
Qlik’s Data Products feature, with its REST API, addresses this pattern directly. A domain team can package a curated dataset as a governed data product, with defined ownership, versioning, and quality rules, and expose it via a standard API that any application can call. The consumer does not need to understand how the data was built, who maintains it, or what transformation logic produced it. They call the API and get a validated, trusted result.
This is not a replacement for Parquet-based data sharing at scale. It is a complement: real-time, low-volume access for applications and AI agents alongside bulk export for analytical pipelines. Together, the two patterns cover the vast majority of cross-domain data consumption scenarios without requiring the domain team to build custom integration work for every new consumer.
Earned Trust: Quality Signals for Downstream Consumers
There is a question that any downstream consumer of a domain team’s data will eventually ask, and it is not a technical question. It is a trust question: how do I know this data is good enough to use?
In a centralized data warehouse, the answer was implicit: the central team certified the data, and certification was their job. In the Pragmatic Mesh model, where domain teams own and publish their own data, the answer needs to be explicit and auditable. Trust cannot be assumed from the source. It has to be demonstrated at the point of consumption.
Qlik addresses this through its Trust Score feature, which assigns a quantified quality signal to a dataset based on measurable properties: completeness, consistency, freshness, and — for teams using their data in AI workflows — fitness for LLM consumption, including factors like metadata richness and potential bias. The score is not a marketing badge. It is a structured quality assessment that a downstream consumer can inspect, question, and factor into their decision about whether to use the data for a given purpose.
For the Pragmatic Mesh model, Trust Score does something organizationally important: it makes a domain team’s quality standards legible to the rest of the organization without requiring a central governance team to audit every dataset. The domain team owns the quality. The score makes that quality verifiable. That is the right division of responsibility.
The Growth Path: When the Data Lake Needs to Scale
For many organizations, Parquet files in cloud storage is sufficient for cross-domain data sharing. But for teams operating at significant scale, or with complex requirements around data versioning, schema evolution, and time-travel queries, there is a natural next step: Apache Iceberg.
Iceberg is an open table format built on top of Parquet that adds the capabilities that enterprise data teams need when their data lake starts to behave more like a data warehouse: ACID transactions, schema evolution without data migration, partition pruning for fast queries, and the ability to query data as it existed at any point in time. It is supported by every major cloud data platform and is rapidly becoming the standard for serious lakehouse architectures.
The relevance for the Pragmatic Mesh model is this: a domain team that starts by exporting Parquet files can graduate to writing directly to Iceberg tables as the organization’s data maturity grows, without changing the fundamental approach. The domain team still owns its pipeline. The data still reflects their business logic. The difference is that it now participates in an enterprise lakehouse architecture that supports cross-domain queries at scale, versioned data contracts, and integration with cloud data platforms like Snowflake and Databricks. The starting point does not constrain the destination. Each stage is a genuine upgrade rather than a rebuild, as described in table below.
The domain team’s Qlik environment and strong ownership does not change as the enterprise layer matures. What changes is the output format and the orchestration around it. That continuity is itself a form of organizational capital that most data platform migrations destroy.
AI as the Documentation and Translation Layer
One of the persistent concerns about domain teams owning their own pipelines is lineage and legibility. If the Sales domain’s Parquet files land in the enterprise data lake, and those files were produced by a Qlik load script that only one developer fully understands, what happens when that developer leaves? What happens when the enterprise data team needs to audit the logic for a regulatory review? What happens when someone downstream gets a number they cannot explain and needs to trace it back to the source?
This is a real concern and it deserves a practical answer rather than a reassurance. The practical answer, in 2025, involves large language models used in a specific and grounded way.
A Qlik load script is readable code. It is not a black box. Given a load script, a capable LLM can do three things that are genuinely useful for lineage and governance:
Generate human-readable documentation. Describing in plain language what each section of the script does, what business rules are encoded, and what transformations are applied at each step. This documentation can be maintained automatically alongside the script, so it stays current rather than drifting from the code it is meant to describe.
Flag logic that warrants review. Joins that could produce fanout, fields with ambiguous naming, hardcoded date filters that will break at year boundaries, business rules that are applied inconsistently across different sections of the script. A senior developer reviewing the script manually would catch these. An LLM can surface them as a checklist before the review rather than during it.
Translate load script logic to SQL. For teams that need to migrate a Qlik pipeline to a different platform, or that need to replicate the logic in a downstream system, an LLM can produce a working first draft of the equivalent SQL transformation. It will not be production-ready without review, but it reduces what was previously a weeks-long reverse-engineering exercise to a starting point that takes hours to validate and refine.
AI readability doesn’t stop at the load script either: Qlik’s extensive API’s make all the app UIs, semantic layer (called master library in Qlik), access rights and reload task configurations accessible to automated documentation and auditing.
The Architecture Earns Its Freedom
The argument across Parts 3 and 4 is essentially this: the Pragmatic Mesh model is not a compromise between speed and scalability. It is a sequenced approach that delivers speed first, at the domain level, and earns its way into enterprise-scale architecture through open standards rather than being forced into it from the start.
Starting fast and staying open are not in tension. They are a sequence.
The domain team that ships a novel sales analysis in three days is not doing something that conflicts with the enterprise data team’s lakehouse strategy. They are doing something that can feed into it, once the output format is Parquet and the governance rituals are in place, which brings us to the last part of this series: how to implement lean governance that doesn’t create centralized bottlenecks.
COMING UP IN THIS SERIES
Part 5: Four governance rituals that bulletproof your data handoffs without slowing your team back down to the pace they were trying to escape.
Fast and trustworthy are not opposites. Part 5 shows you how to be both.
