Skip to Content

The Loop Asia

Insights

Analysis and commentary from The Loop Asia — AI, APIs, and technology leadership across Asia-Pacific.

Thanks for subscribing!

No spam. Unsubscribe any time.

Why a tool that won't talk to your other tools becomes a C-level problem

The real cost of a new security or observability tool isn't the license fee — it's what happens to your team's ability to react when it doesn't fit into everything else they already use.
October 22, 2024 by
Why a tool that won't talk to your other tools becomes a C-level problem
Jon Scheele

This deep dive expands on the Loop Asia conversation with Buu Lam, Community Evangelist at F5.


Buu Lam said something in passing at Govware worth more room than the interview gave it: "How often do we see technologies that are amazing at what they do, but they can't quite figure out how to build an ecosystem." Not unkind — a failure mode I've seen in almost every architecture review: a tool excellent at what it does, hostile to everything around it.

For a Head of Architecture or CTO evaluating the next addition to a multi-cloud stack, that's the real decision. Not "is this the best product in its category" — whether it's still integrable in eighteen months, once your team has wired their workflows around it.

The test Buu described, without quite naming it: does it still have an IP address, and do we still have connectivity. Too simple to be a framework, maybe — but it rejects judging a tool on its narrow function over whether it fits the system it lives inside. F5 never had a homogeneous environment to assume, so "does this play with others" became a first-order question, not an afterthought.

Why best-of-breed loses to ecosystem-fit

Take the Red Hat example further. Red Hat had its own answers to problems its OpenShift partners also solve, and opened the platform up anyway — to F5 and others who could, in theory, compete with it. A platform that does everything itself caps its market at its own roadmap; one that opens up captures every workload needing a capability it won't build.

The hyperscalers ran the same experiment in reverse and learned it the expensive way: "it's all software, we'll write it ourselves, we'll carry the whole load." What stopped that wasn't technical — customers had already built DevOps pipelines with specific vendors, and moving a workload meant replacing that pipeline or discovering the homegrown alternative didn't fit. The ecosystem had to exist before the workloads would move.

The governance layer this creates

There's an implication here that matters more to architecture than procurement. If ecosystem-fit is the real selection criterion, the compliance question — who can attest to what, who owns the audit trail when three vendors' telemetry feeds into one incident response — has to be evaluated at selection time, not retrofitted once the tool is load-bearing. Buu's aside on Govware compliance put it plainly: "if you're government or you're financial and you have to attest that you can do certain things and you don't have the proper recording for it... you can't do business." That's an architecture decision, not a security team's problem to inherit later.

In practice: evaluation criteria should include what standard a tool exposes data through, whether it adds to your control plane or fragments it, and who's accountable for the audit trail. None of that shows up in a feature comparison. It shows up eighteen months later, when a tier-1 analyst can't find a signal because it's sitting in a dashboard nobody wired into the rest of the estate.


Evaluating the next tool for your stack on features alone?

Making the vendor and architecture calls with the full downstream integration cost in view — before the contract is signed, not after the workaround exists — is exactly where I help.

See how I can help →