Why I Keep Calling Connectors the Boogeyman

I call connectors the "boogeyman" at the start of this episode. That was a joke. Mostly.

A connector means another service to deploy, another owner, and another place to look when something goes wrong. It is easy to point at all of that and decide the connector was a bad idea.

It was not. Connectors solved a real problem, and plenty of printer fleets still need them.

What a connector actually does

Printer fleets are rarely uniform. Manufacturers have their own communication methods, and a perfectly useful receipt printer can stay in service for ten years or more.

In the model I describe in the episode, the OEM builds software that sits between Workspace ONE UEM and its printers. That connector translates the conversation for devices we could not otherwise reach in a consistent way.

Customers do not replace a ten-year printer fleet just because our architecture got nicer. Compatibility will never win the prettiest-slide award, but it can prevent a very ugly replacement bill.

Where it gets awkward

The OEM owns the connector. That has consequences.

Support for a new manufacturer or model depends on the matching connector work, even when the Workspace ONE side is ready. I cannot responsibly promise a date for work we do not fully control.

Troubleshooting can also split in two. Workspace ONE may look healthy while the OEM still needs to inspect the connector. Each team can end up holding half the picture, which is not a fun place for the customer to be.

Then there is the setup around the software itself. Depending on the OEM and implementation, a customer may need to obtain the connector separately, arrange services, or run more than one instance to reach the required scale.

None of that is a fun surprise after someone has already checked the compatibility box. Put the ownership, services, and scale questions on the table before rollout.

A better path cannot become a deadline

Where the printer and the required capabilities support it, MQTT is the path I would rather take. Fewer handoffs. Fewer owners. Fewer places for everyone to point when the dashboards are green but the printer is not. Episode 3 gets into why.

But a better architecture does not make an old fleet new. Some manufacturers will not support the newer stack yet. Some customers will run both paths for years. Printers tend to outlive the technology plans made around them.

So my rule is fairly simple: use MQTT where it is supported and does the job, keep the connector where it still solves a real compatibility problem, and be very clear about who owns deployment, support, and scale on either path.

An architecture diagram also tells you who answers when something breaks.

I will probably keep calling connectors the boogeyman because the joke is too convenient. I just will not pretend they can disappear before the printers that rely on them do.