Fully managed in the cloudStarburst GalaxySelf-managed anywhereStarburst Enterprise
- Start Free
Fully managed in the cloud
Collecting all business data in one location would enhance access across the company.
Yet that dream never came true. What was behind efforts to create central data stores? Why didn’t it work? And why are businesses reversing course by decentralizing their analytical architectures?
Let’s find out.
Published: July 31, 2023 | Last Updated: Aug 1, 2023 | Author: Andy Mott, MBA
Centralized data is the long-established practice of gathering all data the company generates into an enterprise database, a data warehouse, or, more recently, a data lake. This centralized repository becomes the company’s single source of truth.
Centralized data is the antithesis of distributed data. The former funnels data from every source into one location, while the latter leaves data at the source.
Centralized models grant corporate data teams authority over data management. In decentralized models, corporate groups set strategies and policies but leave data management to the lines of business (or domains).
A centralized repository is supposed to be the organization’s authoritative information source, but users must go through data teams for most requests. Decentralized systems let business users access data by requesting access from the line of business that is most familiar with the data and what the data can be used for.
In theory, centralization would improve a company’s data usage. Running everything in one place should give the company more control over inputs, costs, and outcomes. Centralized data’s theoretical benefits included:
A centralized data strategy was meant to be easier to manage. Corporate data teams controlled infrastructure initiatives, allowing them to align data storage with business processes and analytical workflows.
Consolidating data allowed enterprises to invest efficiently in technology to optimize storage and computing performance.
Rather than waiting to retrieve data from the periphery, corporate users could get their data over the company’s low-latency networks and purpose built data technology.
Corporate data teams developed the pipelines for ingesting, cleaning, and preparing data entering the centralized system. Managing pipelines in one place eliminated inefficiencies and redundancies within the data infrastructure.
With total control, IT departments could ensure the consistency of all data in the central repository. Data pipelines ingested, cleaned, and prepared data so users could trust that similar data would share standard formats, labels, and other properties.
Giving every user access to consistent data reduced the risk that conflicting data would cause poor business decisions. For example, sales and finance departments would use the same revenue metrics in their reports. Centralized organizational structures responsible for data management enabled hyper-specialization in data technologies, and these skills to be available to all lines of business.
Giving business users clean, accurate, and consistent data aligned everyone in the organization. Collaboration around actionable insights became easier when everyone used the same numbers.
In practice, centralization and its benefits were more an aspiration than a reality. Companies could never fully centralize their data storage. Business needs always demanded domain-level storage. As a result, centralized enterprises have always faced enormous challenges.
The way that finance, marketing and risk functions in a financial services organization consider a customer are fundamentally different with a different set of relevant attributes. Attempting to model the different contexts of cross domain entities in a single system is difficult and becomes more challenging with time.
Centralization was meant to bring ownership and control under one roof. However, it also created a disconnect between the application engineers creating the data, the data engineers managing the data and the lines of business consuming the data. Conflicting priorities led to inefficiencies that inhibited business growth.
Centralization also created divisions and strife between executives and their organization’s data teams. Consider what typically happened when executives needed data to support a decision:
1) Executives (or their analysts) create a data request.
2) The request joins dozens of others in the task queue.
3) Data engineers design a pipeline to fulfill the request.
4) Data engineers use the pipeline to provision data into a central location.
Even in the best-case scenario where the data was useful, it could take weeks to fulfill a decision-maker’s request — months for complex requests or when the data team was busy.
In other scenarios, the delivered data would be outdated or fail to meet the decision-maker’s expectations. Executives re-submitted their requests, demanding a better result. This request-wait-repeat cycle compromised the business in several ways.
Without infinite resources, the team allocated its limited time away from new tasks to rework failed requests. Growing backlogs worsened the data team’s support for the rest of the organization.
Decision-making became rigid, and the business became less responsive to a dynamic competitive environment. Decision-makers would find creative solutions to this problem by accessing shadow data sources. However, short-term “solutions” like this created long-term data governance problems.
One consequence of the Cycle of Doom is the creation of departmental level single sources of truth, where lines of business manage and govern data outside the purview scope of the data governance function to meet their business requirements and timelines.
True centralization never existed. Enterprise data was always distributed between the core and the periphery.
Today’s data architects recognize this reality and embrace distributed data.
Starburst empowers this decentralized strategy. Rather than struggling to create a single source of truth, companies use Starburst to give their users a single point of access to every data source.
Starburst enables lightning-fast retrieval and data analytics at scale. Building upon the open-source Trino project’s massively-parallel query engine, Starburst performance optimizations can deliver ten-to-twentyfold improvements in complex queries.
By creating a virtual data layer over a decentralized data storage infrastructure, Starburst eliminates many frustrations users experience in centralized systems.
Analysts can use the SQL tools they already know to directly access data without relying on data pipelines. This direct access lets decision-makers and analysts get the data they need without waiting for data engineers.
Since this self-serve model lets data teams spend less time on simple requests, engineers can devote more time to complex big data projects that drive business growth.
Starburst brings data to center stage by pushing complexity into the background. For example, the holistic user interface masks the complexity of integrating disparate data sources.
Starburst offers over fifty connectors to enterprise-scale data systems, from data lakes to real-time data streams. These connectors transform data in each source into Starburst catalogs, translating data types and automatically handling source-to-source variations in SQL implementations.
Abstracting the complexity of disparate data sources severs the chains binding compute and storage. Domains can decide how best to manage their data stores without impacting the rest of the organization. Data teams can optimize compute to deliver affordable performance at scale.
Modern enterprises are storing data all over the world, catching them in a tangled web of global data security, privacy, and sovereignty regulations.
ISO/IEC 27001 certified and SOC Type 2 compliant, we understand what our customers go through to meet regulatory requirements. The Starburst data lake analytics platform includes security and governance capabilities to streamline regulatory compliance.
Create fine-grained role-based authorization policies with Starburst’s built-in access controls or through connectors for Apache Ranger, Privacera, or Immuta.
Query Starburst’s activity and change logs to monitor data access, flag unusual behavior, and conduct compliance audits.
Just as enterprises never fully achieved a centralized data architecture, most companies will not fully decentralize. Data warehouses and data lake technologies will continue to be exist with data lakes continuing to grow in popularity. They will never be one-stop shops for all data, but data lakes will play a critical role in decentralized data architectures.
Using Starburst to bring data together in a lake where regulations allow and efficiencies can be exploited is a powerful capability. Data engineers can make the decision on when to build and maintain pipelines, when to integrate data and from which sources, and when to federate access to remote data sources and data lakes.
Starburst helps evolve your data infrastructure from a rigid, underperforming centralized model to a modern, distributed data mesh. Domains best understand the context and purpose of the data they generate. A mesh lets domains own data while providing a framework for sharing it with other domains.
Corporate data teams still play a role, guiding domains through high-level standards for data quality and interoperability.
By embracing the distributed architecture of a data mesh, companies can deploy a self-serve access model that empowers data-driven decision-making everywhere in the organization.
Fast, secure, and controlled access gives users the data they need to support KPIs and other business goals. By supporting better, faster decisions, Starburst creates a competitive advantage in a dynamic marketplace.
Up to $500 in usage credits included
Up to $500 in usage credits included