Why Are We Still Designing IT Like It's 2012?
Let’s talk about complexity in IT. Not the fun kind—like building a Raspberry Pi-powered coffee machine or arguing over whether Terraform should be capitalized. I mean the kind of complexity that slows teams down, bloats your stack, and makes security people question their career choices. You know the type: five backup platforms, three monitoring tools, two storage vendors “for resilience,” and a bunch of scripts someone wrote in 2019 that nobody’s brave enough to touch. We tell ourselves it’s “best-of-breed,” “cloud-first,” or my personal favorite—“strategic.” But let’s call it what it is: chaos without any direction. Enter Conway’s Law (aka the Mirror You’ve Been Avoiding) Melvin Conway dropped this gem in 1967: “Organizations design systems that mirror their own communication structures.” Still true. Still brutal. If your company has six teams that don’t talk to each other except through passive-aggressive Jira tickets, your architecture is going to reflect that—fragmented, redundant, over-engineered, and impossible to secure. Conway’s Law isn’t just a quirky observation. It’s a diagnostic tool. If your architecture feels like a group project gone off the rails, chances are it’s because your org works that way too. Cloud Chaos: Now with More Vendors! And just when you thought it couldn’t get worse—we bring in the cloud. Or clouds. Somewhere between “cloud-first” and “cloud-only,” we lost the plot. We started treating hyperscalers like interchangeable gas stations: need compute? Just pull over at the nearest one. We’ve seen it: Migrations from AWS to Azure to GCP like it’s some weird tech pilgrimage Applications lifted and shifted with zero refactoring Hybrid architectures that “just sort of happened” Look, the cloud’s not the problem. I like cloud and I believe it is here to stay. But designing 100% for the cloud without actually understanding your why? That’s Conway’s Law, just with bigger invoices. Even worse? Bouncing between cloud providers because someone read a Forrester report and got nervous about lock-in. That’s not strategy—that’s cloud-induced panic. The Two-Vendor Lie We Keep Telling Ourselves Ah yes, the old two-vendor strategy. Meant to be safe. Designed to reduce dependency. What it really does? Doubles your complexity and halves your team’s sanity. Two vendors = two playbooks, two consoles, two support teams blaming each other It’s not more resilient—it’s just more confusing Gartner even calls it out: more vendors = more risk, not less If you think managing multiple tools with overlapping functions is safer than consolidation, congrats—you’ve just invented the world’s most expensive “Oops” button. Manual ≠ Secure. It Just Feels That Way Let’s talk about the weird rituals we still do in the name of security: Manually copying data to “safe zones” Turning off network access like it’s a security blanket Spinning up siloed sandboxes to avoid risk It’s not protection. It’s procrastination. Manual controls introduce human error, waste time, and don’t scale. If your “strategy” depends on someone remembering to toggle a firewall rule every Thursday, you're not secure—you’re just lucky. And outsourcing that chaos to a vendor doesn’t make it better. Handing over management to a provider that’s Frankensteined a bunch of loosely integrated tech with bailing wire and hope isn’t a strategy—it’s just renting someone else’s mess. If there’s no real roadmap, no cohesion, no architectural vision—it’s not a partnership. It’s a future support ticket waiting to happen. Hybrid Cloud Needs Purpose, Not Permission Hybrid isn’t a backup plan. It’s a design decision. Too many shops end up hybrid by accident—because apps don’t refactor, budgets don’t stretch, or politics get in the way. The result is an environment that’s technically working but operationally exhausting. A good hybrid strategy is opinionated. You should know: What runs where (and why) How data moves What your north star architecture looks like If you don’t have answers to that? You’re not doing hybrid—you’re doing hope. So What Do We Do About It? We simplify. On purpose. Relentlessly. Design like a startup, not a committee. Keep the stack lean. Less is more when you have tools that actually integrate. Use Conway’s Law in reverse. Want systems that work together? Build teams that do too. Break silos before they become dependencies. Treat cloud like architecture, not an escape route. Cloud is amazing if you design for it. Otherwise, it’s just someone else’s complexity in your billing statement. Stop solving people problems with platform purchases. Most complexity isn’t technical—it’s cultural. No vendor can fix your org chart. Final Thought: Complexity Is a Tax. Stop Paying It. Every extra platform, every vendor “just in case,” every manual handoff is a tax. And it’s compounding interest on your ability to execute. If you want to move fast, secure your data, and stay sane—you’ve got to design with purpose. That means fewer tools, better alignment, and architectures that reflect how you want to operate, not how your politics force you to. You want resilience? Start with intention. But what I’m really curious about is your perspective: How are you dealing with complexity? Is hybrid working for you—or just holding you hostage? Have you successfully simplified your architecture without sacrificing flexibility? Let's make this a real convo—not another “cloud is the answer” thread. —Zane Allyn
