How applying a hub-and-spoke model to Looker expands your data governance capabilities

A Hub and Spoke model is a proven means to optimize multiple industries.

Whether referring to flight schedules or product shipments, this data architecture establishes a centralized location for resources. From there, organizations can send them to connected points for distribution.

A Hub and Spoke model can also be applied to Looker to streamline its ability to manage projects within your organization. In Looker, a project refers to the files that describe the information system and business rules making up your LookML objects. Your users need these database connections and user interface details to carry out their queries.

What Is a Looker Hub and Spoke model?

At the center, a hub project stores your high-level business logic and company-wide KPIs. You can then use this information to populate the downstream spokes across your organization.

The hub holds the critical information about your business data, including standard field definitions. These are the core building blocks of Looker’s Explores and views that make up your analytics queries. In organizations with multiple departments, these spokes access the hub’s centralized resources to assure their queries are drawn from consistent definitions.

When effectively deployed, Hub and Spoke architecture provides an additional means for Looker to keep your data reliable and secure. When it comes to your analytics needs, data that is trustworthy and governed is the only kind that matters.

A Hub and Spoke Model for Looker improves data governance

In a competitive marketplace filled with organizations harnessing the advantages of cloud technology, proper data governance is critical. In order for your business to generate useful conclusions from the full scope of its business information, all your data must be trustworthy, centralized, and consistent.

With a Hub and Spoke model, your organization gains another crucial layer of data governance. With Looker’s business logic stored in a centralized hub, the communication between its connecting spokes only travels one direction. When changes are made to your data definitions in the hub, they’re pushed down and disseminated to every spoke in your organization.

As a result, a Hub and Spoke implementation of Looker supplies an additional layer of reliability in your data by providing a single source of truth for your business.

Provide data flexibility and limit technical debt

A Hub and Spoke implementation of Looker provides additional assurance your data sources remain trusted and consistent. However, you don’t have to sacrifice flexibility. At the spoke level, parts of your organization remain free to change LookML objects or establish new definitions as needed.

Across your organization, differing departments or business units may use different logic to define revenue or sales to satisfy specific queries. For example, finance teams may use different metrics to inform their KPIs versus your sales team. With a Hub and Spoke model, these teams can implement custom changes without worrying about their impact on how other parts of your organization uses data.

This model empowers teams to augment and modify the content they inherit from the hub. Plus, a Hub and Spoke architecture provides additional safeguards against technical debt.

When teams are moving quickly and creating new reports and ways to compile data, Looker can quickly accumulate duplicate or unclear queries. As these repetitive or unnecessary files stack up, your teams lose certainty about which calculations are correct or apply to their position. As this technical debt mounts, your users lose trust in your data.

A Hub and Spoke model keeps your Looker instance free of redundancies and reduces clutter in the platform’s Explore menu. Instead of seeing multitudes of changes made by differing departments, your users see only what applies to their specific spoke within your organization.

How a gaming company draws benefits from this data model

With every user interaction ripe for analysis, the gaming industry is driven by data. However, gaming companies face considerable challenges in keeping up with their data. They need to manage and access large amounts of information, which are unstructured or semi-structured and evolving in real time.

Big Fish Games is a mobile-friendly gaming company that operates with multiple titles, studios, and platforms. Needing to manage a high volume of KPIs and multiple streams of data, the company used a Hub and Spoke model to maintain data governance while allowing for augmentation and customization within its separate groups.

Shared KPIs such as daily active users (DAU), revenue, and first runs with a game are maintained in the hub project. The hub’s engineering teams manage the company’s KPIs to ensure they remain accurate and consistent. These metrics are derived from standard ETL (extract, transfer, load) processes and drawn from the company’s canonical definitions.

The individual game studios working on the company’s separate titles comprise the spokes of the model. Each studio draws the organization’s business logic from the centralized source to populate their Looker projects. Working from a single source of truth, the teams can modify the content by hiding any files unrelated to their needs. Or, they can add their own custom data without impacting the central hub.

Permissions allow for greater control in a Hub and Spoke model

Along with supporting the needs of varying studios, a Hub and Spoke model allows Big Fish to control access to Looker projects. The data team maintaining the hub has full permissions to modify the centralized business logic within those projects, but not the projects developed for use within each spoke. Similarly, the developers at each individual game studio within the company only have access to change the projects within their spoke.

The company has the flexibility to grant developers a subset of permissions to the hub project, depending on whether a team member from a given studio needs to access a view to sync with Looker’s latest updates. However, spoke developers will not have permission to deploy changes to the hub project.

By allowing their individual teams to customize Looker to their needs, the gaming company has the flexibility to extend the reach of their business intelligence efforts. At the same time, the company retains a much-needed layer of governance that ensures every team is working from a centralized, trusted data source.

If your organization features disparate units requiring similar levels of freedom while remaining under a unified umbrella, a Hub and Spoke model may satisfy your needs.