Vendor Addiction

If you spend much time in IT, you’ll eventually encounter someone suffering from vendor addiction. Vendor addiction is characterized by an aversion to building your own tools, environment, and architecture, in favor of farming these core components out to a third party.

Like any other addiction, Vendor Addiction affects those around the addict as much, if not more, than it does the addict themselves. In fact, most vendor addicts don’t think they have a problem. “They have a great offering, great price… I really think we should schedule a demo.” or “I really like <salesperson> and would love it if we could partner with them.” Notice the use of words like offering and partner? Those are warning signs.

The effects on the team are pronounced. Endless demo meetings, constant “check these guys out” emails from the boss, and the risk of being negatively labeled for disagreeing with management (who should not be designing your infrastructure anyway — isn’t that what you were hired to do?).

Of course I am being somewhat sarcastic. There are technology vendors with great tools that do enable engineers to be more productive. But partnering with a third party is a serious decision that will affect your design and architecture for years, if not for the entire life of the product. For example, if you decide to use a third party product that slaps a pretty front end on top of Amazon EBS, then calls themselves a “cloud storage solution”, what problem are they solving? Is it so hard to learn EBS that we need a front end that has a nicer font than the AWS console? Years later when you realize it was a mistake, how easy will it be to back away and manage your own storage? Did your developers use the vendor’s API? Congratulations, you are now coupled to them, and can’t decouple easily (hmm, maybe these APIs are a gateway to vendor lock in..).

I posit that your time is better spent learning the platform you develop on (AWS, for example) and managing your storage, network, etc, using native tools. AWS was made for that very purpose, to make provisioning and managing a virtual datacenter easy. Designing your own tools pays off down the road. You know how they work, and they can be customized for your team’s needs. Oftentimes the functionality you’d actually use from that $300k per year “solution” can be coded in a week. Trust your engineers more than someone else’s.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.

Responses
The author has chosen not to show responses on this story. You can still respond by clicking the response bubble.