Proposals for a bridge connecting Manhattan and Brooklyn existed as early as the 1800s. For decades, the ferries were fine, so nobody committed. It took a German immigrant engineer named John Roebling getting his ferry stuck in East River ice in 1852 to produce someone with enough frustration and vision to stop proposing and start designing. Even then it took fifteen more years to get legislative approval. The bridge finally opened in 1883. The cities had not lacked an idea. They had lacked a decision.
I spent 20 years building and running analytics platforms in a large healthcare company. The bridge story is not an analogy I chose for effect. It is what I watched happen, in slow motion, across five organizational regimes and four different BI platforms. Every team had working tools. Most of them had built something to connect those tools to the people who needed them — scripts, processes, a person who knew how it all fit together. What almost none of them had done was imagine it at the scale of the Brooklyn Bridge. A structure worth engineering from the start, worth funding as a line item, worth building to last longer than the people who built it.
I started my career as an architect, the licensed kind. Design the whole system at a human scale before you touch a component. I ended up as the person the organization called when something complicated needed to be designed across teams. Over time I saw the same needs appear in every BI operation I worked with, and very different levels of investment in solving them. That gap is what this paper is about.
I am not a consultant. I am not selling a product. What I have is a set of observations from two decades, and I am curious whether any of them look familiar to you.
Three forces create this gap. None of them are mistakes. All of them are normal.
Organizations change over time. Teams split, merge, and reorganize. Analytics problems are often solved by small business-aligned teams, and each team picks the tools that fit their immediate need. Nobody consolidates those tools on day one. Often nobody consolidates them ever.
Cognos gives way to Tableau. Tableau makes room for Power BI. Each transition takes years and the old tool never fully retires because there are always reports that aren’t worth the cost of migrating. So both tools run in parallel. Then a third shows up.
Internal employees are one population. External customers are another. Regulated data adds a layer. Multiple product lines add more. Each audience has different entitlements, different compliance requirements, and a different relationship with the content.
Each of these forces adds a tool, a user population, and a governance burden. None of them add a unifying layer.
There is a fourth force that compounds the other three. BI work attracts brilliant problem solvers. These are people who find a way to get data in front of users no matter what the tool limitations are. When the platform falls short, they build something. When the process breaks, they fix it with what they have. That resourcefulness is a genuine strength. It is also why the data access layer ends up as scripts, spreadsheets, and workarounds instead of planned architecture. The problem is rarely recognized as an architecture problem, so it rarely receives architecture-level investment. It gets solved off the side of someone’s desk, usually by the people closest to the pain, with the tools and skills they have.
Most people hear “data platform” and think about the data foundation. Ingestion, ETL, modeling, the warehouse, the lakehouse. That work is well understood and it gets real engineering investment. Above the foundation sit the BI tools: Tableau, Power BI, Cognos, whatever the organization has licensed. Mostly debated, always licensed, rarely rationalized. Above those sit the reports and dashboards: what users see and what the business funds.
Anchoring the whole stack are the source systems. They were there before any data team showed up, and they absorb most of the organization’s technology investment. Everything above them runs on what is left.
Everything above the source systems lives on what is left. The data access platform lives on what is left of what is left.
Between the data foundation and the reports there is a layer that handles how users actually get access to what has been built for them. I call it the data access platform. It includes governed metadata that controls access and defines key reporting concepts, the delivery application that manages authentication and authorization, extensions that replace native BI features lost through embedding, and the administrative tools for managing customers, users, and utilization.
When I look across the organizations I have worked with, the same five functions show up every time. The question is whether they are managed in a fully engineered platform or handled by whatever person can carve out some time to solve them.
For each one, I have described what it is, why it matters, and what I have seen happen when it is left without a plan.
One login. The customer opens a browser, signs in once, and sees their reports. They don’t know or care which tool rendered the content. That sounds simple until you have multiple BI tools, external customers on a different identity provider than your employees, and compliance requirements that differ by product line. When it works well, the customer sees your analytics as a product, not a collection of tools.
Not folder permissions. Authorization modeled around business concepts. This customer sees these product lines. This user has this role within their organization. This territory maps to these reports. Every BI tool thinks in folders, sites, and workspaces. Your business thinks in customers, products, and roles. Someone has to map one to the other, and in most organizations that mapping lives in someone’s head.
The data that makes the data make sense. Customer organizations, brands, territory-to-zip mappings. The reference data that makes a report meaningful for a specific customer. This metadata is almost always unique to the business and no generic tool manages it well. It is where implementations run into walls they did not see coming.
Those three show up in almost every BI modernization conversation. Ask yourself the harder question: does your organization have a deliberate answer to the next two, or does it have a workaround?
Who is using what, across which tools, for which customers. If you asked your organization for a single view of report usage across all your BI platforms, how long would it take to get an answer?
The ability to add, retire, or replace a BI tool without rewriting the user experience. Without this, every tool migration is a hard cutover for every user at once. With it, you can migrate incrementally, run a long tail on a legacy platform while new content moves to the replacement, and bring in custom AI tools or specialized insight applications alongside your primary BI platform as part of one unified experience.
I have seen what happens when an organization recognizes the data access layer as something worth engineering from the start. The difference is not talent. The people finding solutions in every organization I have worked with were smart and resourceful. The difference is whether the organization ever recognized this layer as architecture, or whether it stayed invisible until someone close to the problem solved it with whatever they had.
What a purpose-built data access platform provides. Same five functions, fully engineered.
There are two cost pressures that live inside this layer.
The first is operational. When an organization manages the data access layer entirely through people and manual process, it consumes time from many people just to hold it together. That overhead introduces inconsistencies, which takes more time to investigate. And it reduces adoption, because access is slow to set up and painful to change. The cost is not just headcount. It is the drag on every team that depends on the platform working cleanly.
The second is licensing cost, and this one is subtle enough that most people evaluating BI portal solutions miss it entirely. There are two fundamentally different ways to deliver BI content through a portal, and they have very different economics.
At thousands of external users, the difference is 2x to 4x per user.
Most commercial BI portal products use the catalog model. They inherit authorization from the source platforms. That means the users still need to be set up as licensed users on those platforms. You get a better experience and better governance, but you do not get the cost economics that come from true embedding. Understanding the difference before you commit to a direction matters, because at scale the licensing economics can dwarf every other cost in the platform.
Commercial BI portal vendors do exist. MetricInsights, ZenOptics, Digital Hive, and others have productized portions of the data access layer. Their existence is validation that the problem is real and recurring. The category is young and not well defined, but if you recognize the patterns described in this paper, these products are worth evaluating.
The harder truth is that most organizations have not gotten to the point of evaluating solutions because they have not named the problem. The people closest to the pain are heads-down solving it with whatever they have. The people with budget are not seeing the pain at all. The full solution crosses teams, requires a business case, and needs someone to explain why the space between the tools and the users is worth a line item. That is a hard thing to get onto a roadmap.
Bridges had been built for thousands of years when Roebling proposed his. The technology was not the barrier. His proposal sat unanswered for fifteen years. It moved when the right conditions aligned: political will, a bad enough winter, and a champion who would not let it drop. The data access layer is not a new problem. What is missing is not the solution. It is the organizational recognition that the problem exists and is worth solving.
If any of this felt familiar, you probably have the same gap I spent 20 years learning how to fill. I would be curious to hear what you have seen.