Back in 2017, when I was looking around for my next challenge, I wrote this article while preparing for an Amazon interview. I just came across this and thought it was a good story to share about the early days of Power BI SaaS offering.
Most decisions are made with analysis, but some are judgment calls not susceptible to analysis due to time or information constraints. Please write about a judgment call you’ve made recently that couldn’t be analyzed. It can be a big or small one, but should focus on a business issue. What was the situation, the alternatives you considered and evaluated, and your decision-making process? Be sure to explain why you chose the alternative you did relative to others considered.
An existential question most engineering leaders face at least once in their career is whether to reuse or rewrite a core piece of their technology due to changing trends impacting their business. Recently as a Group Engineering Manager for Microsoft’s PowerBI team I had to make a similar decision. The choice is usually a hard one since you don’t always have the data required to make an analyzed decision and it is more a judgement call based on past experiences and future trends on which you need to take a bet on.
Before I describe the specific decision taken, it would be helpful to provide some context as to where we were as a business. PowerBI’s core value proposition is to provide self-service BI tools targeted at business users. Towards this goal, we had released PowerBI 1.0 as an addon for Office 365 users which leveraged the analysis and reporting capabilities of Excel on the web. As part of that effort, the visualization stack used for the charting capabilities were based on an existing implementation from Excel. For the web application, our team had transformed it into a server hosted rendering component fitted with a client side support for drawing of the charts. The team built a new concept called Visual Representation Markup for communicating the shape (or geometry) of charts on the server side to the client. Nine months into the project, the MVP of the visualization stack was released along with release of PowerBI 1.0. At that time the team was aware of the high technical debt they had accrued due to the complex nature of the stack. One of the primary areas of concern was the performance of the stack since it was a chatty service and each user interaction required several round trips to the service from the client. The team had drawn up a plan to address these performance issues and implement other optimization techniques.
After the initial release of PowerBI 1.0, senior leadership team challenged with slow user adoption decided to pivot PowerBI from an Excel based workload to a more generic SaaS service. The service was focused on allowing business users to connect to a variety of data sources and help them gain insights using interactive charts. As a part of this pivot, I was promoted to the role of Group Engineering Manager for the SaaS service and I inherited the visualization stack. Given the intense pressure to release the new service, we had to decide the execution strategy for our visualization stack. Our choice at that point was either –
- double down on the existing server based rendering stack and improve the performance of the service, or
- invest in rewriting the visualization stack on a client based technology leveraging the best of breed charting solutions available in the market like D3.js, C3.js, Highcharts, etc.
One of the main reason for the server based stack was the desire to use a single implementation across desktop and web. The goal behind it was to provide a consistent experience for our users. Given the team’s and my previous experience with web technologies and the requirements around experience, we trusted our instincts that a rewrite using the latest HTML5/JavaScript technologies would make the team more agile and help meet our goals both on user requirements and engineering cost. After an assessment of the available frameworks, we chose to use D3.js which had industry wide adoption and strong community support. The technical challenge was to wrap this framework within our visualization stack and implement the experience consistency. We didn’t think a continued investment in the server based stack would have resulted in a better outcome. The reasoning was based on two fronts –
- User Experience – a client based implementation would provide the best experience in terms of performance and fluidity. Making a chatty server based implementation perform better would have been prohibitively expensive.
- Engineering Cost – Leveraging community built solution would make our engineering cost lower since we could completely devote our focus on making the integration solid and invest more in the user experience.
Armed with a few early prototypes demonstrating the proposed new architecture, we undertook the task of convincing senior leadership that this would be the right call. Microsoft has long struggled with the “not-invented-here” syndrome where distrust in community solutions caused it to invest in building everything internally. But based on our persistence and presentation of the pros & cons, we convinced the leadership to provide us a 3-month window to deliver a MVP to replace the existing stack. Based on an aggressive execution plan we delivered a performant and user delightful experience with the new stack on time. With the engineering agility afforded by the new stack, we were able to react quickly to user feedback and make our offering one of the most compelling BI solutions in the market with close to 6 million subscribers in the first year since launch.