Why analytics engineering isn't just data modeling

Analytics engineering is often misunderstood as simply “data modeling” — a task focused on building tables and defining relationships. In reality, analytics engineering is a broader discipline that blends technical craft with software engineering practices and organizational enablement. Analytics engineers transform and test data, document lineage and logic, implement collaboration workflows, and help scale analytics work across teams.

The full scope of analytics engineering

Analytics engineers transform, test, deploy, and document data. They apply software engineering best practices like version control and continuous integration to analytics code. This work extends well beyond simply designing tables and defining relationships between entities.

The role emerged from a practical need. Traditional data teams operated in a cycle where analysts gathered requirements from stakeholders, submitted requests to data engineers, and waited (sometimes for weeks) for new data pipelines or fixes. Data engineering teams accumulated months-long backlogs while business users grew frustrated with delays. Analytics engineers broke this bottleneck by taking ownership of the transformation layer, using tools like dbt to build data pipelines that were both less complicated and less fragile than previous approaches.

Core responsibilities beyond modeling

Analytics engineers maintain clean analytics code at scale. This means checking code into source control, versioning transformation models, creating and running data transformation tests, ensuring code follows DRY principles by bundling reusable components into packages, and using CI/CD to automatically and safely ship data changes to production. These practices come directly from software engineering, adapted for the specific challenges of data work.

Documentation and data definitions form another critical area of responsibility. Analytics engineers ensure that data users and other engineers understand what purpose data serves, where it comes from, and how it was derived. This documentation work directly enables data self-service across the organization.

Training business users on tools represents yet another dimension of the role. Analytics engineers bridge the gap between data engineers and business users through brown bags, one-on-one training, and other teaching modalities. They show data analysts and others how to find data and leverage it in reports, reducing dependency on centralized teams.

The organizational impact

The value analytics engineering delivers extends far beyond technical outputs. When organizations introduce an analytics engineering practice, they typically see improvements across multiple dimensions.

Reducing engineering backlogs

When all requests for new data projects or fixes must flow through the data engineering team, that team becomes a bottleneck. Adding analytics engineering means adding a practice focused solely on creating new data pipelines and transformations. Instead of relying on data engineering for every data change, teams can hire analytics engineers whose sole responsibility is managing their specific data needs.

Improving data velocity and quality

Data engineering team members juggle multiple responsibilities, which often creates large lags between requests and fulfillment. If a business user has an issue with something the central data team delivered, it means making yet another request and returning to the back of the queue.

By contrast, an analytics engineer's sole focus is developing new data sets for their teams. They can ship changes to users in days instead of weeks or months. This faster iteration cycle also improves data quality. Analytics engineers embedded with their teams develop deep domain expertise in their specific business area. They understand the business model and data needs in detail, making them more efficient at implementing requirements. They can get answers to hard questions more easily than members of a centralized data engineering team who support multiple domains.

Enabling infrastructure evolution

Data engineers can absolutely build data pipelines, but that doesn't mean it's the best use of their time. Most data engineering teams would rather focus on providing new capabilities for analytics engineers and data analysts. When analytics engineers take on more data pipeline work, it frees data engineers to focus on infrastructure improvements like creating self-serve tools for initializing new data products, improving data governance capabilities, optimizing query performance, and reducing pipeline costs.

Since infrastructure improvements benefit the entire company, this work often has high return on investment. Consider a change that reduces the time to run CI/CD jobs by 10 minutes. In a company with hundreds of data pipelines, this represents significant time and cost savings.

The technical craft: modularity and maintainability

While analytics engineering encompasses organizational responsibilities, the technical craft remains central to the role. The shift from monolithic SQL scripts to modular, version-controlled transformations fundamentally changed what's possible in data work.

From monoliths to modules

Before modern data transformation tools, the most reliable approach to data modeling involved writing massive SQL files (sometimes 10,000 lines or more) or splitting logic across separate SQL files or stored procedures run in sequence with Python scripts. Few people in the organization would be aware of these scripts, so even when someone needed similar transformations, they'd start from source data rather than leveraging existing work.

With modular approaches enabled by tools like dbt, every producer or consumer of data models can start from foundational work that others have done before them. When foundational data models are referenced in multiple places rather than rebuilt from scratch each time, the dependency graph becomes much easier to follow. Teams can clearly see how layers of modeling logic stack upon each other and where dependencies lie.

Naming conventions and project structure

A solid naming convention makes data modeling projects easy to navigate. Without one, teams may rebuild models that had already been reviewed and published, or rejoin data in duplicative, low-performance ways. Naming conventions define both the types of models used (source, staging, marts) and what types of transformation each model type handles.

Staging models clean up and standardize raw data coming from the warehouse, providing consistency for downstream models. They're typically a one-to-one reflection of raw sources, with light transformations like field type casting, renaming columns for readability, and filtering out deleted records. When anything changes in source data, fixing the staging layer ensures changes flow into downstream models without manual intervention.

Data mart models apply business logic to build core data assets used directly in downstream analysis. These typically include dimension and fact tables with heavier transformations: joins of multiple staging models, CASE WHEN logic, and window functions. Organizations may also use intermediate models to break up complex logic or base models to join related staging models before moving downstream.

Readability and reusability

Individual data models should remain readable (ideally around 100 lines of code). Models shorter than 100 lines typically avoid overly complex joining, either by limiting the raw number of joins or by joining in simple ways. When someone opens the model, they can quickly understand what it does and how they might modify or extend it.

SQL files can become long and tedious to read, especially when handling tasks like unioning multiple source tables or generating date spines. This is where macros become essential: they allow teams to invoke modular blocks of SQL from within individual files. Leveraging macros and packages built by others enables teams to sprint out data models quickly while keeping them easily readable.

Where transformation ends and analysis begins

Defining where data modeling effort ends and where analysis begins helps teams avoid over-engineering transformations. If end users write SQL or use analysis tools that join tables for them, the final data modeling output can be generalized fact and dimension tables. Users can freely mix and match these to analyze various aspects of the business.

If end users don't write SQL or analysis tooling is limited in terms of self-serve joining, analytics engineers may need to curate datasets that answer specific business questions by joining together multiple fact and dimension tables into wide tables. The goal in transformation work is to bring data together and standardize prep work, not to pre-build every analysis or complex aggregation that may come up in the future.

Building for the team

Analytics engineering enables broader participation in data work. Once a project has clearly defined structure, new contributors can produce high-quality SQL modeling regardless of their "technical" background. A solid folder structure and clear model review process provide enough guardrails to keep transformation code quality high.

This democratization of data work represents one of analytics engineering's most significant impacts. By creating accessible, well-documented data products and establishing clear patterns for how to build on them, analytics engineers enable more people across the organization to work directly with data. This reduces bottlenecks, improves data literacy, and ultimately helps organizations become more data-driven.

The path forward

Analytics engineering is not just data modeling. It's a practice that combines technical craft with organizational enablement, software engineering principles with business domain expertise, and infrastructure thinking with end-user empowerment. For data engineering leaders evaluating whether to build an analytics engineering practice, the question isn't whether your team needs people who can model data; it's whether you need people who can transform how your entire organization builds, maintains, and uses data.

To learn more about building an analytics engineering practice, explore resources on what analytics engineers do, review analytics engineering best practices, or check out the dbt Learn training catalog to develop your team's skills.

Analytics engineering FAQs