Just a thought from a guy who's spent way too many years in the ops trenches and is now trying to make sense of it all from an enterprise architecture chair. This isn't a formal paper. This is a conversation.
Alright, let's be honest with each other for a minute.
I'm still finding my feet in this whole Enterprise Architecture world. For the last 15+ years, my life has been operations. Servers, cloud, networks... the stuff that breaks at 3 AM. My job was to get it working again, fast. You learn a few things when you live that life. You see the same patterns of failure over and over.
And there's one pattern that's been bugging me more and more lately.
It's this idea we keep selling ourselves: that using multiple vendors for a single solution makes us more resilient. On paper, it's beautiful. Don't put all your eggs in one basket, right? If Vendor A has an issue, Vendor B can step in to pick up the slack. Simple.
But then I look at the reality I've had to deal with. The specific flavor I keep seeing is this: we buy one solution, but we're told to use two vendors to deliver it, splitting the workload between them.
This isn't a resilience strategy. Let's call it what it really is: "feeding the village."
It's a political decision disguised as a technical one. It's about keeping multiple parties happy, spreading the budget around. And it's one of the most effective ways I've seen to build a complex, expensive system that's almost guaranteed to fail when you need it most.
The Mess in the Kitchen
Imagine you're trying to cook one big, important meal. But instead of one kitchen, you're forced to use two. In different buildings.
You have one chef in Kitchen A and another in Kitchen B. You give them both the same recipe for the main course. Kitchen A is responsible for the protein, Kitchen B for the sides. Sounds simple enough.
But Chef A uses a gas oven, and Chef B uses an electric one. They use different brands of salt. Their timers are calibrated differently. When the protein is ready, you have to run it across the street to Kitchen B to be plated with the sides. But by the time it gets there, it's cold. The sides are overcooked. The customer gets a messed-up meal.
Who's fault is it? Chef A? Chef B? The guy who ran the plate between kitchens?
That's what running a single solution across two vendors feels like. It's a logistical nightmare that creates problems you never would have had in the first place.
The Problems We Pretend Don't Exist
When we do this, we're not building a safety net. We're weaving a spiderweb. And we're the fly.
The Blame Game: This is the first thing that happens when something breaks. It's never anyone's fault. Vendor A points to Vendor B's API. Vendor B says Vendor A's data format is wrong. Your own team is stuck in the middle, trying to prove who broke what, while the system is down and the business is losing money. I've been on those marathon conference calls. They are soul-destroying. And they don't solve the problem.
The Hidden Costs: The sticker price is a lie. You're not just paying for two licenses. You're paying for the integration team to stitch them together. You're paying for the duplicated support contracts. You're paying for the extra management overhead to coordinate between them. You're paying for two sets of training. These costs are almost never in the original business case, but they show up on your budget, always.
The Frankenstein Monster: You end up with a system that isn't really Vendor A's product or Vendor B's product. It's a custom-built... thing. A Frankenstein's monster. Neither vendor is fully accountable for it because neither vendor truly owns it. And when it's time to upgrade? Good luck. You have to coordinate a three-way dance between both vendors and your integration team, praying that a change on one side doesn't bring the whole house down.
I've seen this movie before. A big project fails. Millions of dollars are wasted. Everyone looks around for someone to blame. The post-mortem reports talk about
"integration challenges" or "governance issues." But the root cause was there from day one: we made a political decision and expected a technical miracle.
But Wait — Doesn't Multi-Vendor Work Sometimes?
Yeah. It does. For commodities.
Need laptops? Buy from three OEMs. If Dell disappoints you, go Lenovo next cycle. No drama. Need office chairs? Same thing. Even some SaaS tools that live on their own island—email, project management, file storage—can handle vendor diversity just fine.
The key word there is "on their own island." A commodity doesn't need to deeply integrate with everything else to do its job. It works standalone. You swap it out, life goes on.
But a core enterprise platform? A BSS stack, an ERP, a network orchestration system? That's not a commodity. That's the circulatory system of your business. Everything flows through it. Everything depends on it. You can't just swap half of it out like changing a lightbulb.
And here's the thing that really gets me. Unless these vendors are building their stuff to a common architectural standard, the integration problem isn't just hard—it's structural. It never ends.
In the telecom world, there's something called ODA—Open Digital Architecture, developed by TM Forum [6]. It's basically a blueprint that says: "Hey, if everyone builds their components this way, with these standardized APIs, things can actually plug and play." Vodafone adopted it and saw digital sales jump by over 50% [3]. That's what happens when interoperability is designed in, not bolted on.
But when vendors don't follow a common standard? When each one builds to their own proprietary architecture? You're not integrating. You're performing surgery. Constantly. On a patient that's awake and running your business.
So, What Are We Supposed to Do?
This is the part where, as an architect, I feel like I have to have an answer. And the answer isn't to just throw up my hands and say it's all broken.
The job of Enterprise Architecture isn't to recommend we use two vendors for one solution just to spread the love. That's not resilience. That's abdication of responsibility.
The job is to make sure the solution we choose is resilient. Period. Full stop.
A single, solid, well-built solution from a vendor you can trust—a real partner—is a thousand times more resilient than a fragile patchwork of two or three systems that secretly hate each other.
Resilience isn't about how many vendors you have in your portfolio. It's about whether the system actually works when it's under stress. Can it handle failure? Can it recover? Do you know who to call when it breaks? With a single solution owner, the answer is yes. With two, it's... maybe.
This is a People Problem, Not a Tech Problem
If we want to fix this, we have to stop pretending it's a technology problem. It's a people problem. It's a process problem. It's a culture problem.
It means we have to get brutally honest about how we choose vendors.
And this is where it gets uncomfortable.
I've been in the rooms. I've seen the decisions get made. We have to stop letting personal bias drive the bus. Stop picking a vendor because you know a guy who works there, or because you hope to work there yourself one day. Stop blocking a vendor—even if they're the best fit—because you had a bad experience with their sales guy five years ago. That isn't professional. It's petty.
And for God's sake, can we stop pretending that the cheapest option is the best one? It almost never is. The real cost of a solution isn't the price on the contract. It's the total cost of owning and operating that thing for the next five to ten years. The cheap option with the massive integration bill and the constant operational headaches is a financial trap.
Our job is to pick the best solution, not the cheapest one, not the one from our friend, and not the one that makes the most internal stakeholders happy. The best one. The one that works.
Let's Just Call It What It Is
Look, I get it. The real world is messy. Decisions are made for reasons that have nothing to do with technology. Politics are real.
But we, as technical leaders and architects, have a responsibility to speak the truth, even when it's not what people want to hear.
Splitting a single solution across two vendors isn't a resilience strategy. It's a political compromise. It's "feeding the village." And it creates systems that are brittle, expensive, and a nightmare to operate.
I'd rather have one throat to choke when things go wrong. One partner who is fully accountable for the end-to-end solution. One kitchen, one recipe, one meal.
Maybe that's just the old ops guy in me talking. But after all the 3 AM calls, I can tell you this much: simplicity is the ultimate form of resilience.
Just my two cents. I'm still learning. What do you think? Have you lived this nightmare too?
I've read this information as a reference:
- Husar, L. (2026, January 20). The Hidden Cost of Multi-Vendor IT Programs. Medium. https://medium.com/@husar.lavinia/the-hidden-cost-of-multi-vendor-it-programs-0a92e1475603
- Ross Video. (2024, July 24). 8 Expensive Challenges of Multivendor Environments. https://www.rossvideo.com/blog/8-expensive-challenges-of-multivendor-environments/
- Uferer, C., Goddard, M., & Papadopoulos, M. (2024, December). Open Digital Architecture: The Next Frontier for Telecom Operators. Arthur D. Little. https://www.adlittle.com/en/insights/viewpoints/open-digital-architecture-next-frontier-telecom-operators
- Dwara, V. S. (2024, July 8). Leveraging TOGAF Principles for an Effective Vendor Selection Framework in Enterprise Architecture. LinkedIn. https://www.linkedin.com/pulse/leveraging-togaf-principles-effective-vendor-selection-dwara-wuxfe
- Kaspersky. (2025, August 4). Over Half of Security Experts Overwhelmed Managing Cybersecurity Tools from Multiple Vendors. https://www.kaspersky.com/about/press-releases/over-half-of-security-experts-overwhelmed-managing-cybersecurity-tools-from-multiple-vendors
- TM Forum. Open Digital Architecture (ODA). https://www.tmforum.org/open-digital-architecture/
- TM Forum. About Open APIs. https://www.tmforum.org/open-digital-architecture/about-open-apis/
