Experience detail · Jul – Aug 2024
Corporate Application & Platform Development Intern @ TSMC
Project overview
TSMC maintained more than 20 internal IT products, many of which relied on complex approval workflows handled through a centralized approval platform. While the platform was effective at routing individual approvals, it offered limited visibility into approval activity at the product level.
During my internship, I explored whether Apache Superset could provide an analytics layer that allowed product managers to understand approval patterns more directly while still meeting the company’s integration and access-control requirements.
My role
I was responsible for evaluating Apache Superset for this use case, connecting it with the existing database and TSMC SSO environment, investigating role-based and row-level access control, and configuring analytics useful to product managers.
Because Superset was relatively unfamiliar within my immediate team, I also researched its behavior, coordinated with another internal team that had prior experience with it, and documented my findings so the work could continue after my internship.
Problem
Approval data existed, but product-level visibility did not
The centralized platform was designed primarily to route approvals and expose approval functionality through APIs. Its interface focused on individual approval requests rather than giving each product manager a broader view of the activity associated with their product.
Approval, partial-approval, and rejection records existed in the underlying database, but product managers depended on processed SQL queries for recurring reviews. The challenge was to provide easier access to analytics without compromising TSMC’s security and least-privilege requirements.
Solution
Introduce an analytics layer without changing the core platform
I investigated Apache Superset as a separate analytics layer on top of the existing approval data. Rather than modifying the centralized approval platform itself, Superset could provide dashboards and visualizations specifically for product-level analysis.
My evaluation covered more than whether Superset could create charts. I tested its compatibility with the existing data environment, investigated SSO and permission behavior, explored row-level restrictions, and documented limitations that would affect an enterprise implementation.
How I worked through it
A closer look at the process
- 01.
Defining What the Tool Had to Prove
Superset was proposed as a possible solution, but the first question was not how to build a dashboard. It was whether the tool was appropriate for the environment at all. I broke the broad request into concrete requirements, including database compatibility, analytics flexibility, SSO integration, and access-control capabilities.
I aligned those requirements with my mentor and manager, then consulted engineers from another internal team who had previously worked with Superset when documentation alone was insufficient. This gave me a clear framework for evaluating the tool rather than experimenting without defined criteria.
- 02.
Tracing an Unexpected Time Shift
While testing a dashboard, I noticed that timestamps were consistently shifted even though I had been told the underlying database used UTC. Rather than immediately adjusting the displayed values, I traced how time could be interpreted across four layers: the source data, database engine, Superset backend, and browser client.
I verified the database-to-Superset configuration, investigated client-side conversion, and changed browser timezone settings to isolate the shift. When those tests failed to explain it, I asked my mentor to verify the source configuration. The database was actually using UTC+8, revealing that the issue came from the input assumption rather than the dashboard.
- 03.
Designing Access Around Least Privilege
Making the data visible also meant ensuring users could see only what they were authorized to access. Basic roles already existed for SSO-connected departmental accounts, so I investigated whether Superset’s permission model could restrict access at the row level rather than only at the dataset or table level.
I determined that row-specific access was possible, but introduced additional complexity and limitations. A complete implementation was beyond the remaining internship timeframe, so I documented the role structure, limitations, and configuration steps another developer would need to reproduce and continue the work.
Outcome
What changed — and what I learned
By the end of the internship, I had evaluated Superset against the team’s major analytics, integration, and security requirements, configured a working analytics environment, resolved an unexpected timezone issue, and established that product-specific row-level access was technically possible while identifying its implementation limitations.
Just as importantly, I turned the investigation into reusable documentation rather than leaving the knowledge tied to a two-month internship. The experience taught me to approach unfamiliar systems by first defining requirements, isolating assumptions during debugging, and communicating technical findings in a form another engineer can continue from.