Why your data needs an org chart, and why Qlik spaces and apps already are one
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.
