Building a shared analytics platform trusted across the university
RMIT is an international university of technology, design and enterprise with more than 104,000 students and over 13,000 staff. It has campuses in Australia and Vietnam, a research and innovation hub in Spain, partner-delivered programs across Asia, and research and industry partnerships worldwide.
In 2022, RMIT launched a centralized data analytics platform on AWS, Snowflake, and dbt platform to bring previously distributed analytics teams onto a shared foundation with common governance and engineering standards.
“When this platform was built, it was built around a principle of bringing people to data, rather than data to people," says Jain.
From the outset, dbt gave RMIT University a transformation layer plus lineage, documentation, and catalog capabilities that helped create a shared foundation across the university.
This platform sits inside a wider central analytics function. Before that shift, analytics teams were distributed across different parts of the university, each using different tools and processes. Gradually, the platform became part of a broader strategy to create shared standards, reusable engineering patterns, and centrally trusted data products for the university’s data team.
As the platform scaled, adoption had grown to 20+ teams, around 70 to 80 dbt users, and roughly 30 to 40 core developers. The main analytics project alone had about 3,500 models and nearly as many tests. That growth showed the platform strategy was working.
A platform ready for its next stage
"The platform was doing exactly what we'd designed it to do. More teams were using it, more data products were being built, and adoption was growing. The challenge became how to maintain a great developer experience as everything scaled," says Jain.
The friction was cumulative. Parsing, compilation, validation, and pipeline checks each added waiting time. On their own, those delays looked manageable. Combined, they slowed how quickly the team could deliver new work across the university.
"If I needed to deploy code, I’d start planning days in advance because I knew the pipelines and processing would take time. Even small changes take longer than they should, and that slowed everything down," says Jain.
RMIT's initial response was architectural. The team started planning a project split, with dbt Mesh as the path forward. But this wasn't just reorganizing code. It would have meant moving to a multi-project operating model, reworking Snowflake RBAC, setting up cross-project enablement, and changing how teams developed and collaborated. The platform was already working, and all of that effort was just the cost of keeping performance up at the next scale.
From 6,100 migration blockers to Fusion-ready in four days
"We were planning to split the project and redesign parts of the architecture, but when Fusion entered the conversation we asked ourselves: can Fusion solve the problems we're trying to solve? That question changed our approach," says Jain.
Fusion addressed parsing and compilation bottlenecks within the existing shared platform, without making that disruptive redesign the immediate next step.
At the start of 2026, the team migrated from Bitbucket to GitHub, improving integration with the dbt platform and standardizing the development workflow ahead of the upgrade.
The first immediate challenge was technical debt. The project had approximately 6,100 deprecations that needed to be resolved before Fusion could deliver its full benefits.
Rather than tackling them manually, the team analyzed common patterns and used dbt-autofix to accelerate the process. All of this happened while the platform was still running on dbt Core, with no disruption to ongoing work. "Within a few hours, we were able to fix more than half of the deprecations. That gave the team confidence that this was actually possible," adds Jain. Four days later, all 6,100 had been resolved, and a quality gate in the CI/CD workflow ensured no new ones could be introduced.
To minimize disruption, RMIT University tested Fusion first in a smaller governance project used for telemetry and observability. This surfaced macro behavior that triggered continuous queries in Snowflake, as well as manifest-related issues, allowing the team to resolve problems before expanding deployment across the wider platform.The team took the same careful approach with orchestration, selectively enabling a capability that reuses unchanged assets rather than rebuilding them only where it improved efficiency.
Fusion drops parsing to 18 seconds and cuts pipeline runtimes by more than half
The first improvement appeared almost immediately. Parsing times in the university's primary analytics project dropped from approximately three minutes to roughly 18 seconds. For a repository containing thousands of models and tests, that dramatically shortened development feedback cycles.
The team then revisited its broader CI/CD workflows, replacing dbt Core-based checks with Fusion-based processes and simplifying the steps developers needed to run before pushing code. As a result, average feature pipeline runtime fell from approximately eight minutes to three minutes before the dbt platform job itself began.
Users also began seeing improvements in production environments. Overnight jobs, release processes, and other production workflows completed faster following the rollout.
Fusion allowed RMIT to continue scaling its existing environment and improve the developer experience without first undertaking the planned platform redesign. The decision didn't remove the need for future architectural stewardship. It changed the immediate path and avoided layering a broad organizational change on top of a technical migration.
The migration delivered benefits beyond performance. By working through the rollout and understanding how Fusion behaved in practice, the engineering team became more confident in identifying and resolving problems when issues occurred.
The team also saw approximately 15%–20% reusable assets in workloads where orchestration was enabled. More recently, Fusion combined with model optimization by the engineering team drove approximately 20% lower compute usage through daily pipelines, even as workload continued to increase.
"Fusion gave us a way to achieve the scaling objectives we were aiming for without having to redesign the platform we'd already invested in." - Vishesh Jain, Delivery Lead, Data Analytics Platform at RMIT University
The most significant outcome was that day-to-day users experienced very little disruption. Rather than becoming a prolonged change-management program, Fusion simply became part of the platform experience.
Creating capacity for the next stage of growth
With the platform performing more efficiently, RMIT is focused on simplifying job design, reducing operational complexity, and identifying further opportunities to optimize compute usage as adoption continues to grow.
Longer term, the university wants to bring more teams onto the platform so they can build and manage their own trusted data products within a governed, standardized environment while reusing shared assets and established engineering practices.
"People coming on board are not just consumers. They can benefit from the standards the engineering team has set and the quality of models that have already been written," says Jain.
The ambition is to extend that pattern across the university, improving engineering maturity beyond the data team.
