Vendor Interactions

[deanwebb]

Question: Do vendor (X) products work with vendor (Y) products?

This is going to come up all the time. And while the answer may be, at the time of sale or when you last called support, "yes", that can change over time.

No vendor can test for all possible ways a customer uses a product, especially with regard to third-party systems. Doubly especially with regard to third-party systems that are from vendors otherwise regarded as competitors. Will there ever be an official connector to allow data interchange between Cisco ISE and ForeScout CounterACT, for example? I would imagine that if such a connector were created, it would be to facilitate a competitive upgrade, But if a big enough customer makes a big enough demand, a connector to allow the systems to peacefully co-exist might just happen.

But then it would fall subject to the peril that besets all interoperability - upgrades. Sure, everything was fine when (X) was on code 3.4.5 and (Y) was running 1106.2A, but the new 1107.0 code for (Y) breaks the functionality. And just when that's fixed, 3.4.6 from (X) accidentally re-introduces a bug from 3.4.4 that breaks the 1107.0.1 hotfix from (Y). And so on...

And, while it may make you feel better to verbally berate your vendor reps for their lack of QA to catch that problem, it won't change the fact that there are only so many developers at a vendor and that they now have a hard choice to make. Namely, do they fix the problem right now, or do they put it off for a later service release?

If the problem is killing production on a core feature of the product, like maybe two different vendors at either end of a VPN connecting a company HQ with a manufacturing line, then the vendors are going to put resources on resolving that issue. There may still be finger-pointing - "Well, our router would work fine if they would just follow the RFC the way we read it!" - but they can work together to fix things to get that production out of the mire.

But if the problem is something closer to "nice to have" than "must have", that increases the chance that you'll have to come up with a workaround or live without the feature. If it's an optional software model that's not getting support, then that means you're likely to not renew a subscription to that piece - the devs in charge of that module could then be facing reduced or zero bonuses if sales start to drop off. That can light a fire under their will to support.

But even if the devs are inspired to help you night and day and to move mountains to get you where you need to be, if the other vendor's devs either can't or won't help, then there's not much that can be done, should the other vendor need to make changes (or open up a proprietary API) to make things work.

Things like database queries or REST API calls are quite common and easy to implement or fix. Things like proprietary SDK implementations are neither. Your mileage may vary, but that's how things go, in general. Some technologies are old enough or common enough, such as Microsoft Active Directory, that even though it's vendor-specific, it's pretty much an accepted standard that everyone knows how to work with. It's those emergent technologies that are the most difficult to accommodate and where vendor-to-vendor interactions will potentially face the most obstacles.