Component Map

Each component in Alma has its own page, and the map sits at its centre. The component is in the middle with its APIs listed under it. On the left are the components that call it, on the right the databases, queues and services it calls, each with its own queries or topics. The open issue sits above the component, linked to the API where it was detected, so an analyst sees the issue, the data it touches and everything around it in one view.

I was the product designer on it end to end, from the two maps to the anatomy of every node, working with one engineer for about two months.

Alma monitored the customer's traffic and collected a detailed picture of how their services talk to each other. But that picture only lived in our data. Customers relied on Datadog and other table-based tools, where every row stood alone and the connections between components were simply not there. We needed a way to show what we saw, so a customer understands what their data is doing and where it goes.

I worked with the people using it every day, SOC analysts and DevSecOps engineers, and found two different jobs.

One user browses the inventory to understand their own system: which services, databases and queues exist and how they connect. The other investigates a threat and needs to know which component it sits on and what that component reaches. So we built two maps: an inventory map of app items, and a threat map that starts from the issue and shows the component it leans on.

The first version used nodes in the style of our security map, but they couldn't carry the detail people needed, so each node became a card: a service with its APIs stacked inside it. Icons replaced text wherever they could, and colour carries status: a green or red lock for encryption, a red row where an issue was detected. Long lists collapse into a "+ more" row for the extra app items connected to a service. The trade-off was clear: by stacking APIs inside their service, an API doesn't get a map of its own.

Building it with the engineer exposed a data problem. Kubernetes reported the same workloads several times, which created duplicate app items, and NGINX and load balancers appeared as services with dozens of APIs, when a service usually has one. We had to clean that up before the map could tell the truth.

Customers told us it was the first time they had seen their system this way, and that it helped them follow their app items and spot where the problems are, quickly. Our CEO made it part of how Alma was presented: finally something he could show potential customers and investors.