The most complicated IT environments I’ve worked in weren’t built that way on purpose. They got there through a sequence of reasonable decisions made by reasonable people under real pressure. A cloud provider added because the incumbent couldn’t hit a latency requirement. A point solution brought in because a business unit needed something fast. A managed service layered on when headcount froze. Each one made sense at the time. The problem comes later, when twenty years of reasonable decisions turn into an environment no one has fully stepped back to understand.
The ones carrying the most complexity aren’t usually the ones that made the worst decisions. They’re the ones that grew the fastest, had the most demands on their IT teams or operated in environments where buying was distributed across business units. The complexity is, in a strange way, a byproduct of success. That doesn’t make it any less expensive to carry.
How complexity builds
When I was leading one of the largest cloud and managed services practices in the country, I started keeping informal track of how enterprise clients described their own environments during the first few meetings we’d have with them. Most of the time, the same terms came up in all of our conversations: legacy, inherited, technical debt and almost always “we need that for compliance” or “that team won’t let it go.” The complexity extended well beyond the technology itself. It was tied to people, processes, compliance requirements and the realities of how the organization operated.
What I’ve observed over time is a pattern that plays out in roughly three phases, though nobody experiences it as phases when they’re living through it.
The first is the accumulation phase. This is the normal course of IT operations: you add capability as the business demands it. A SaaS application gets added because a business unit needed it fast. A new cloud region gets stood up because a regulatory requirement demanded data sovereignty. A point solution fills a gap in a platform that hasn’t been updated in three years. The organization is growing through M&A, acquiring many new contracts and vendors in the process. None of these are bad decisions. But each one adds an integration surface, a contract, a support relationship and a line item to the budget.
The second phase is drift. This is where team members start working around the official channels (IT, Financial, Legal or Procurement) rather than through it, because the official channel is too slow or too complicated to serve their actual, or perceived, needs. Shadow IT gets a bad reputation, but in most of the organizations I’ve worked with, it’s less about rogue behavior and more about rational people solving real problems with the tools available to them. The official tools just often aren’t those tools.
The third is what I think of as the lock-in phase. By this point, the environment has so many interdependencies, some documented and many not, that making a significant change feels genuinely risky. The technical debt is high with perceived high costs to modernize. Building the case to move requires more stakeholder engagement and analysis than simply comparing the existing approach to a more modern one. Every potential simplification comes with a list of downstream impacts that nobody is fully confident about, so the environment stays complicated and the maintenance burden grows.
The Flexera 2024 State of the Cloud Report found that organizations waste an average of 28% of their cloud spend, a number that has held remarkably consistent across multiple years of the same study. In my experience, a meaningful portion of that waste isn’t irresponsible purchasing. It’s the cost of maintaining overlapping capabilities that were acquired at different points in time, for reasons that made sense then and are hard to untangle now.
Why simplification efforts stall
I’ve watched a lot of simplification initiatives get announced and then shelved. The reasons are usually practical, not political, though the politics can make the practical harder.
One of the biggest problems for teams is that nobody has a complete view of their environment. I’ve seen consolidation initiatives take longer than anticipated because every time a team thought they had their dependencies mapped out they found another application or workflow that wasn’t included in the initial discovery. Nobody did anything wrong in those instances. The environment had just evolved faster than the documentation, which is what happens when you’re adding capability under pressure for years at a time.
This is more common than organizations want to admit. Gartner has found that shadow IT accounts for 30 to 40% of IT spending in large enterprises, composed of tools acquired by business units, spun up for a project and never decommissioned, or inherited through an acquisition that never got fully integrated. When you’re trying to simplify something you can’t fully see, the margin for error is wide.
The second problem is that simplification affects real people inside the business. Somewhere in the organization, there is someone who is dependent upon the application or process that you want to eliminate. This could be either a report or workflow that is tied to a database that was supposed to be shut down two years ago, or it could be a team that has customized a platform in such a way that they will not be able to migrate when the time comes. Real simplification requires working through those dependencies carefully, which takes time and coordination that most IT teams don’t have in abundance while also keeping the lights on.
The third problem is that the business case is hard to make in advance. The cost is real, but it does not always show up in one clean line item. It shows up as slower incident response times, higher vendor management overhead, more onboarding time for new IT staff and missed windows to adopt newer capabilities. All of these elements highlight the risk that grows as these elements continue unaddressed. Those costs are hard to aggregate into a number that justifies a multi-quarter consolidation project, so the project often doesn’t get funded until something breaks badly enough to force the issue.
What works in the real world
I want to be careful here, because there’s a version of this advice that sounds simple and isn’t. “Just rationalize your vendor portfolio” is easy to say. Doing it in a way that doesn’t create new problems requires discipline.
The first thing that’s worked consistently in the environments I’ve been close to is starting with the contract layer, not the technical layer. Most organizations have a better view of what they’re paying for than what they’re running. A thorough contract and spend audit will surface redundancies faster than a technical architecture review, because the money trail is usually cleaner than the configuration trail. It won’t give you the full picture, but it gives you a starting point grounded in something real.
The second is building the map before you touch anything. Organizations that have executed well on simplicity spent significant amounts of time, often months, conducting an inventory of the current state before determining what to consolidate. This is unglamorous work and will not show up on the board update as a major accomplishment, but that’s precisely what distinguishes successful consolidation from stalled or failed consolidation.
The third is staging the work around business cycles rather than IT timelines. I’ve seen technically sound simplification projects fail because they were scheduled without regard to when the business could absorb the risk. Migrations during quarterly close processes, architecture changes during peak retail seasons: these are the kinds of decisions that undermine confidence in IT’s judgment, regardless of the technical merits.
The goal isn’t a simple environment for its own sake. A mature enterprise IT environment is going to carry some complexity, because the business it supports is complex. What you want is an environment where every tool, vendor, platform and contract has a clear purpose. You know who owns it, what it costs and what risk it creates. Most of the organizations I’ve worked with aren’t that far from that state. They just need to stop adding before they can start subtracting.