Analytics and BI Roles: Who Does What on a Modern Data Team

The traditional boundaries between the various analytics and BI roles were shaped partly by the tools they worked in. Data engineers built and maintained pipelines and core data models. BI developers created reporting models and dashboards. Analysts queried that prepared data to answer business questions. Those lines were never absolute, but the handoffs were relatively visible.

Modern analytics architectures are changing the division of labor. Now, a semantic model or governed metric might support a dashboard, self-service analysis, a conversational interface and an AI agent at the same time. Logic that once belonged to a particular report or analyst workflow increasingly sits in shared infrastructure, where changes propagate across many analytical experiences.

These changes affect what organizations need from their analytics roles. Analytics engineers may take on more responsibility for business logic, BI teams may spend less time producing individual reports and more time supporting reusable analytical experiences, while data product and governance roles take on greater responsibility for definitions, access and quality. Exactly where those responsibilities land still varies by organization.

This article maps the changing division of labor: which roles typically own each part of the analytics system, where they overlap and how those boundaries are shifting as more analytical work moves into shared, governed layers.

A business intelligence (BI) team is the group responsible for turning operational data into information people use to make decisions. Its work typically spans data modeling, metric definition, reporting, dashboards, analysis and support for the people who rely on those outputs.

That function can sit almost anywhere on an org chart. Some organizations place BI under IT, others within finance or individual business units, while larger companies often bring BI together with data engineering, analytics engineering, data science and data governance inside a broader data organization.

Team size varies just as widely. A growing company might rely on one analyst to maintain executive dashboards and investigate questions from across the business; a large enterprise might distribute the same responsibilities among dozens of specialists.

Watch how Marriott built a conversational analytics experience around standardized KPIs, governed semantic models and natural-language access to trusted data:

Although titles shift from company to company and over time, four areas make up the bulk of the work: data readiness, metric definition, delivery and enablement.

Data readiness

Before someone can conduct an analysis, the underlying data needs the appropriate quality, structure and freshness. Data engineers often own upstream pipelines, while analytics engineers and analysts shape the resulting data for analytical use. Where that ownership is unclear, preparation work tends to leak downstream into one-off SQL, spreadsheets and dashboard logic.

Metric definition

Someone needs to decide exactly what active customer, net revenue, conversion rate and other metrics mean, including the filters, aggregation rules and edge cases. A single metric definition might encode decisions about time windows, joins, exclusions and business events.

This is where an unowned responsibility can cause outsized problems. If marketing, finance and product each implement revenue separately, for example, all three calculations might be technically valid yet disagree. Time is then wasted reconciling definitions every time a business question involves data from more than one domain.

Delivery

Dashboards, recurring reports, analytical applications and ad hoc analyses sit in this layer. Different roles own different pieces, depending on how the team is staffed, but each translates governed data into something people use for a decision or workflow.

Enablement

As self-service and conversational BI spread, BI teams spend more time helping people work with trusted data directly. Documentation, data literacy, stakeholder support and the design of usable analytical experiences all sit here, along with the semantic definitions and governance that help natural-language interfaces interpret business questions consistently. Rather than routing every routine question through an analyst, the team establishes the data, context and guardrails that support a wider set of users and analytical tools.

Most organizations use one of three broad operating models, each placing business context, technical expertise and shared definitions in a different location.

Centralized analytics teams

In a centralized model, analysts and BI specialists sit together and support the organization through one shared function. Centralization gives the team a natural place to maintain reusable data models, reporting standards and common metric definitions. Technical expertise is concentrated as well, which generally makes peer review, shared tooling and career development easier to coordinate.

Distance from the business creates the main trade-off. A central group serving marketing, finance, product and operations often works through a request queue, and analysts may have less day-to-day exposure to the context behind each question. As demand increases, prioritizing the queue consumes more of the team’s attention.

Metric ownership is relatively straightforward when the central group controls both definitions and reporting, although the business still needs a voice in deciding what those metrics mean.

Decentralized or embedded analytics teams

Embedded models place analysts directly inside the functions they support. A marketing analyst works alongside marketers, a product analyst sits with product teams and a finance analyst works within finance.

This proximity gives analysts richer context and often shortens the path from a business question to an analysis. Each function also has greater control over its analytical priorities.

Shared definitions require more deliberate coordination with this model. If each embedded team maintains its own logic, small implementation differences accumulate: revenue excludes a particular transaction type in one dashboard but includes it in another, or one retention metric uses a 30-day window while another uses 28 days. In that environment, metric ownership is distributed by default unless the organization explicitly centralizes it elsewhere.

Hybrid and center-of-excellence models

Hybrid structures combine a central data or analytics group with analysts embedded throughout the business. Often described as hub-and-spoke or center-of-excellence models, they split the work: the central group maintains shared infrastructure, governance and metric definitions, while embedded analysts concentrate on the questions and workflows within their functions.

The arrangement depends on a practical division of ownership. If the central team publishes standards but embedded analysts still rebuild calculations locally, the organization retains much of the definition drift associated with a decentralized model.

Governed semantic definitions soften that trade-off. When metrics live with shared data infrastructure and downstream tools reference those definitions, embedded analysts retain their business proximity without independently implementing every calculation. Organizational structure still shapes how teams collaborate, although it no longer carries the full burden of maintaining consistency.

Most analytics roles touch more than one responsibility area, but their centers of gravity differ.

On a small team, one person might cover three or four rows. In a larger organization, even a single row might represent several specialties.

Metric ownership also cuts across the categories. A finance leader might approve the definition of net revenue, an analytics engineer might encode its calculation, a BI analyst might validate its use in reporting and a governance team might establish who is permitted to modify it. Clear ownership depends on both business accountability and technical implementation.

A data analyst turns business questions into evidence, typically using SQL, spreadsheets, BI tools and statistical techniques to explore data and communicate findings. Data analysts work in central teams as well as marketing, finance, product and other functions, which helps explain why the title covers such a wide range of responsibilities.

Depending on the organization, a data analyst might own ad hoc analysis, recurring dashboards, metric validation or some combination of all three. The role frequently sits downstream of shared data preparation while working closely enough with business stakeholders to identify when a metric or data set needs clarification.

A business analyst focuses primarily on business processes, requirements and coordination between stakeholders and technical teams. Data supports that work, although ownership of analytical models or reporting infrastructure is less central.

A business intelligence analyst works directly with metrics and reporting, often developing dashboards, maintaining recurring reports and answering performance questions through a BI environment. Because BI analysts sit close to the reporting layer, they frequently help translate business definitions into usable metrics and identify inconsistencies when the same measure appears across multiple reports.

In practice, the titles often overlap. Job descriptions reveal more when they show whether the role centers on processes and requirements or analytical data and recurring metrics.

Read more about the BI analyst role >

Data science and statistics roles extend analytical work into modeling, experimentation and inference.

A data scientist applies statistical methods, machine learning and experimentation to questions such as which customers are likely to churn, how demand is likely to change or which factors help explain an observed outcome. Depending on the organization, data scientists also build features, evaluate models and collaborate with engineers on production deployment.

A statistician concentrates more heavily on sampling, experimental design, uncertainty and formal statistical inference. The title appears particularly often in research, government, healthcare and other settings where methodological rigor carries substantial operational or regulatory weight.

These roles typically consume many of the same governed data sets and business definitions used elsewhere in analytics, even when their outputs are predictive rather than descriptive. A churn model, for example, depends on an agreed definition of customer, churn and the time period used to observe it.

Several roles sit closer to the data models, reporting infrastructure and analytical platform that downstream users depend on. Their titles overlap heavily.

An analytics engineer turns raw or lightly transformed data into clean, tested and documented analytical models. The role often carries technical responsibility for reusable business logic, which puts analytics engineers close to metric implementation even when a business team owns the metric’s meaning.

A BI developer builds and maintains data models, dashboards, reporting environments and integrations associated with BI. A BI engineer usually leans further toward pipelines, query performance and platform reliability, although many organizations treat the two titles as interchangeable.

A report developer specializes in standardized recurring reports, particularly in operational, financial or regulatory environments. A data visualization developer focuses on the presentation and usability of dashboards and interactive visual analytics.

Across these titles, proximity to the underlying data generally corresponds with more responsibility for modeling and reliability, while proximity to the end user brings greater emphasis on presentation, interpretation and workflow design.

As analytics functions grow, organizations add roles that set priorities, govern shared assets and connect technical investment with business outcomes.

A chief data officer (CDO) typically owns enterprise data strategy, governance, quality and the treatment of data as an organizational asset. A chief analytics officer (CAO) places greater emphasis on analytical capabilities and measurable business outcomes. Some companies employ both; others place the responsibilities under one executive.

An analytics manager runs the operating layer beneath that strategy, balancing incoming work, coordinating delivery and developing the analysts or engineers on the team.

A data product manager treats shared data sets, metrics and analytical platforms as products with defined users, roadmaps and adoption goals. That work often gives metric ownership a clearer operational home: the business defines the concept, technical teams implement it and the product owner coordinates how it’s maintained and consumed.

A BI consultant provides external or advisory expertise around BI strategy, architecture, platform selection and implementation.

The distribution of these responsibilities depends heavily on company size and history. What matters operationally is whether someone owns the decisions that span teams — particularly definitions, governance, priorities and the lifecycle of shared data products.

As business logic moves from individual reports and queries into shared models and semantic layers, responsibility for maintaining that logic shifts across analytics roles. Self-service and conversational analytics also expand who uses those shared definitions directly.

More analytical logic is shared in the semantic layer

A revenue metric once implemented separately in an analyst’s query, a BI developer’s dashboard and another team’s report can now live in a shared semantic layer. The calculation, dimensional relationships and business meaning are maintained centrally, then reused across dashboards, self-service analysis, conversational BI and other analytical applications.

Snowflake Principal Product Manager Will Pugh describes the need for this semantic layer in Why Do We Need Semantic Views?: “SQL is a literal language, but business logic is contextual.” A technically valid query can produce an inappropriate business answer when the system lacks the grain, relationships or metric logic that supplies that context.

This increases the importance of work that sits between raw data and its downstream uses. Analytics engineers, BI developers and other modeling roles increasingly maintain reusable analytical structures and business logic that serve multiple interfaces rather than a single report or workflow.

Self-service changes the analyst’s role

Self-service BI has already given business users more ways to explore governed data without submitting every request to an analyst. Conversational analytics extends that access by allowing users to ask questions in natural language, while AI agents introduce analytical results into workflows that may not begin in a BI tool at all.

For analysts, that shifts the mix of work toward framing questions, interpreting results, investigating anomalies and advising stakeholders. Recurring reports and dashboards remain important, particularly in operational and regulatory settings, but routine questions increasingly have other paths to an answer.

“As AI takes on more routine query generation and ad hoc reporting, an analyst’s value increasingly shifts toward framing business logic,” says Josh Klahr, Snowflake’s Head of Product Management for Analytics. “The role moves from fulfilling individual report requests toward shaping the semantic frameworks that keep self-service grounded.”

The analytical skills involved are changing as well. Writing SQL remains valuable, while understanding business context, evaluating whether an answer is appropriate and recognizing when a metric or underlying data needs further investigation take on greater weight.

Governance moves into the analytical workflow

Broader access to analytics puts more pressure on the shared definitions and controls underneath it. Someone has to maintain metric definitions as business rules change, determine who can access sensitive data, establish quality expectations and coordinate changes that affect multiple downstream experiences.

Those responsibilities span several roles. A business owner might approve what a metric means, an analytics engineer might maintain its technical implementation, a data product manager might coordinate its lifecycle and governance teams might oversee access and policy requirements.

As a result, governance increasingly operates through the same models, semantic definitions and data products that teams use for everyday analytics. Clear ownership becomes especially important when a change to one shared object can propagate across dashboards, conversational interfaces and other downstream applications.

None of these shifts implies that a particular analytics role is going to disappear. Rather, they redistribute work across the team as analytical logic, access and governance move into shared infrastructure — and they make the interfaces between roles increasingly important.

As analytics work spreads across more roles and interfaces, shared definitions become part of the team’s operating model. Snowflake Semantic Views give business entities, dimensions, relationships and metrics a governed location. An organization might define its approved revenue calculation once, then reference that logic across SQL, BI experiences and Snowflake Cortex Analyst. The business still owns what the metric means, while the technical implementation has a shared home.

Cortex Analyst uses that semantic context to interpret natural-language questions and generate SQL against structured data. Routine questions have a path to self-service without requiring each business user to understand the underlying schema, while Snowflake access controls continue to govern the data available to the user.

Analytics titles will keep changing as tools and operating models change with them. An org chart built around today’s labels offers only a temporary picture of how analytical work gets done.

Clear ownership provides a more useful organizing principle. If an organization knows who prepares trustworthy data, who defines shared metrics, who delivers analytical experiences and who helps the business use them — including what happens when those responsibilities cross team boundaries — the titles have room to evolve without leaving critical work unassigned.