Bundling is Dead. Here’s How We’re Building a Holistic App Management Platform

The SaaS market is shifting from best-in-class to robust end-to-end platforms to save costs and create a unified UX.

At Lumos, we’ve pioneered a holistic app management platform from the outset, contrasting the traditional approach of gradual bundling that we often see in tech.

Our rapid product expansion has fueled our differentiation, accelerated revenue expansion, and led to bigger contracts.

There are three product pillars that make up the Lumos platform — AppStore, Access Reviews, and Savings. Although these pillars address different use cases of managing apps and access, all rely on the same data models and capabilities. We don’t need to choose between breadth and depth because our architecture is built on a core platform of reusable building blocks. This frees up engineers to focus on developing a level of feature depth in our products that surpasses competitors.

Lumos Analytics: A Case Study

One of the building blocks we recently built is Lumos Analytics, our product-wide reporting feature. Engineers, product managers, and designers worked across 3 product engineering teams to build a unified reporting platform that we launched to our customers this past January. This project illustrates how at Lumos we can achieve both breadth and depth as we build our platform.

Product & Design: Designing for Compounding Effects

To build a single Analytics feature that spans across our 3 product pillars (Savings, AppStore, Access Reviews), we were challenged with building a unified experience that served different use cases/personas, had different requirements, and communicated different value propositions. However, that isn’t to say that our products don’t overlap today in terms of value for our end users — in fact, Lumos is predicated on the idea that our products have compounding benefits as companies adopt the entire platform.

This is why we decided to pull all of our reporting into a unified tab, as opposed to embedding our reporting within each product.

As our CEO Andrej Safundzic mentioned in this article we built Lumos Analytics around key themes of: 1. Profitability, 2. Operational Efficiency, and 3. Risk Reduction, aligning with our Spend, AppStore, and Access Reviews tabs today.

But what about when these themes overlap? For example, AppStore contributes towards risk reduction and spend is informed by temporary access in the AppStore.

We wanted to build an experience that would eventually be seamless to navigate through with time. In order to achieve this, we needed to focus on user interactions that were consistent, no matter what data points you were looking at. This was an opportunity to build Lumos Analytics with a holistic platform approach.

How can we present the right amount of information? Lumos has a lot of data to offer — how can we avoid being overwhelming? For Analytics, we practiced some restraint to make sure that the data we showed was important and actionable.

This was an opportunity to redefine ourselves through UI, a new beginning for Lumos design where we could come out and be playful, but sharp — something you can share with executives, but still approachable.

We wanted to differentiate ourselves from every other app out there.

Engineering: Building for Reusability and Scale The “How?”

Although AppStore, Access Reviews and Savings are different product areas with different data models and requirements, in order to speed up the development process for Lumos Analytics, we set a goal of building a solid and flexible architecture which would allow different teams to create or update data points quickly with just a few specific changes.

The first step to accomplish that was setting the base requirements for each product area. We broke down requirements to identify things in common across the areas. We divided the technical design into 4 different layers: the Data Layer, Service Layer, Middleware and Front End.

We looked to optimize the performance for each layer plus define a clear way to communicate between them. Decoupling the layers to make them independent was the key to developing with the freedom to independently make decisions based on what was the best for each layer in the system.

Data Layer: The data layer is responsible for getting necessary data from the database in the most performant way. We analyzed different approaches and did prototype testing to validate the performance and validate our decisions. This layer was the most important one for us because it determines the efficiency and therefore the success of this new feature — as you may expect with analytics, data often has to be displayed in real time and being fast is crucial. We defined good practices and standards about how to communicate with the database, and we built a client to consume data from a replica whenever possible to not affect overall application performance.

Service Layer: The service layer is responsible for executing data layer methods and calculating responses based on business requirements. We defined a base calculator interface that each team can use to calculate their data points and return the results to the middleware. We also implemented a lot of helpers that could be reused, including percent calculators, comparators, date grouping, and timezone handlers. Each calculator follows the same signature which helps the middleware communicate with it easily.

Middleware layer: The middleware layer is responsible for the communication between the frontend and the service layer. We designed the middleware based on what the client needed from the backend, prioritizing loading the page as fast as possible and considering what was important from the client perspective. For example we load the data when it is available instead of waiting for all data points to be calculated before loading the page.

Frontend layer: One of our goals was to build reports with shared design languages to ensure a consistent look and feel across our application. To achieve this, we created a design system and a UI library that facilitates frontend implementation. This approach enables all product teams to reuse components and build new charts following the design system with minimal configuration. It also makes frontend implementation much faster!

By unifying reporting across our product pillars with Lumos Analytics, we’ve created a seamless user experience. Our engineering approach of building shared middleware has enabled us to rapidly build our functionality across AppStore, Access Reviews, and Savings, without sacrificing breadth or depth. At Lumos, we’re pioneering the shift toward comprehensive platforms over niche point solutions. Follow our journey as we document some of our processes and learnings within our resources.