Six Products and the Rule That Keeps Them Apart

In the last post I said Cadres was a suite now. I thought that was where it would stop.

It wasn’t. I kept building, so here’s where it went and the rule I’ve set to keep it under control.

The service desk moved out

The service desk started inside the endpoint platform. That made sense at the time: tickets about servers, sitting next to the servers.

Once I used it properly, the problems showed. A service desk has needs of its own. SLA policies have to do real calendar math per customer and per priority, in the customer’s time zone. Requests need to come in where people already are, which today means Teams and Slack rather than a portal bookmark. Change governance needs a CAB and freeze windows. None of that has anything to do with patching servers.

So the service desk became its own product, called Beacon.

The part I cared about was how it stays connected. Beacon and the endpoint platform talk over a bridge. Incidents and asset state go one way and ticket status comes back. A technician can run a device fix from the ticket, but only from a fixed list of allowed actions; no arbitrary scripts get sent across. The bridge is optional and does nothing until you set it up. You can run Beacon with someone else’s endpoint tools, or someone else’s ITSM with ours.

Making that last part true took more discipline than I expected. It comes up again below.

Then the network

If you’ve run a network across many sites you know how it goes. One dashboard per vendor, each with its own idea of what a device is, and none of them can tell you whether the estate is built to your standard.

I don’t mean whether it’s up. I mean whether it’s built right: the right SSIDs, no banned legacy protocols, no firmware on a known-exploited list, and no hardware quietly going end of life.

I wanted a single view of the whole fleet across vendors, scored against standards the customer sets, with fixes that wait for approval. Vendor support had to be plugins, because the next site you take on always has a vendor you didn’t expect. Adding a vendor should mean adding an integration, not starting a project.

That’s Synapse.

And the endpoints

The endpoint platform, where this all started, grew too. I spent twenty years in warehouses and factories, and the devices those places run on aren’t servers. They’re rugged scanners on the floor, and the tools for managing them have barely changed in years.

So Relay is now one endpoint model from the datacenter to the warehouse floor, in one console. The rugged devices use the same approach as the servers: capture state, act, compare and roll back if something drifted.

Is this a suite or sprawl?

That makes six. Relay for endpoints, Beacon for the service desk, Synapse for the network, Portal for identity, Meridian for compliance, and Keystone for the commercial side.

If a vendor told me that, I’d ask whether it was a suite or just sprawl, so I should answer it myself.

I started Cadres because of sprawl: six agents on a server and four tools that didn’t talk, as I wrote in the earlier post. It would be a bit rich to spend two years building my way back to that.

The rule is that every product has to work on its own.

Each one ships with its own vendor integrations and does its whole job without the others. Beacon works with Intune and Jamf whether or not you run Relay. Synapse scores a Meraki estate whether or not anyone raises tickets. Meridian collects evidence through connectors and doesn’t depend on the rest of the stack. The links between Cadres products are optional bridges that do nothing until you turn them on.

Identity is the one exception. Portal comes included with every product, because every product needs sign-in and it makes no sense to buy it twice.

This matters in how the software is built, not just how it’s sold. If a platform only works when you buy all of it, you’re being locked in. Products that work alone and work better together let you buy what you need.

What it cost

Building six products instead of one has a cost, and I won’t pretend it doesn’t. It’s the same trade-off as in the last post, only bigger. Everything is in beta or early access, and each product page says which. The people these tools are for have heard plenty of vendor optimism already.

All six follow the idea from the first post: automate the routine work, check the result, and involve a person only by exception. Patching compares state and rolls back. Beacon’s automations follow fixed rules and every run is traced. Synapse waits for approval before it writes to a device. Keystone’s month-end close won’t lock the books if they don’t balance.

The thing kept growing. I’ve stopped trying to stop it and given it rules instead.

If your tools only work when you buy the rest of the vendor’s range, and you’d rather they didn’t, start a trial.