Written by Phuoc Tran Minh

Previously: Parts 1 to 5 argued that data initiatives fail for organizational reasons, not technical ones. Data Warehouses fail because they centralize ownership, and Data Meshes because they bury it under engineering (Part 1, The Great Data Strategy Reality Check). Ownership is a condition you create, not a policy you declare (Part 2, Small Teams, Strong Ownership). The platform decides how small a team can stay (Part 3, The Data Platform Has to Get Out of the Way). Open standards keep fast domain teams from getting trapped (Part 4, Start Fast, Stay Open). Governance works as lean rituals, not control (Part 5, Achieve Trust and Data Quality Without New Software And Bureaucracy). This part adds no new architecture. It looks at the same argument through a lens every manager uses every day: the org chart.

A note on perspective: as in Parts 3 to 5, the second half of this part makes a specific case for Qlik. I work with Qlik. The first half holds on any platform.

Why Do We Have Org Charts?
Start with a question that sounds too simple to ask. Why does every company have an org chart?

Org charts are not elegant. They draw boxes, and boxes are silos. Sales optimizes for Sales, Finance optimizes for Finance, and the boundaries between them are where good initiatives go to die. Every manager has complained about silos, and most have lived through a reorganization meant to break them.

And yet nobody abolishes the org chart, because it answers the one question an organization cannot function without: who decides? Who owns this budget, this customer segment, this product line, this problem when it breaks at two in the morning?

Silos are the price. Clear ownership is what you buy with it. Experience says the price is worth paying.

The Matrix Experiment
The matrix organization was the fashionable cure for silos: keep the business lines, overlay them with shared functions and platforms, give people two bosses, and everyone has to collaborate. On paper, the silos are gone. In practice, every decision now needs both sides of the matrix to agree, nobody is quite sure who owns the outcome, and the organization slides into bureaucracy and analysis paralysis.

Nokia’s fall is the textbook case, even if the matrix was not the only reason it fell. In 2004, Nokia reorganized its business into a matrix. Yves Doz of INSEAD, who has studied the company in depth, calls it a “poorly implemented 2004 reorganisation into a matrix structure”. Product line executives with P&L responsibility were locked in conflict with shared platform managers who were “struggling to allocate scarce resources”. In his words, this “conflictual way of working slowed decision-making and seriously dented morale”. Many managers left. When the iPhone and Android arrived, Nokia still had the engineers, the money and the market share. What it no longer had was a fast, clear answer to “who decides?”

In February 2011, the new CEO, Stephen Elop, put it bluntly in his “burning platform” memo to staff: “I believe we have lacked accountability and leadership to align and direct the company through these disruptive times. We had a series of misses. We haven’t been delivering innovation fast enough. We’re not collaborating internally.”

Read the last sentence again. The matrix was introduced to make people collaborate. Seven years later, the CEO’s diagnosis was missing accountability and missing collaboration.

Take away clear ownership and you do not get more collaboration. You get less of both.

One Person, Not a Committee
The fastest companies tend to go the other way. At the D8 conference in June 2010, Steve Jobs described how Apple worked: “You know how many committees we have at Apple? Zero. We’re structured like a start-up. We’re the biggest start-up on the planet.”

Apple took single ownership down to the level of individual tasks. Adam Lashinsky’s 2011 Fortune reporting describes the DRI, or Directly Responsible Individual: every action item from an effective meeting has one name next to it, and “Who’s the DRI on that?” is a standard question around the company. “At Apple there is never any confusion as to who is responsible for what.”

In the same interview, Jobs called Apple “an incredibly collaborative company”. Collaboration and single ownership are not opposites. Ownership is what makes collaboration end in a decision instead of another meeting.

So the lesson is well established, and most of us learned it the hard way: whether you draw it as an org chart or not, every important part of the business needs one clearly named person who is responsible for it and can decide.

Every important part of your business needs a strong, clear owner. Your data is an important part of your business.
Now Draw the Org Chart of Your Data Warehouse
Here is the exercise. Take your enterprise data warehouse, your lakehouse, or the semantic layer your organization is building for AI. Try to find its org chart.

You will find plenty of documents. A data strategy. A target architecture. Schemas and layers: bronze, silver and gold. Naming conventions. A governance framework with a RACI matrix in an appendix. What you will struggle to find is the page that says: this person owns customer churn data, end to end, and can make the final decisions and implement them without asking for anyone’s approval.

Ask around and you get a matrix. The platform team owns the infrastructure. The data engineering team owns the pipelines. The architecture board owns the model. A data steward in the business owns the definitions, on paper. The BI team owns the reports. The business owns “the requirements”.

Every one of them is responsible for a layer. Nobody is responsible for delivering the answer.
That is Nokia’s matrix, rebuilt in data. A change to one business rule needs the platform team, the pipeline team and the model owners to agree across their separate backlogs, prioritization meetings and release schedules. Through the org chart lens, the cause of this bottleneck is plain: the central warehouse is not short of talent or technology. It is short of an org chart.

And the business notices. When nobody owns the answer, people build their own, in spreadsheets and disconnected tools. Shadow IT is the business drawing the org chart that the official data platform never had.

A Data Org Chart
This is the real case for decentralization, and it is simpler than most Data Mesh literature makes it sound. Decentralization is not primarily an architecture. It is an org chart for your data: every data product has a named business owner, the same way every business unit has a named head.

But a box on an org chart only means something if it comes with a budget and a team. A unit head with no staff and no budget is not an owner. Part 2 put it this way: authority means decision rights and dedicated implementation resources, and if you give a team responsibility without them, you have not created ownership. You have created a scapegoat.

Data Mesh, as usually implemented, stops halfway here. It draws the boxes, then asks each domain to staff them with platform engineers. The Pragmatic Mesh makes sure the owners are not owners on paper only, but have the resources to act: a dedicated full-stack developer, a platform one person can run end to end, open standards so the box is not a prison, and lean rituals for the boundaries between boxes.

“Dedicated” does not mean exclusive. A full-stack developer is often a shared resource, responsible for several apps and sometimes for more than one domain. Dedication means something else. Think of a good family doctor: you can call any time, they understand your situation at once, and when it is urgent, you come first. A dedicated developer fully understands every app they are responsible for, takes emotional ownership of each one and is proud of all of them.

Qlik: A Platform Shaped Like an Org Chart
This is where I think Qlik fits better than any other analytics platform I know. Qlik is not just a visualization tool. It comes with a mindset and best practices that have agility and decentralization at their core: small teams that have end-to-end ownership and build the whole thing, close to the business. And the platform’s structure maps naturally onto a data org chart. Two concepts carry it: spaces and apps.

Spaces are the departments. Create one space per business unit or function, which in practice means one per data domain. Each space has a named business sponsor, who decides on its development priorities and resourcing, and a technical space owner, the domain’s Qlik lead developer, who runs it day to day. Inside the space, the domain owns everything from raw data to the visualization layer: the data connections to its sources live in the space, and so do the apps built on them. It owns its access rights, through space roles (who can edit, view or reload) and section access in the load script for row-level security. And it owns its release path: develop in a shared space, publish to a managed space when an app is ready for a wider audience. As Part 3 noted, spaces keep teams independent of each other in data, user permissions and compute resources, so one team’s full autonomy cannot put another team’s resources at risk.

Apps are the teams. Under each space sit the apps. Each app has a clear key user from the business and a full-stack Qlik developer who builds it from any available data sources to the dashboard, and in the platform every app has a single named owner. Semantic layer and data product definitions are owned at either the space or the app level, always by a clearly named owner.

A data org chart in Qlik Cloud: shared platforms on top, and each domain space owns its data, logic and apps. The Logistics space is opened up as the example. Every role in it is held by a named person.
Spaces and apps are deceptively simple concepts. That is the point. An org chart is a simple concept too; its power is that everyone can read it. Below is a detailed summary table of the concepts explained above.

Why This Is Different in Power BI and Tableau
To be fair: Power BI and Tableau also have containers you could draw an org chart with, workspaces with roles in Power BI and projects with permissions in Tableau. And Power BI Desktop can hold the Power Query transformations, the data model and the report in a single file, so one person can in principle build end to end there too.

The difference is in what each platform is designed and recommended to do by default, which dictates whether they really support full-stack development technically and mentally.

Power BI. Microsoft’s own guidance for scaling self-service (“managed self-service BI”) is to decouple the semantic model from the reports: a few shared semantic models for “a single version of the truth”, “commonly maintained by a centralized team (like IT, BI, or Center of Excellence)”, in a separate workspace from the reports business experts build on them. Microsoft notes the split is not required, but it is the recommended path to scale, and it is the central warehouse org chart again: one box owns the model, other boxes own the visuals.

Tableau. Tableau’s documentation calls publishing data sources separately from workbooks “a step toward centralizing data management”, with policies “geared toward minimizing data source proliferation”. Heavier data preparation lives in a separate tool, Tableau Prep Builder. Again, the data layer and the visualization layer are separate boxes, often with different owners.

Qlik. The unit of work is the app, and the app holds the whole stack: the load script that pulls and transforms the data, the associative data model, the master items, and a powerful UI. The natural thing to do in Qlik is for one developer and one key user to own all of it. It is also why a Qlik app is usually much broader in scope than a typical Power BI or Tableau dashboard: it is built to explore a whole domain, or a major part of one, from KPIs down to transactional details, slicing across dozens of dimensions.

One Qlik load script and data model can become quite complex, but it is much easier to maintain in the end than dozens of simple but totally independently created self-service dashboards that a single Qlik app can replace. That is why I argue that Qlik is the best platform for governed, agile full-stack analytics development, and for creating data silos, deliberately!

When Silos Are the Right Answer
Silos are not always bad; the org chart proves it. The useful question is not “silos or no silos?” but “where do we need them?”

You need them where two things matter most: quick iteration and strong ownership. When the business question is new, the logic is uncertain, and the answer is needed this week, the work has to sit inside one box, with one owner who can change it without asking three other teams. That is the roughly 95% of data that never leaves its home domain (Part 2).

Choosing silos by no means excludes creating and sharing governed data products, nor does it mean abolishing the central data warehouse altogether. It means keeping costly interdependencies out of the way wherever rapid iteration is needed, so if you prefer avoiding the too negatively sounding “silos”, you could just as well talk about modular design or decentralization. For the 5% of data that crosses boundaries, you do need governance but that can be done with lean methods: open formats and APIs (Part 4) and the One-Page Data Handshake (Part 5).

There is also a situation where central process works well: stable specifications. If a report has had the same definition for years and will keep it for years to come, strong ownership and agility matter less, and more formal process control for analytics development is perfectly fine.

But be honest about how often that situation still exists. In a rapidly changing, AI-driven world, new questions, new data and new uses arrive every month, faster than any annual data roadmap can absorb. The stable specification is becoming the exception. The common case is the one that needs an owner who can move fast.

A self-contained domain silo is a price paid deliberately for strong ownership and agility, not a deviation from best practice.
Draw the Chart.

Here is a small exercise for your next leadership meeting. List your important data products and dashboards. For each one, answer three questions: Who is the single business owner? Do they have a dedicated developer? Can they change it this week without a committee?

Wherever the answer is no, you have found your bottleneck, and it is not a technical one.

You would never run a business unit without an org chart. Do not run your data without one.

COMING UP IN THIS SERIES
Part 7: The Semantic Layer You Already Have. Every organization is now building a semantic layer for AI. Why your domain-owned apps may already be one, and why AI needs a thin map that routes to the owners and never redefines what they own.

Written by GOODIN BI Lead Phuoc Tran Minh

Here is the scenario that has been waiting in the background of this entire series.
During a CRM version upgrade over a long weekend, the customer service team consolidates their churn reason codes. What were previously two distinct values, “price sensitivity” and “competitive loss,” get merged into a single value. The change is deliberate and well-reasoned from a CRM administration perspective: the two categories had been inconsistently applied by different regional teams for years, and the migration is the right moment to clean it up.
The Parquet file exported by the Customer Service domain team on Monday morning looks identical to the previous week. Same schema. Same row counts. Same field types. No nulls in critical fields. Every stop-the-line assertion passes. Every automated quality check is green. The data is technically perfect.

But the Sales leadership team’s churn analysis now shows competitive losses have effectively doubled while price sensitivity has disappeared entirely from the dashboard. Over the following three weeks, leadership commissions an urgent competitor analysis and pricing review, preparing for a workshop to formulate new go-to-market and product development strategies to be presented in the next board meeting.

The root cause surfaces only when a CRM specialist mentions in passing that the reason codes changed in the version upgrade. No automated system could have detected it. The data was correct by every technical measure. What changed was meaning, and meaning lives in the heads of the people who use the data, not in the schema. Three weeks of misdirected strategic effort are not recoverable.

The most expensive data failures are not the ones that break the pipeline. They are the ones that let it run perfectly while feeding the wrong story to the people making decisions.

The traditional enterprise response is to buy expensive data cataloging software, enforce rigid data contracts, and build automated lineage tracking pipelines. In other words, to solve a human coordination problem with an engineering solution, adding exactly the kind of complexity that caused the Data Mesh to collapse under its own weight in Part 1.
The Pragmatic Mesh takes a different position. Fast, autonomous teams do not need more software or process gates. They need lightweight social contracts: shared expectations, clear accountability, and a small number of habitual practices that prevent the most common failure modes without slowing anyone down. We call these lean governance rituals. There are four of them, and any team can implement all four by next Monday.

Ritual 1: The One-Page Data Handshake
Before a domain team shares a dataset with another team, they write a single page. Not a formal specification. Not a forty-field entry in an enterprise data catalog. A page. It lives in whatever shared documentation tool the organization already uses: Confluence, Notion, a Teams channel, a shared drive. It covers exactly four things.

The four things a Data Handshake must answer:
Owner: The specific human being, not a team inbox, who is the first call if something looks wrong.
Cadence: When is this dataset updated? Daily by 8am? Real-time every 15 minutes? The consumer needs to know when to worry if it has not arrived.
Grain and meaning: What does one row represent, and what do the key classification fields mean in this business context? The reason code scenario above would have been prevented by a single sentence here: “Churn reason codes follow the classification scheme defined in the CRM migration document dated [date]. Any changes to this classification will be communicated two weeks in advance.”
Schema and semantic lock: A commitment that core column names, types, meanings, and business classifications will not change without two weeks’ notice to all known consumers. Not a legal contract but a personal and professional commitment by the owner.

Whatever documentation platform you use, it should have one specific capability: automated notifications. Consumers of a dataset subscribe to its Data Handshake page and receive an automatic alert any time it is updated. This is a pull model, not a push model — people subscribe to the datasets they actually consume, rather than receiving every update from every domain team. That distinction matters because broadcast fatigue is a real failure mode: if every change goes to everyone, people stop reading.

The subscription notification is the safety net. When a domain team updates the Data Handshake page, subscribed consumers are alerted automatically. The team should also broadcast the change to the release notes channel described in Ritual 3 for the benefit of consumers who have not yet subscribed. Together, these two layers cover both the known and the overlooked consumers of every shared dataset.

Ritual 2: Stop-the-Line Assertions
In lean manufacturing, stopping the production line the moment a defect is detected is a foundational quality principle. Data pipelines need the same instinct. A domain team using Qlik can embed simple validation checks directly into the load script, before the export to Parquet runs. These are not sophisticated testing frameworks.

They are basic sanity checks that catch the technical failure modes that happen most often.

Practical stop-the-line checks to build into every load script:
Duplicate primary keys in the output? Abort and alert.
Row count more than 20% lower than yesterday’s run? Abort and alert.
Key metric negative or zero when it should not be? Abort and alert.
Null values in fields that should never be null? Abort and alert.

The core principle is deliberate failure over silent corruption. It is always better for a downstream consumer to receive data that is 24 hours old than data that is quietly wrong. An alert that says the pipeline did not run is immediately actionable. A pipeline that ran and produced corrupted output can contaminate decisions for days before anyone notices.

Crucially, these checks catch technical failures. They would not have caught the reason code scenario, which passed every technical check perfectly. That is precisely why the semantic commitments in Ritual 1 and the human communication in Ritual 3 exist alongside them. No automated check validates meaning. These rituals work as a system.

When Tooling Makes Governance Easier, Not Heavier
Qlik Cloud Analytics now includes AI-assisted data quality rules that complement stop-the-line assertions without replacing them. Rather than writing validation logic manually, a team member describes the intent to Qlik’s Discovery Agent which will then proactively raise red flags when it detects potential anomalies. No specialist skills required, no ongoing maintenance overhead. Qlik’s Trust Score feature extends this further, giving downstream consumers a quantified quality signal based on completeness, freshness, and consistency, without requiring anyone to design a quality framework from scratch.

Similar AI-assisted quality tools will proliferate across the industry. They are worth adopting when they reduce cognitive load and keep processes simpler for the team. They are worth ignoring when they require dedicated configuration, specialist maintenance, or create their own process overhead. The test is always the same: does this tool help the small team stay small and focused on the business, or does it give the team a new system to manage?

Good tooling is governance that runs itself.
Ritual 3: The Release Notes Channel
The most expensive data failures are caused by silent semantic changes. A metric calculation is updated. A classification scheme is consolidated during a system migration. A date filter or lead-time calculation shifts from shipment creation to pickup date. Each change is correct and intentional from the domain team’s perspective. None of them are visible to the teams depending on the data, unless someone says something.

The fix is a single shared channel, a dedicated Slack or Teams channel called something like #data-updates, where any domain team about to make a meaningful change to a shared dataset posts a brief note. Not a ticket. Not a change request. A message.

Example message:
“Hey everyone — following our CRM migration this weekend, we have consolidated the churn reason codes. ‘Price sensitivity’ and ‘competitive loss’ are now a single code. If you use churn reason in your dashboards or models, please check whether this affects your logic. The updated classification is in the Data Handshake page. Happy to answer questions.”

That message takes two minutes to write. It would have saved three weeks of misdirected strategic effort in the scenario above. The channel also serves as a lightweight audit trail: when an analyst notices an unexpected shift in a metric weeks later, they can search the channel and find the explanation without opening a ticket or scheduling a meeting. The combination of automated subscription notifications from Ritual 1 and this broadcast channel creates two layers of communication, covering both the consumers who subscribed and those who did not yet know they needed to.

Ritual 4: The Quarterly Swamp Draining
When exporting data is as easy as adding one line to a load script, shared storage accumulates quickly. Old project exports never deleted. Experimental datasets that became permanent by accident. Three versions of the same customer table from three different points in a migration. Over time the shared space becomes a swamp: technically navigable, practically confusing, and quietly corrosive to the confidence downstream teams have in the data they find there.
Once a quarter, get the domain data owners together for a thirty-minute meeting with one agenda item: look at the shared storage and remove anything that is not actively maintained and consumed.

The decision rule:
Not updated, accessed, or queried in 90 days: archive to cold storage with a clear label, or delete.
Nobody in the room knows who owns it or what it contains: delete.

Name does not clearly indicate what it is, when it was created, and who owns it: rename before the meeting ends.

Swamp draining is the governance ritual that feels least like governance. But it forces a regular conversation between domain owners about what data actually exists, who is responsible for it, and whether it is still worth maintaining. Teams that know what each other are publishing coordinate without being forced to. That awareness, renewed every quarter, is one of the most effective defenses against the silent semantic drift that causes the failures described at the start of this part.

Governance as Culture, Not a Control Process
Four rituals. One page of documentation per shared dataset. A few lines of validation code in each load script. A two-minute message when something meaningful changes. A thirty-minute meeting once a quarter. That is the foundational governance framework for the Pragmatic Mesh.

The reason it works is not technical sophistication. It is proportionality. The vast majority of costly data failures are basic communication failures: someone changed the meaning of something without telling anyone, someone did not know what a classification field represented, someone could not find the right version of the data. These are human problems, and they respond to human solutions.

The heavy enterprise approach to governance makes it technically difficult to cause these problems. The lean governance approach makes it culturally normal not to. The heavy approach requires ongoing maintenance, license fees, and specialist knowledge. The lean approach requires only a shared commitment to a small number of intuitive habits. Build the culture of accountability first. Buy the software only when you genuinely have to, and only when it makes the process simpler rather than adding a new one.

Good governance is not primarily about rules but about people who feel personally responsible for the quality of what they publish.

The One Thing That Will Undo All of This
There is a warning that belongs at the end of this series, because it describes what happens to well-designed small teams if they are not vigilant: the complexity will grow back.

Complexity accumulates naturally in any successful system. A domain team ships a working pipeline. Another team depends on it. A third depends on the second. An edge case requires a new field. A regulatory requirement demands an audit log. A new tool is added for a specific problem. Each individual addition is reasonable. Collectively, they erode the conditions for strong ownership more reliably than any organizational restructuring.

As complexity grows, authority weakens because more stakeholders are required for every decision. Understanding fragments because no single person can hold the full picture anymore. Motivation drains because the work becomes about managing the complexity rather than serving the business. The small team that was shipping insights in days starts opening tickets, waiting for approvals, and writing documentation nobody reads. The backlog appears. Then the specialist roles to manage the backlog. Then the processes to coordinate the specialists. The centralized data team has reconstituted itself, this time inside the domain.

The defense is active, not passive. It requires deliberately minimizing dependencies between domains, preferring integrated tools over best-of-breed stacks that need orchestration, choosing free-form collaboration over rigid JIRA workflows/approval chains for routine work, and treating every addition to the team’s technical surface area as a cost to justify rather than a capability to acquire. Simplicity is not the default state of a growing system. It is the result of consistent, intentional resistance to the forces that undermine it.

The Pragmatic Mesh is not a one-time implementation. It is an ongoing discipline of keeping things simple enough that a small team can own them completely and feel personally accountable for every part of what they have built.
Accumulating complexity is how strong personal ownership dies quietly. Every unnecessary dependency, every approval step, every new tool that requires its own specialist is a transfer of ownership away from the team that was supposed to have it.

Where We Started, and Where We Have Arrived
In Part 1, we described a pattern that plays out repeatedly in large organizations. They build the centralized Data Warehouse. It arrives late, costs more than planned, and becomes a bottleneck the moment it goes live. The business loses patience and builds its own analytics in the shadows. The organization ends up with both problems simultaneously: a stagnating warehouse they cannot retire and a self-service sprawl they cannot govern. When it fails, it is always the technology or the consultant gets the blame, never the centralized model.
Data Mesh was meant to fix this by returning ownership to the business. In practice, it replaced one form of complexity with another, asking business analysts to become software engineers as the price of autonomy. The failure rate speaks for itself.

The Pragmatic Mesh starts from the observation that the root problem was never technical. It was motivational and organizational. People without authority, understanding, or a visible connection to the impact of their work do not take ownership, regardless of what the org chart says. Daniel Pink described this at the level of individual motivation. It applies with equal force to how data teams are structured.

The model this series has argued for is not complicated. Small teams embedded in business domains, with dedicated developers who stay long enough to develop real understanding. A platform that keeps the full stack manageable for a single capable person. Open standards for output so local speed does not create enterprise silos. Lightweight social contracts based on personal commitment instead of compliance theater. Active vigilance against the accumulating complexity that will quietly dismantle everything if left unchecked.

None of this is radical. The best software product teams have operated this way for years. The data industry has simply been slow to catch up, distracted by the promise of each successive architectural silver bullet. The warehouse did not fix the ownership problem. The lake did not fix it. The mesh did not fix it. The Pragmatic Mesh does not fix it either, because no architecture can. What architecture can do is stop making the problem worse, and give the people doing the work the conditions they need to solve it themselves.

The competitive advantage in data does not come from the most sophisticated architecture. It comes from empowered, motivated people who understand their domain, own their pipeline end to end, and feel personally accountable for what they produce.

The warehouse that arrived 18 months late and became a bottleneck was not a technology failure. It was a structure that guaranteed the wrong people would own the wrong decisions with no skin in the outcome. Fix the structure, choose the right platform, build the social contracts, and defend simplicity like the strategic asset it is.
That is what the Pragmatic Mesh is. Not a product. Not an architecture. A set of conditions under which strong personal ownership of data becomes possible, and where the people closest to the business problem are also the people with the authority, the tools, and the motivation to solve it.

THE PRAGMATIC MESH SERIES: A SUMMARY
Part 1: The Data Warehouse fails because it centralizes ownership. The Data Mesh fails because it confuses organizational autonomy with infrastructure engineering. Most organizations end up with both problems simultaneously.
Part 2: Strong ownership requires authority, understanding, and motivation — Pink’s autonomy, mastery, and purpose applied structurally. Small, business-embedded teams with dedicated developers are the only structure that satisfies all three. Co-creation builds the relatedness that makes the work worth doing.
Part 3: The platform is the team size constraint. Qlik Cloud Analytics enables full-stack development by a single capable person, with fast feedback loops, transparent load script logic, and no infrastructure overhead. One well-designed associative model replaces dozens of fragmented point-solution reports.
Part 4: Starting fast does not mean staying trapped. Parquet, the Data Products REST API, and Apache Iceberg provide a clear maturity path from domain-level iteration to enterprise lakehouse architecture. Qlik Talend Cloud is the natural extension for complex data integration at scale.
Part 5: Fast, autonomous teams stay reliable through four lightweight social contracts: the Data Handshake, Stop-the-Line Assertions, the Release Notes Channel, and the Quarterly Swamp Draining. Governance as culture, not compliance, and active resistance to accumulating bureaucracy and complexity that quietly weakens personal ownership.

Most data initiatives fail for the same reason: nobody owned it personally enough to make it succeed. No architecture fixes that. What you need is the right structure, platform, and culture: the Pragmatic Mesh.

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.

BY Phuoc Tran Minh, GOODIN BI Lead

Previously: In Part 2, we established that strong ownership requires authority, understanding, and motivation, and that authority is hollow without dedicated implementation resources and stable developers. The platform choice is the load-bearing wall of the model: it determines how small and fast your domain team can actually be. This part is where the platform argument gets specific.

A straightforward disclosure

In Parts 1 and 2, the argument was purely structural: why the current models fail, and what the right organizational conditions look like. From here the series gets specific about technology, and specifically about Qlik Cloud Analytics. I consult with Qlik. I am going to make a case for the platform. I want to be clear that this recommendation comes from having watched what works and what does not in real enterprise environments, not from a feature sheet.

If you use a different platform and the principles from Parts 1 and 2 resonate, the principles still apply. But if you are evaluating your options, I am going to give you an honest account of why I think Qlik gets the fundamentals right for the model we are describing.

Let us start with a real-life situation. Just the kind of moment that happens in every large organization, probably multiple times a month.

It is Tuesday afternoon. The VP of Marketing needs to present Customer Acquisition Cost by channel to the board on Friday. The numbers currently live in three places: the CRM, the ad platform exports sitting in someone’s Downloads folder, and a finance reconciliation spreadsheet that the CFO’s team updates monthly.

The marketing analyst knows exactly what the answer should look like. She has built versions of this report in Excel before. But the data needs to be clean, joined, and defensible before it goes to the board. So she raises a ticket with the central data team.

The central data team is not being obstructive. They are genuinely busy. The ticket lands in sprint planning. The earliest they can look at it is three weeks from now. By which point the board meeting is over, the decision has been made on the basis of the Excel version anyway, and the carefully engineered data product will be used once, by the analyst who already knew the answer.

This is not a data quality problem or a governance problem or a prioritization problem. It is a latency problem. The gap between the moment a business question becomes urgent and the moment a reliable answer is available is too wide to be useful. And it is structural: it is baked into any model where the person who understands the question and the person who can answer it are separated by an IT backlog.

The Pragmatic Mesh model solves this by putting the analyst and the developer on the same small team, co-creating in the same environment. But that only works if the environment itself does not require three specialist roles to operate. Which brings us to the platform.

What the Platform Actually Has to Do

Most platform evaluations focus on the wrong question. The question is usually: what can it do? The right question for the Pragmatic Mesh model is: what does it stop you from having to do?

A platform that makes a small domain team viable needs to do three specific things well.

First, it needs to abstract away infrastructure. The developer on the domain team should be thinking about business logic, not cluster management, container orchestration, or storage configuration. Every hour spent on infrastructure is an hour not spent understanding the business problem. The platform should handle the plumbing invisibly so the team can focus on the data flowing in the pipes that actually matter to the business.

Second, it needs to close the feedback loop. The marketing analyst in the scenario above should be able to see the impact of a data model change immediately, not after an approval and deployment cycle. When a join produces unexpected nulls, that should be visible in minutes, not discovered by a stakeholder in a meeting three weeks later. Short feedback loops are what make co-creation between a business expert and a developer actually work in practice.

Third, it needs to enable full-stack development by a single capable person. This is the capability that makes the small team model viable. If one analytically capable developer can take a business question from raw source data all the way to a governed, shareable data product and management dashboard without needing to hand off to a pipeline specialist, a modelling specialist, and a visualisation specialist, the team stays small. The moment the platform requires multiple handoffs and coordination between different specialists, the team grows, the backlog appears, and you are back to the centralized model with domain branding.

The best platform is not the one with the longest feature list, but the one that keeps your team small and agile by having full control of their own pipeline.

Why Qlik Cloud Analytics Gets This Right

Qlik Cloud Analytics fits the Pragmatic Mesh model so well because of three architectural decisions that happen to align with exactly what a small, autonomous domain team needs.

1. The Associative Engine: Exploration Without Pre-Planning
Most BI platforms are query-based. You define what question you want to answer, build the query or the model to answer it, and get the result. This works well when the questions are stable and known in advance. It works poorly when the business is trying to understand something it does not fully know how to ask yet, which is most of the time.

Qlik’s associative engine holds the entire dataset in memory and tracks relationships across all fields simultaneously. When the marketing analyst selects a single campaign in a chart, every other visualization on the screen updates to reflect what is associated and what is not, without her having to write a filter or rebuild a query. Furthermore, this automatically extends to all available data fields, so she can follow a thread of interest across the data without knowing in advance where it leads, and without having to specify all the required drill-down paths in advance when developing a dashboard.

For a domain team co-creating with a business expert, this is significant. The team can explore the data interactively during the development session itself, catching incorrect joins, missing data, or unexpected patterns in real time instead of waiting for 2 week springs. The feedback loop that matters most, the one between the data model and the business expert’s intuition about whether the numbers make sense, closes during development, not after deployment.

Back to the marketing analyst. With Qlik, she and a domain developer go through a new requirement on Tuesday morning. By afternoon, the developer has loaded the CRM data, the ad platform exports, and the finance reconciliation sheet directly into the Qlik associative engine. She clicks through it, spots that the CRM is attributing some paid social conversions to organic search, and explains why. He fixes the attribution logic on the spot and she quickly validates the corrected numbers. By Wednesday afternoon, they have a governed, shareable app. The board presentation on Friday uses defensible data. No tickets. No sprint planning. No three-week wait.

2. The Load Script: Transparency That Builds Trust and Enables Rapid Iteration

One of the persistent problems with self-service BI tools is that they make it easy to produce numbers but hard to understand where the numbers come from. A drag-and-drop report can look authoritative while quietly producing nonsense because of an unnoticed join issue or a filter applied three screens back. When a stakeholder challenges the number, the analyst often cannot trace it back through the visual interface to show all the relevant steps of the data pipeline.

Qlik’s load script is a first-class citizen of the development experience. Every transformation, every join, every business rule is written explicitly in readable script that sits within the Qlik application. When a CFO asks how the revenue figure of a new business unit was calculated, the developer can show the exact logic in two minutes. When a new team member joins the domain, they read the script and understand the model. When something breaks, the script tells you where.

Although powerful, it doesn’t mean that all data pipelines for Qlik applications need to be handled entirely in its load script. Especially when using more mature data products, most of the business logic can be maintained in a separate data layer independent of any single Qlik application. However, it is a tremendous advantage to be able to iterate quickly the entire data pipeline defined in a Qlik load script when business logic is still uncertain and requires rapid learning by trial and error.

3. Managed Cloud Infrastructure: The Overhead That Disappears

Qlik Cloud is a fully managed SaaS platform. There are no servers to configure, no Kubernetes clusters to maintain, no storage tiers to optimize. The domain team connects their data sources, writes their load script, builds the UI, and publishes it. The infrastructure that makes all that possible is fully maintained by Qlik.

For a small domain team, this is not a minor convenience. Infrastructure management is one of the most common reasons a domain team grows beyond the size where it remains effective. The moment you need someone to look after your compute environment, you have added a role that is not about the business domain at all. That person is focused on uptime, not outcomes. Their work is necessary but it is not the work the team exists to do.
Qlik’s access rights framework makes it easy to provide each team with its own work spaces, totally independent of each other in terms of federated management of data, user permissions and compute resources. This makes it safe to give full autonomy to each team without a risk of unintended consequences that would affect resources not owned by said team.

The Full-Stack Data Developer: One Person, End to End

Together the aforementioned three capabilities produce something that most analytics platforms cannot: a credible path to full-stack data development by a single non-techie person.

In the traditional analytics stack, you need at minimum these roles: a data engineer to build and maintain the data pipeline, a data modeller or analyst to structure the data for analysis (e.g. create a data mart), and a BI developer to build the reports and dashboards. These require genuinely different skills, and in a complex enterprise environment with custom infrastructure, they often require different people. But much of that specialization is a consequence of platform complexity, not of the business problem being solved.

When the infrastructure manages itself, and when the data loading, transformation, modelling, and visualization all happen within a single coherent environment, the cognitive load drops to the point where one capable person can own the entire stack. Not because they are a superhero hacker, but because the stack is no longer artificially divided by tooling boundaries.

In the Pragmatic Mesh model, this person is the full-stack data developer: embedded in the domain, co-creating with the business, owning the logic from source to insight. They write the load script that pulls the data. They build the associative model that structures it. They design the app that makes it explorable. And when the CFO asks how the number was calculated, they can explain the full data pipeline in two minutes.
In the Pragmatic Mesh, the full-stack data developer is not a legendary superhero hacker. They are what naturally happens when the platform stops creating artificial specialization.

What This Is Not

This is a good moment to be clear about two things the Pragmatic Mesh model with Qlik is not.
It is not a replacement for enterprise data infrastructure. Large organizations will still have shared data platforms and cross-domain analytical requirements that need coordinated engineering effort. Part 4 is specifically about how domain-owned Qlik applications connect to the wider enterprise data ecosystem through open standards.

It is not a way to avoid governance. The argument has never been that small autonomous teams should operate without oversight. It is that governance works better when it is designed for the team rather than imposed on them. Part 5 covers four practical governance rituals that work specifically because they are lightweight enough for a small team to maintain without a dedicated governance function. What we are eliminating is governance theater that is more concerned about procedures than business impact.

The Honest Assessment

Qlik is not the only platform that can support small, autonomous domain teams. Thoughtful implementations on other platforms can achieve similar outcomes with more custom engineering work. What Qlik offers is that these outcomes are closer to the default experience rather than the result of significant platform customization.

There are genuine trade-offs to acknowledge. Qlik’s load script language has a learning curve for developers coming from SQL-first environments. The associative engine, while powerful for exploration, behaves differently from the query based models that many data teams are accustomed to, and that difference requires time to internalize. For teams with very large data volumes or real-time data streaming requirements, the architecture will eventually need to evolve beyond what a Qlik load script handles natively.
Part 4 addresses that last point directly. It is about how a domain team that starts with Qlik Cloud for fast iteration does not paint itself into a corner as the organization’s data maturity grows.

COMING UP IN THIS SERIES
Part 4: The Parquet handoff: how domain-owned Qlik applications connect to the enterprise data ecosystem through open standards, and why starting small does not mean staying small.
Part 5: Four governance rituals that work precisely because they are lightweight enough for a small team to maintain without a dedicated governance function.

The strategic advice is cheap. The execution is everything. That is why the platform enabling small autonomous teams matters.

There is a word that appears in almost every data strategy document written in the last decade. Ownership. Business ownership of data. Domain ownership. Outcome ownership. It has become so familiar it has almost lost its meaning.

But when you look at the organizations that actually execute well on data, the ones where insights reach decisions in days rather than quarters, something specific is true. Ownership is not a policy they have declared. It is a condition they have created. And that condition turns out to have a well-established scientific foundation.

What Behavioural Science Has Been Telling Us Since 2009

In his 2009 book Drive, Daniel Pink synthesized decades of behavioural research into a conclusion that was simultaneously obvious and ignored by most large organizations: for complex, creative work, the traditional management toolkit of rewards and penalties actively destroys the motivation it is meant to produce.

Drawing on Edward Deci and Richard Ryan’s Self-Determination Theory, Pink identified three conditions that drive genuine high performance in knowledge work: Autonomy, the desire to be self-directed and in control of how and with whom you work; Mastery, the compounding drive to get better at something that matters; and Purpose, the experience of doing work in service of something larger than the task itself.
Data and analytics work is exactly the kind of complex, contextual, judgment-heavy work Pink was describing. Yet most data organizations are still managed with the extrinsic toolkit: JIRA tickets, SLAs, burndown charts and project budgets. Then we wonder why talented people stop caring whether their deliverables have any real impact.

What Pink described at the level of individual motivation, strong data ownership requires at the structural level, but the similarities are striking.
The Three Structural Conditions of Strong Ownership

Pink’s three elements of intrinsic motivation translate directly into three structural conditions that a domain team either has or does not have. The difference between having ownership only in title or in practice depends on whether all three are genuinely present.
Authority (Pink’s Autonomy, made structural)

Pink’s autonomy covers four dimensions: what you work on, when you work on it, how you approach it, and who you work with. In a data context, this translates into two concrete requirements that organizations consistently grant the appearance of while withholding the substance.
The first is decision rights: the actual authority to decide what gets built, in what order, and when it is good enough to ship. Not the responsibility to execute someone else’s roadmap, but the power to set the direction. Without this, ownership is accountability without agency, which is a polite description of a demoralizing situation.

The second, and the one most often overlooked, is control over implementation resources: a dedicated, stable developer who is accountable to the domain, not to a central IT resource manager. This is where Pink’s team dimension of autonomy becomes structural. A domain team that shares a developer pool with seven other teams does not have authority. They have a prioritization problem with extra steps. And when the developer rotates every quarter, institutional knowledge drains away with every handover. The team may own the roadmap on paper while the expertise that could execute it lives nowhere.

Give a team responsibility without authority or implementation resources, and you have not created ownership. You have created a scapegoat.

Understanding (Pink’s Mastery, made domain-specific)

Pink’s mastery is the compounding drive to get better at something that matters, culminating in what psychologist Mihaly Csikszentmihalyi called flow: the state of complete absorption in work that is neither too easy nor too hard. In data work, mastery has a specific and often missed requirement: it must accumulate within a domain, not just within a technical discipline.

A data architect can have technical mastery of DBT and lakehouses but very little understanding of the ERP system and business processes they are modelling. Understanding, in the sense that makes ownership real, means deep contextual knowledge: knowing what a spike in a process control chart actually signals in this business, which data fields are trustworthy and which are artefacts of a system migration three years ago, which seasonal patterns are meaningful and which are noise. This knowledge cannot be documented into a data dictionary. It lives in people who have been close to the same domain for long enough to develop genuine fluency.

Rotating developers do not just lose technical continuity. They structurally prevent mastery from forming. They are permanently in the orientation phase, which is the least productive and least motivating place to be, for both the developer and the business they are serving.
Motivation (Pink’s Purpose, made tangible)

Pink’s purpose is the experience of doing work in service of something larger than the task itself. This is not manufactured by a motivational poster or a town hall about company values. It emerges from proximity to consequence.

When a developer can see the board presentation that used the analysis they built, or hears directly from a sales director that a segmentation model changed how the team approached a key account, the connection between effort and impact is visceral. That connection is what Pink identifies as the most powerful and most durable driver of high performance in knowledge work.

Conversely, a data engineer closing tickets in a central data team is operating in what Pink calls a Type X environment: one driven by extrinsic rewards, where the primary signal of success is task completion rather than business impact. Type X environments work reasonably well for routine, repetitive work. Pink’s research is unambiguous that they are counterproductive for the complex, contextual, judgment-heavy work that good analytics development requires. We have been organizing data teams using the wrong motivational model, then expressing surprise when the results are mediocre.
Why Centralized Teams Fail All Three Conditions

A centralized IT data team, however skilled and well-intentioned, is structurally set up to fail at least two of these three conditions, and usually all three.

On authority: centralized teams have technical decision rights but almost none over business priorities. They can build what is asked of them but cannot decide what should be built or when it is good enough to ship. And because developers are shared across domains, no single team gets the dedicated implementation capacity that genuine authority requires.

On understanding: a team serving fifteen different business domains simultaneously cannot develop genuine depth in any of them. They learn the data model. They do not learn the business. The result is technically correct data products that answer the wrong questions, slowly.

On motivation: when a data engineer is three stakeholders removed from the decision their work enables, the feedback loop is too long and too indirect to sustain real engagement. The work becomes about closing tickets, not improving the business. Furthermore, as IT only owns the costs and risks and not the business benefits, their natural focus is safety rather than betting on growth.

This is not a criticism of the people in those teams. It is a structural observation. Put it in Pink’s terms: centralized data teams are structurally Type X environments. The people are not the problem. The missing incentives and feedback loop is.
Comparison between Data Warehouse, Data Mesh and Pragmatic Mesh:

Most organizations don’t have the skill and resources to properly execute the Data Mesh playbook, that is why we need a simplified and humanized version of it ie. the Pragmatic Mesh.

The Insight That Changes the Engineering Calculus

Here is a practical observation that gets buried in most Data Mesh discussions but should be front and center: in most organizations, roughly 95% of data never actually needs to leave its home domain.

The Marketing team’s campaign performance data is primarily consumed by Marketing. Finance’s revenue reconciliation data is primarily consumed by Finance. The genuinely cross-domain analytical questions, the ones that require joining customer data with sales data with logistics data, are important, but they are a fraction of the total analytical workload.

This matters enormously for architecture. It means the vast majority of a domain team’s work does not require sophisticated enterprise-wide mesh infrastructure. They need a clean, reliable, well-governed environment they control. The cross-domain sharing problem, which is what most of the Data Mesh engineering complexity is designed to solve, is actually a secondary problem for most teams on most days. The architecture should solve for the 95% first and handle the 5% as a deliberate integration layer.

We have been building highways to solve a neighbourhood traffic problem. Most of the journeys are local.

Co-Creation: Where Knowledge Transfers and Relatedness Takes Root
There is one more structural shift that separates the teams that deliver real impact from the ones that produce beautifully architected but rarely used data products. It is how the work gets done, not just who does it.

Traditional data projects operate on a waterfall handoff model. A business analyst writes a requirements document. A data engineer builds to the spec. Three months later, the analyst looks at the output and explains why it is not what they meant. The mismatch is not incompetence. It is an information transfer problem: you cannot write down tacit knowledge in a requirements document.

Co-creation means the person who understands the business question and the person building the data model work side by side, iterating in real time. When a number looks wrong, the business expert says so immediately and explains why. When a data structure is technically impossible, the developer proposes an alternative on the spot. The feedback loop collapses from weeks to hours.

This only works when the developer is stable and embedded. A rotating developer who joins the sprint, builds to specification, and moves on cannot co-create. They can execute. Co-creation requires enough accumulated context to push back, to ask the question behind the question, to know which shortcuts will cause problems in six months. That context takes months to build and days to lose.

There is a dimension of this that goes beyond knowledge transfer. Deci and Ryan’s Self-Determination Theory identifies relatedness, genuine connection to the people you are working with and for, as a core human need in motivated, high-performing work. This is the element Pink’s framework underplays and that most discussions of data team design miss entirely. A developer who knows the business expert they are building for, who has been in the room when a decision was made and seen the consequence of a number being wrong, experiences their work differently from one who builds to a specification and moves on. That difference shows up in the questions they ask, the edge cases they anticipate, and the care they bring to the logic. It is not a soft benefit. It is a quality mechanism.

Co-creation is not just a knowledge-transfer mechanism. It is what makes the work feel worth doing at the level of human motivation.

The Platform Is the Team Size Constraint
Everything argued above depends on keeping the domain team small. A small team maintains shared context. A small team makes fast decisions. A small team co-creates without coordination overhead. The moment a team grows beyond four people, the dynamics start to shift. Processes appear. Handoffs appear. The backlog appears.

And here is the constraint: a team can only stay small if one person can do what previously required three specialists. If the analytics platform requires a dedicated data engineer to manage infrastructure, a separate developer to write transformations, and a BI analyst to build reports, together with a business owner, you have a minimum viable team of four before you have shipped anything. Add more stakeholders and you quickly also need a dedicated project manager or scrum master, growing to a size that requires separate budget and project stage gate approvals.

The data platform is not a nice-to-have. It is the load-bearing wall of the entire model, but its function is not measured by its grandiosity of covering all possible real-time IoT and Big Data requirements. Instead, the simplest possible platform that abstracts away infrastructure complexity, shortens the feedback loop between data and insight, and allows one capable person to own the full stack from raw data ingestion to dashboard is what makes a team of two or three genuinely viable.

The right platform should not add any unnecessary complexity. Instead, it removes the ceiling on how fast your team can be by keeping it small.

What This Actually Looks Like

A well-functioning small domain team in a large organization is embedded in a business domain, not reporting to an IT department. It owns the data pipeline from source to decision, not just one layer of it. It has a dedicated, stable developer who knows the domain well enough to push back. It is measured on business outcomes, not technical deliverables. It can ship a working data product in days and change direction the following week without filing a formal change request.

The best software product teams have operated this way for years. Small, cross-functional, embedded, autonomous. The data world has been slow to follow, not because the model is wrong, but because two things got in the way: platforms that required specialist engineering skills to operate, and organizational cultures that confused central control with governance. The first of those obstacles is genuinely falling away. The second requires courage more than technology.

In Part 3, we tackle the platform question directly, with a specific argument and a specific recommendation.

COMING UP IN THIS SERIES
Part 3: How Qlik Cloud Analytics breaks the engineering bottleneck and lets your team focus on business logic instead of infrastructure and governance processes.
Part 4: How to escape data silos while doing fast domain owned data iteration without a data lakehouse?
Part 5: Four lean governance rituals that bulletproof your data products without complicated software or bureaucracy.
Ensuring strong ownership is the only data strategy you need.

Written by GOODIN’s BI LEAD – Phuoc Tran Minh

If you work in data and analytics, you are used to the whiplash. Every few years, the industry promises a new architectural silver bullet that will finally solve the reporting backlogs, the data quality nightmares, and the governance headaches. Recently, that silver bullet has been Data Mesh.

I will be the first to admit I have been a strong advocate for it. The core promise of shifting data ownership away from a centralized IT bottleneck and putting it directly in the hands of the business sounded like the exact antidote large organizations desperately needed. And intellectually, it still does.

But after watching these implementations unfold in the real world, we need a serious reality check.

The War Story Nobody Publishes

I have watched some of the largest companies in the world, flagship enterprises, household names, fail at this problem repeatedly. Not once. Repeatedly. The pattern is almost identical every time.

They invest heavily in a centralized Data Warehouse. The project runs 18 months over schedule. By the time it delivers, half the business requirements have changed. The central data team, talented as they are, becomes a permanent bottleneck. They understand the technology but not the business, and every new report request joins a queue that never clears. The business loses patience and starts building its own analytics in spreadsheets, local databases, and disconnected BI tools. Shadow IT blooms.

Here is the part that rarely gets said out loud: most of these organizations do not actually choose between the two bad options. They end up with both simultaneously. A stagnating, increasingly outdated Data Warehouse on one side, and a sprawling mess of shadow self-service analytics on the other. They are paying for the warehouse they cannot retire and suffering the chaos of the self-service sprawl they cannot govern. The worst of both worlds, billed as a strategy.

When it fails, the instinct is to blame the technology or the consultant. Never the model itself.

The BI Manager’s Dilemma: both choices end in pain.

The Numbers Are Damning, Across the Board

The failure of centralized data platforms is not anecdotal. Gartner, IDC, and Forrester have consistently placed the failure or underperformance rate of traditional Data Warehouse initiatives at somewhere between 50% and 80% over the last fifteen years. The specific number varies by study and definition of failure, but the directional truth has been stubbornly consistent: most of these projects do not deliver their intended ROI.

The unsettling part? The decentralized alternative is not faring much better. Zhamak Dehghani first published the concept of Data Mesh already in May 2019 to much acclaim, but very few successful implementations have since emerged. In 2022, Gartner predicted that Data Mesh may become obsolete before reaching full maturity, and estimated that only 18% of organizations have the necessary governance maturity to successfully adopt Data Mesh architecture. Unfortunately, these estimates still seem highly accurate.

Two Books, One Argument

The industry’s frustration has recently found a voice in two very different books worth naming directly.

Martyn Jones’ F*CK DATA MESH says the quiet part loud. The title alone captures the mounting exhaustion with architectures full of grand theory about domain sovereignty that collapse the moment they meet an actual organization. The sentiment is valid. Data Mesh implementations have frequently produced fragmented, expensive messes that delivered less than the warehouses they were meant to replace.

At the other end of the conversation, Phil Le-Brun and Jana Werner’s The Octopus Organization, a recent Harvard Business Review publication, offers a compelling biological metaphor for what a genuinely decentralized, high-performing organization looks like: distributed intelligence at the edges, fast local decision-making, coordinated but not controlled from the center. It is a useful model, and one worth keeping in mind. But it is also a model that assumes the organizational foundations are already in place to support it.

Both books are participating in the same conversation: what does genuine, functional decentralization actually look like, and why does it keep failing in practice?

The Problem Is Not the Vision. It Is the Execution Trap.

Here is the reality CIOs must face head-on: the core principle of Data Mesh, business ownership of data, is fundamentally correct. Gartner’s recent CIO Agenda research is unambiguous on this point: the organizations winning at digital delivery are the ones with genuine business ownership of technology outcomes, not the ones that kept everything inside a central IT function.

The vision is not wrong. But the enterprise execution of it has been a disaster, for a specific and diagnosable reason.

Data Mesh implementations typically fail because they confuse organizational autonomy with infrastructure engineering. By asking business domains to take ownership of their data products, companies inadvertently require business analysts to master Git repositories, YAML configurations, dbt transformations, and CI/CD deployment pipelines just to publish a clean dataset. The autonomy on offer turns out to be an engineering curriculum in disguise.

Business units do not have the technical skills, the budget, or frankly the incentive to become software engineering teams. The result is anxiety, stalled adoption, soaring cloud costs, and, ironically, a new generation of exactly the same shadow IT silos the whole exercise was supposed to eliminate.

We gave domains the responsibility without giving them the means to carry it. That is not decentralization. That is delegation of blame.

The Question We Actually Need to Answer

So we are stuck. Going back to the centralized Data Warehouse means burying every request in an IT backlog and watching the business work around you. Pressing forward with a full Enterprise Data Mesh means handing business analysts an engineering toolkit they cannot use and watching the whole thing fragment.

The question is not which of these two paths to choose. It is how to escape the false choice entirely.

That is what this series is about. The argument is for a pragmatic middle path, one that keeps the principle of business ownership intact while stripping away the engineering complexity that has been killing it in practice. And by Part 3, we get specific about the technology that makes it executable.

COMING UP IN THIS SERIES
Part 2: Why real agility and ownership requires authority, understanding, and motivation, and why small business-driven teams are the only structure that delivers all three.
Part 3: How Qlik Cloud Analytics breaks the engineering bottleneck and lets your team focus on business logic instead of infrastructure and governance processes.
Part 4: How to escape data silos while doing fast domain owned data iteration without a data lakehouse?
Part 5: Four lean governance rituals that bulletproof your data products without complicated software or bureaucracy.

The era of the IT-driven rigid data factory is ending. But the era of the over-engineered, under-delivered Data Mesh needs to end with it.

Mikon reaktio oli erityisen kiinnostava – hänelle nämä ominaisuudet
tuovat mieleen jotain hyvin tuttua.

“Tämähän on kuin 2018 – mutta parempi”

– Mikon tarina Podium Datasta. Mikko on pitkän linjan #Qlik-veteraani, ja kun hän ensimmäistä kertaa näki
uudet Data Products -ominaisuudet, hän hymyili tunnistavan hymyn.

Vuonna 2018 Qlik hankki yrityksen nimeltä Podium Data, ja Mikolla on siitä
omakohtainen kokemus – hän ehti työskennellä kyseisen tuotteen kanssa
ennen kuin se integroitiin Qlikin tuoteperheeseen nimellä Qlik Catalog.

Qlik Catalogin ydinajatus oli ratkaista se ikuinen ongelma: tekniset ihmiset ja
liiketoiminta ihmiset puhuvat samoista asioista eri kielillä. Mitä tarkoittaa
“asiakas”? Entä “tuote”? Catalogin avulla sekä data-ammattilaiset että
liiketoiminta ihmiset saattoivat määritellä ja arvioida käsitteitä samassa
paikassa – yhdessä. Mikon mukaan ajatus oli oikea ja tuote toimi, mutta oli
käyttäjän näkökulmasta kenties hieman tekninen. Visio oli aikaansa edellä.

Nyt visio alkaa näyttää todelta

Kun kävimme Mikon kanssa läpi Qlikin uusimpia julkaisuja, tunnelma oli selvä:
tämä on sitä, mitä 2018 tavoiteltiin – vihdoin kypsänä muotona.

Kolme asiaa erottuu erityisesti:

• Data saadaan kaikkien näkyville – Data Marketplace toimii yhtenä
ikkunana organisaation datoihin.
• Datan laatu selviää – Trust Score kertoo selkeästi, kuinka luotettavaa
data on. Ei enää arvailua.
• Dataa voidaan helposti jakaa eteenpäin – REST- tai OData-
connectorin kautta data liikkuu sujuvasti jatkokäyttöön.

Ja parasta kaikessa? Kaikki tämä löytyy yhdestä käyttöliittymästä: olennaiset
datatuotteet, niiden laatu, missä niitä käytetään, mistä data on peräisin ja
minne se kulkee – Data Lineage kertoo koko tarinan.

Miksi tämä on tärkeää juuri nyt?

Data ei ole enää vain raportoinnin raaka-aine. Kun tekoäly ja AI-agentit
hyödyntävät dataa yhä enemmän, datan laatu, löydettävyys ja luotettavuus
nousevat aivan uuteen arvoon. Jos AI saa syötteekseen huonoa tai
väärinymmärrettyä dataa, seuraukset voivat olla vakavia.

Qlik Cloudin uudet ominaisuudet vastaavat juuri tähän tarpeeseen. Kun
datatuotteet on määritelty selkeästi, niiden laatu on arvioitu ja ne ovat helposti
saatavilla – niin ihmisille kuin koneille – ollaan oikeasti valmiita tekoälyaikaan.

Yhteenvetona voinee todeta: hyvät ideat löytävät aikansa!

Podium Datan visio oli oikeassa. Se syntyi vain hieman ennen aikojaan. Nyt
teknologia, markkinat ja tarve ovat kohdanneet – ja Qlik Cloud vie tätä
kehitystä eteenpäin tavalla, joka saa kokeneenkin Qlik-ammattilaisen
hymyilemään. Mikolle se on selvästi palkitseva hetki.
Seuraamme kehitystä innolla Mikon kanssa ja autamme asiakkaitamme
Goodinilla ottamaan nämä mahdollisuudet käyttöön.

Terkuin, Mats (von Hertzen), GOODINilta

Kiinnostuitko? Laita meille viestiä!

2024 was a defining milestone for Qlik, as highlighted in our previous review by our Business Intelligence Lead and Managing Partner, Phuoc Tran Minh, in early 2025. Strategic goals were met, and the integration of Talend solidified Qlik’s position as the market’s most robust data integration platform.

But what lies ahead? 2025 and the beginning of 2026 have marked a fundamental shift in the ecosystem: moving from passive reporting to active, “agentic” analytics. Here are the key innovations shaping the daily operations of Qlik users right now.

1. From Assistant to Agent: The Rise of Agentic AI

If 2024 was the year of experimenting with Generative AI, 2025 was the breakthrough year for Agentic AI. Qlik no longer simply answers questions; it takes action.

These new AI agents execute complex sequences of tasks autonomously. They can detect an anomaly in sales data, analyse the root cause by comparing multiple data sources, and automatically generate a proposal for next steps – all without the user needing to build a query. Qlik Answers is pivotal here, integrating unstructured data (contracts, manuals, PDFs) into the analysis to ensure a true 360-degree view of the organisation.

2. Qlik Trust Score™: AI is Only as Good as Its Data

The biggest barrier to AI adoption is a lack of confidence as we know at GOODIN. Qlik addresses this with the Qlik Trust Score for AI, which automatically scores the reliability of data. As businesses build their own custom models on top of Qlik, the Trust Score ensures that AI does not draw conclusions based on flawed or outdated information. It is the “green light” management needs for automated, defendable decision-making.

3. The February 2026 Breakthrough: The Qlik MCP Server

The most significant update in early 2026 is the general availability of the Qlik MCP (Model Context Protocol) Server. This is a game-changer for AI Interoperability.

Rather than locking your data inside a single platform, MCP acts as a universal “USB-C port” for AI. It allows third-party assistants – such as Anthropic Claude, Microsoft Copilot, or your own internal LLMs – to securely “reach into” Qlik’s engine. This means your external AI tools can use Qlik’s governed measures and logic to provide answers that are actually accurate and grounded in your business reality. Here is more info!

“Qlik has gone so far beyond visualisations and dashboards: it has become the trusted intelligence layer for your entire enterprise AI ecosystem.”

Says Phuoc Tran Minh

4. Next-Level Integration: The Open Lakehouse

The Qlik-Talend merger has matured into a seamless Open Lakehouse architecture. In 2026, there is a massive emphasis on real-time data movement across Snowflake, Databricks, and AWS. Native support for the Apache Iceberg format allows enterprises to store vast quantities of data cost-effectively while avoiding vendor lock-in. Data quality is now managed by AI-assisted tools that rectify errors automatically as data moves through your pipelines.

5. User Experience: Beyond the Dashboard

Analytics visualisation has undergone a significant makeover to drive operations, not just viewing: Write-back Capabilities: Users can now modify or input data directly from a Qlik sheet back into source systems (like CRMs or ERPs). Discovery Agents: New “always-on” agents monitor your metrics 24/7 and proactively alert you to meaningful trends or anomalies before you even open a dashboard.

Conversational Interface: Interacting with data through natural language is now the standard. The dashboard has evolved from a primary interface into a supporting visual for deeper context.

Towards Autonomous Analytics

At GOODIN, we have followed Qlik’s journey closely, and the direction is clear: analytics is shifting from the “rear-view mirror” to real-time operational guidance. The Qlik MCP capabilities added in late February 2026 represent a “safe harbour” moment – providing a standardised, governed way to connect any AI tool to your most valuable data.

“The innovations of 2025–2026 represent a new era where data is a company’s most active asset. Agentic capabilities are already delivering massive value to end-users by automating the “boring” parts of data analysis and focusing on what matters: action.”

says Mikko Kuusela.

Is your organisation ready to leverage Qlik’s latest Agentic and MCP capabilities? At GOODIN, we help you translate technology into measurable business value and can train your entire organisation to make use of data and AI.

Reach out to our CEO Jarmo Rajala or Mikko Kuusela, Petri Viljanen, or Siru Saaristo. We are happy to help you find better ways to get the most out of your data and AI!

Our Business Development Lead Mikko Kuusela has worked in analytics for nearly three decades. This is the story of what he learned – and why one question stayed with him the entire journey.

Mikko has a habit of saying that his career has become more technical than he ever imagined as a young economics student.
But perhaps that’s exactly why he has held so firmly to one core idea. The most important job of technology is not to look complex. Its job is to help people succeed.

Where it all began

The year is 1997. Mikko starts his career at BasWare, working with budgeting and forecasting systems. Oracle consulting follows, then reporting, then business. Early on, a conviction takes shape that never changes:

The best solutions do not emerge on technology’s terms. They emerge when technology genuinely serves the business – with people at the centre.
In 2005, Mikko returns to BasWare and encounters QlikView. It changes his thinking. It is no longer just about reporting, but about analytics: the opportunity to understand the business more deeply, to spot patterns, to make better decisions.

#Qlik technology has been part of his career ever since. Around 20 years in total, more than 15 of them with Qlik directly.

The question that never went away

Alongside everything he learned, one thing kept nagging at Mikko. What if data entry could live in the same interface?
If viewing, analysing, and updating information could all happen in one place, a solution like that would serve the business in an entirely different way. No separate Excel files. No system-hopping. No unnecessary intermediate steps.

It’s a question he has heard from clients over the years countless times, too.

The answer arrived six months ago.

About six months ago, Mikko came across #Inphinity. He was immediately excited.

Inphinity enables data entry directly within Qlik – in the same interface where data is also analysed. No more separate processes, no more separate systems. One environment, one whole.

The concrete impact was visible quickly. In a client project, key metrics from around 50 companies were brought together into a single Qlik environment. Data entry, review, and utilisation – all in one place. It worked.

Why this matters – from a data empathy perspective

At GOODIN, we talk about data empathy. It simply means that data and solutions are not built for systems – they are built for people. Understanding users’ day-to-day reality and understanding what stories the data tells. Understanding the genuine needs of the business. Building something people will actually use.

When the process feels natural, users trust the data. When users trust the data, the organisation makes better decisions.
That is exactly what Inphinity delivers – and exactly what Mikko’s story is about.

30 years in analytics creates a certain level of #DataEmpathy

“The job of technology is not to look complex. It’s job is to help people succeed.” — Mikko Kuusela, GOODIN

#GoodIn #DataEmpathy #Qlik #Inphinity #Analytics #PeopleOverProcesses

1. Half still have no real touchpoint

Around 50% of participants have never opened an LLM before the course. This isn’t about the technology—it’s about caution, uncertainty, and the lack of guidance. Once people start experimenting in a supported environment, the hesitation fades quickly. Many express the same thought: “I didn’t know what I was supposed to ask, so I didn’t dare to start.”

2. Usage falls into three clear levels

Among those with at least some experience, usage forms a consistent three-tier structure:

• 90% use LLMs very lightly: translations, summaries, and simple edits.
• 10% use them more actively, but still at a surface level. Few users actually use frameworks, build consistent logic, or design workflows around the model.
• Deep usage is extremely rare.
  • Custom GPTs, structured tools, and process-level thinking are still marginal.

This pattern repeats across almost every organisation.

3. Agents generate interest – but they are not simple

Agents and custom GPTs now come up in almost every discussion compared to early 2025. Interest is strong, but real hands-on work is still limited. Across our training groups:

• About 50 people have built a custom GPT.
• About 20 people have built an agent (usually as a team).

Building an agent isn’t a “just do it” button. It requires quiet technical intuition, process thinking, and a willingness to experiment. Many are only now developing these foundational skills. This is why claims that “2025 is the year of agents” is more about marketing than reality. The real “agent year” in everyday work is likely closer to be realised end of 2026–2027.

4. Understanding is rising quickly – usage more slowly

Between January and November, the change is clear:

• People now better understand what LLMs do and don’t do.
• They recognise the importance of context.
• The model is seen more as a conversation partner, not just a text machine.

Yet everyday use is still largely task by task, not a continuous partnership with the model.

5. The “sparring partner” mindset works

One of the strongest findings relates to mindset. When the model is seen as a sparring partner, usage becomes more natural and relaxed. In our courses our mission, which is stated at the start of the course, is to make LLMs your sparring partner. At the end we ask how we succeeded and the results are striking:

• 95% of participants respond to our feedback survey.
• Of those, 97% say the model became a sparring partner during the course (N=1000).

Once people understand how an LLM works and where its limits lie, their usage becomes instinctive. The barrier isn’t technical—it’s emotional.

6. The biggest shift is in thinking, not yet in routines

The most notable change in 2025 is not what people do with LLMs. It is that more and more people understand what an LLM is, what it can be used for, and how it should be used. This unlocks internal conversations, role clarity, and new ways of dividing work.

And the one fact: The term “Artificial Intelligence” as a singular is the most misguiding term and should be completely abolished to create better understanding.

What does this tell us about Finnish organisations in 2025?

Based on everything we’ve seen in our training data, the situation looks like this:

🙌 Interest is growing relatively fast, but not like we inside the “AI bubble” think.

🙌 Usage is growing slowly—especially if the emotional barrier isn’t lifted.

🙌 Deep usage is still rare. People think this is a new Google, and naturally that will limit exploration as what you do with Google is already a habit—and as we know habits are hardest to change.

Finland is now in a phase where understanding is expanding, but everyday AI-Human working habits are still forming. This is a natural stage—and right now is the ideal moment for organisations to build their LLM strategy before the next major shift arrives.