Having led the data transformation and re-architecture of multiple enterprises such as Nike, Zendesk, AEO, Philips, and more, I’ve learned that one of the best ways to start on the data journey is to clearly map data and analytics platforms to higher-level patterns and functionality such as:
Getting data: Bringing data into the company.
Storing data: EDW, Cloud, on-premises, etc.
Moving data: Internal movement (reuse option here with “Get Data”).
Enriching data: Orchestration tools, purpose-built analytic enrichment platforms, and data science tools.
Protecting data: Entitlements services consisting of AuthN (authentication) and AuthZ (authorization).
Cataloging data: Technical and business metadata, terms and glossary, discovery, scanning, etc.
Serving data: BI/visualization, unified analytics via a semantic layer, and applications and services developed to deliver data and insights.
Every company I have worked with has a range of strengths and gaps in at least one of the areas. They most often struggle to balance maturing with delivering business impact/requests.
For example, at one Fortune 100 company, I inherited nine movement platforms. Having these multiple platforms for data movement (ingestion, loading, transformation, staging, and serving) resulted in brittle pipelines, high costs, and unnecessary complexity. Several of the platforms were for enrichment (including additional, valuable data) rather than movement, and they were not optimized to scale.
To increase efficiencies and reduce costs, the tools were analyzed and functionally compared with alternatives. This ensured that critical use cases leveraged best-in-class technologies rather than making decisions based only on individual preference. This change made the enterprise architecture less of an ivory tower and ensured data patterns easily mapped to the business’s needs.
While each of these functional areas is seeing material evolutions to the patterns and platforms that encompass them, data serving is at a tipping point.
For years, I fought against the “just give me the data” requests. Having built data product teams from the ground up, I have been teaching them to translate requests into business-level questions. They are coached to think about solving problems rather than answering tickets.
For example, “Please give me access to data from systems A, B, and C,” really meant, “Is our demand forecast accurate?” With this mindset, they become partners in solving problems with opportunities to automate solving them easier in the future. The result is faster access to the right data, a better outcome, and improvement opportunities for the data foundation.
However, the request of “just give me the data'' is evolving into a real need. In-function business teams and non-technical users alike now have easier tools for data discovery and complex analysis. There’s also decreasing demand for visualizations as they are being replaced with increased demand for building blocks such as KPIs, universal metrics, and simple natural language interfaces for self-service and machine-based workflows.
This path was foreseen by companies like Looker (via LookML) and ThoughtSpot (think of their campaign, “Dashboards are Dead”) and called out as a Gartner trend back in 2020. Unfortunately, having been a prospect and customer of these companies, the setups were too complex and they didn’t have a fast path for all enterprise data.
Data leaders have been waiting for better open-source options, consistent standards, and/or easier integration paths to emerge to decrease time-to-value, risk, and future switching costs. Thankfully, it is starting to happen.
Headless BI (“Metric Store”) for data sharing
These companies really spurred the metric store capabilities that are picking up momentum. Open source options like Metriql have emerging (via LookML team) capabilities of GenAI and have shown the scale and ease of abstracting the underlying data to make metric sharing easier.
A metric store in the context of headless Business Intelligence (BI) is a centralized repository where your organization's key performance metrics are defined, stored, and managed independently of any specific reporting or visualization tool. It acts as a single source of truth, ensuring consistency and accuracy across all departments by allowing different applications and teams to access the same metric definitions via APIs.
A user may shop for data in a catalog and/or metric store to find and access an already calculated version of the data they were considering creating. Instead of exporting data from a dashboard or building another version of a metric that already exists, users may consume the cataloged metric or branch off of it in a git-like experience. Users consume, mature, or develop a new metric as a child with the lineage and data contracts in place upstream.
This process eliminates the friction of combing through dashboards to see if any metrics needed are already developed. Moving calculations from a Business Intelligence (BI) tool to an open option naturally lowers barriers of entry, enables governance, and lowers future switching costs.
I recently spoke with the data leader of one of the largest supply chain companies in the world and we discussed a mandate he’s championing with their CEO called “No BI.” My response was that he should take two small two-to-three-person teams over two days with a basic UI and show how the world has evolved and gotten easier.
Give the teams a hackathon-style charter with a cross-functional business leader mapped to each team championing a use case (i.e. inventory health analysis scope for one and financial reporting for the other). Allow the teams to explore new patterns such as Headless BI, RAG, and GenAI, and give them the flexibility to leverage or build small and/or large language models (LLMs). Have business leaders perform the demo for the team and you will see not only improvements in the partnership and adoption, but the team will also get invaluable feedback in real-time from a senior leader.
With AI-based agents being deployed and optimized, users will continue to move up past the semantic and BI layers to natural language interfaces. The data foundation's importance is clear, but changing user interfaces makes it easier to improve. These abstraction layers enable the underlying data teams to easily stabilize, upgrade, or modernize the foundation.
Evolving patterns, though, are not guaranteed to be less expensive. The direction certainly is, so delivering against low-hanging fruit with the business will drive confidence and funding for your next steps.
Proceed with optimism and caution
Architectural changes like lakehouses, data virtualization, and iceberg standardization have improved data serving scalability and performance. Instead of dealing with movement and pipeline issues, teams can focus on optimization and quality of integrations
The data leader referenced above set a goal that every employee of that company will leverage GenAI, with an example of their security guard at a warehouse having a truck pull up that is not on the delivery schedule. Without hunting down all the people needed to verify the delivery and, if space is available, the security guard types into a chat bar that a truck with invoice number XXX is at the YYY facility and he asks if the delivery should be accepted. The functions on the backend flowed as:
Audit the invoice.
Map the assets in the truck to the facility and either verify if the delivery is appropriate or calculate that though the delivery is not on the list the facility could use, they have the inventory to meet demand.
Inventory updates are made appropriately and updates are registered across systems.
Reroute any other assets based on any changes.
Reports are avoided, as are time-consuming escalations. Rather, a simple prompt by a security guard empowers inventory optimization and real-time algorithmic adjustments flow as a result.
Stories like the above are driving material changes for enterprises. Open serving layers are changing how data is leveraged. These advancements are also enabling clearer paths to data monetization: Mapping metric stores to marketplaces introduces additional productization paths of data. Developing Apps, UIs, APIs, and more is taking over many dashboards. You should also see additional savings as premium support contracts will no longer be needed to maintain performance SLAs.
Lastly, remember to proceed with caution. Even optimized, RAG at scale is expensive today. Leveraging managed LLMs and coupling compute services is a risk just like waiting for open source options to mature. Building small language models is a way to provide efficiencies and savings while leveraging and improving smaller domains.
Being intentional about quick wins in research mode should be transparently balanced with the cost to scale. And being able to pragmatically drive efficiency, better customer experiences, and measurable outcomes with low-hanging fruit is the best way to get started. Be sure to use efficiencies and internal partnerships to self-fund the cost to experiment, learn, scale, and re-platform as commoditization and more efficient options emerge.
The future of data serving is at a tipping point. There is a clear shift from the "just give me the data" requests to more sophisticated, problem-solving approaches. Headless BI and metric stores are emerging as powerful tools for data sharing and consistency, while AI-based agents and natural language interfaces are democratizing data access.
These advancements offer exciting opportunities for enhanced decision-making and operational efficiency. However, leaders must proceed with optimism and caution, balancing innovation with cost and scalability considerations. By fostering cross-functional collaboration and focusing on quick wins that demonstrate measurable outcomes, organizations can leverage these new capabilities effectively.
Moving forward, those who successfully navigate this evolving landscape will be better positioned to extract strategic value from their data assets, gaining a competitive edge in an increasingly data-driven business world. Architectural changes have improved scalability and performance, allowing teams to focus on optimization and quality of integrations.
The future of data serving is here – it's time to embrace it, but with a pragmatic approach that balances efficiency, better customer experiences, and measurable outcomes.
About the Author:
Nik Acheson is the former Field Chief Data Officer at Dremio. Acheson is a business-obsessed data and analytics leader with deep experience leading both digital and data transformations at massive scale in complex organizations, such as Nike, Zendesk, AEO, Philips, and Concur.
Before joining Dremio, Acheson was the Chief Data Officer at Okera. He is a frequent conference speaker focusing on advanced areas of Data & Analytics, including Data Mesh, Data Fabric, Distributed Intelligence/Analytics, AI/ML & Data Science, Data Governance, Information Security, Personalization, 360 data strategy (product, customer, content, partner), and others.