DATA & ANALYTICS
MODERNIZATIONFIELD
REPORTMetric meaningDependenciesTarget designAcceptance

From inherited analytics to explicit definitions

A new data platform.
The same
business meaning.

Moving a dashboard is only part of the work. Its numbers depend on transformations, filters and business rules accumulated over time. Trazadera modernAIze helps your team recover that logic and decide how it should live in the target platform.

Northstar University · Qlik to dbt for Databricks
Synthetic demonstration

01 / The meaning behind a number

The label stays.
Does the answer?

A familiar KPI can produce a different result after migration. An omitted filter or a changed period can leave teams reconciling two versions of the truth. Start by exposing the definition behind the number.

Northstar metric vCriterion13: distinct count of Comp, excluded values, inherited selection context and the original Qlik expression.Enlarge
modernAIze · a recorded metric, its filters and its original Qlik expression.

Reading one real expression

More than a distinct count.

Which values count?
The expression counts distinct Comp values and excludes empty strings, a space and a hyphen.
Which period applies?
YR_CDE is constrained by the vCriterionCY variable. The chosen year is part of the definition.
Which selections still apply?
The metric inherits the current selection context. A target model and its reporting layer need to agree where that behaviour belongs.

02 / The system behind the report

Follow the number
past the dashboard.

Northstar combines academic and financial extracts with configuration and benchmark data. The flow feeds both a dashboard model and frozen review-year archives. Replacing the front end leaves much of that responsibility unresolved.

Northstar flow from academic, financial, configuration and benchmark sources through processing to frozen review archives and the dashboard model.Enlarge
Northstar University · source architecture reconstructed in modernAIze.

Scope a complete reporting path.

Include the inputs, transformations and calculations that produce one business result. Shared dependencies help determine what should move together and what needs to stay connected.

Keep history intentional.

A frozen review year and a recalculated dashboard serve different purposes. Decide which outputs must remain reproducible before changing the processing underneath them.

03 / A deliberate target model

Give the logic
a place to live.

modernAIze combines deterministic parsing and AI enrichment in a semantic model your team can review. Target decisions and blueprints make the intended architecture explicit: how to organise the data, where to put shared rules and what remains in the reporting layer.

  1. Source-aligned

    Staging

    Preserve source meaning. Make names and types consistent, with a clear route back to the input.

  2. Shared logic

    Transformations

    Put reusable joins and calculations in named models. Define the grain: what one row represents.

  3. Business use

    Published definitions

    Agree dimensions, facts and metric contracts. Decide which filters belong in the model and which remain interactive.

In the Northstar demonstration, a Star Schema Blueprint describes the intended design. The prepared dbt project contains staging and intermediate models for inspection.

See the blueprint
Actual modernAIze Star Schema Blueprint defining layers, staging guidelines and dimension design.Enlarge
Star Schema Blueprint · explicit guidance for staging, dimensions and facts.
Explore modernAIze

04 / The change you can accept

Agree what must match.
Explain what may change.

Readable SQL makes the new implementation inspectable. Business acceptance needs another step: compare agreed results for the same inputs, periods and selections. Make the checks explicit before retiring the existing reports.

CheckMake the comparison concrete

Population & grain

The same entities, at the same level of detail. Account for duplicates, missing identifiers and excluded values.

Periods & selections

The same year, calendar and filter state. Check frozen historical results separately from live recalculations.

Results & exceptions

Compare totals and representative records. Agree tolerances and document intentional changes with the metric owner.

See a concrete check: what counts as “next term”?

A later record is not necessarily the next academic term.

The prepared persistence model looks for the next row for a student and programme. Before calling that retention, agree how to handle missed terms, repeated enrolments and the order of the academic calendar.

This is a separate model in the same demonstration estate, not the implementation of vCriterion13.

src_resident_term_persistence.sql · excerpt
    lead(term_id) over (
      partition by student_id, program_code
      order by term_id
    ) as next_term_id
Download the model
Inspect the dbt project
Northstar dbt project tree and the term persistence SQL model in the modernAIze file browser.Enlarge
Prepared demonstration output · 19 files, including source declarations, staging and intermediate SQL models.

The Northstar output is a prepared demonstration project. Execution on Databricks and source-to-target reconciliation have not been performed for this example.

Start with one reporting path

Which number must
your business still trust?

Bring a representative report, its source scripts and a result your team already relies on. Together, we can identify the hidden rules, define the target responsibilities and agree how to check the change.

Discuss your analytics