There's Not Quite One One Throat to Choke
IT Manager Undertaking Root Cause Analysis
Leaving aside, for a moment, that you're hard pressed to find a vendor partner that isn't a convicted monopolist and therefore unworthy of your trust, you might still find the idea of "One Throat to Choke" appealling.
But just how possible is that, really? Most organizations actually have heterogeneous deployments and don't have just one throat to choke. "We're a *this* shop." "We're a *that* shop." Cobblers. There's too much technology ground to cover, nowadays. Let's have a look at some contenders, what they sell, and what you can call them for support about:
So it looks like you're going to have to choke at least two throats in this list. Honourable mention to HP for getting so close to covering the entire ICS sphere, but only the most hallowed corridors of the most security-conscious organizations on the planet are going without smartphones these days.
So, if you say "We're an HP shop." I'll raise an eyebrow and ask about your Bring Your Own Distraction policy. Otherwise, I know you're fibbing and you're managing multi-vendor interoperability somewhere. Best you accept that, and start making interoperability - not just vendor nameplates - part of your decision-making process.
Here at MYRA, we've had the dubious pleasure of helping many clients manage the true complexities of thinking of themselves as a One Throat to Choke shop when their reality is actually heterogeneous.
All-too-commonly, a dominant vendor in a particular field will be seeking competitive advantage by implementing features for which no agreed industry standard yet exists. Unfortunately, that means that if you have a Vendor A / Vendor B boundary close to that feature set, you're probably going to have an interoperability failure. It won't "just work." Perhaps Vendor B has knuckled under and paid to license Vendor A's feature. Perhaps Vendor B has reverse-engineered an interface with Vendor A's feature. Perhaps Vendor C sells an interoperability bridge between the two. Or perhaps you'll have to downselect Vendor A's use of the feature at that boundary.
One way or another, it tends to be ugly and complicated, and is a common reason for calling in specialist expertise like ours. We think of ourselves an integrator of Best-of-Breed vendors. But just assuming that the boundaries will work because you think of yourself as a One Throat to Choke shop is foolhardy. Come to terms with the fact that you are NOT a One Throat to Choke shop. Insist that your vendors play by the rules. Get vendor-independent advice about your intended architecture. Consider interoperability and standards compliance before you step into the fight.
Unless you actually fancy yourself Hercules.