Scenario

While working with an industry-leading SaaS analytics company, our technical team was asked to build data visualization charts & reports. The primary approach was to develop & extend a UI framework consisting of reusable config-driven components.

As the product’s clientele grew, data volumes increased exponentially. Case in point – one of the customers was facing very high loading times (up to 40s+). There were proposals to improve loading performance by working on low-hanging solutions like optimizing the database by building sub-set views, making concurrent data queries, etc.

However, our technical team was convinced that a future-proof, scalable & extensible solution was needed at an architectural level. Such an extensive solution required sponsorship for the significant development and planning effort necessary.  Since there was no official request for such a solution, this foresight first needed to be communicated, and consensus needed to be built with the client.

This was not only a critical technical challenge but also needed ownership in building consensus by educating everybody about the need and the impact.

Solution

A technical solution was proposed to build a framework-level feature for different reports, dashboards, and customers. A framework solution would not only solve this instance but a solution for this pattern across the entire platform. The aim was to make functionality and usage independent of the data contained in each component.

Few key behavior flags could be configured in the backend, and each configuration would impact its behavior. The solution would cater to multiple data sources and return different data types of various sizes. It would be primarily decoupled with other platform features and driven by explicit configurations. Such a solution would be scalable in the future as the data sizes would vary mainly between different types of clients.

The design ensured that the complex logical data processing was done at the server end and not at the front end, making the front end really snappy, even for large datasets. The front end would become more responsive and performant, positively impacting usability and adoption.

Once a technical solution was found, to build consensus, we took ownership to explain the repercussions of this problem growing in the future in all areas of the product. Multiple teams need to be convinced of such a significant architectural upgrade. As product management teams managed the roadmap, convincing them that the architectural change was worth the effort was also necessary. We needed to enroll these non-tech stakeholders in a future-proof technical proposal, which wasn’t easy.

During implementation, given multiple teams required to coordinate, we proposed a preliminary design and got it reviewed, and took inputs from each one of them. Later, we developed a detailed development rollout plan,  communicated it to all stakeholders, and got it approved by them.

Benefits