The Architecture Diagram Nobody Wants to Draw

ReadStats & TrendsBest PracticesFun Yet Informative
Written By Jeff Winter

“Hey Jeff, will you take a look at our architecture?”

“Sure. Where is the diagram?”

“You’re holding it.”

Oh. 😬

That explains why sometimes it is hard for me to hold my true emotions on the inside. Apparently my face had already completed the assessment. 😂

There is an on-premise server, a legacy system, an old router, several spreadsheet integrations, a third-party tool nobody wants to claim, and something in the cloud. We are not entirely sure which cloud, but “somewhere” has been added to the documentation, so that feels promising. The picture is exaggerated. The underlying situation really is not.

I’m not a technical architect. I’m a strategist who dips far enough into the weeds to start asking annoying questions: Where does that data actually originate? Which system is authoritative? Who owns this interface? What breaks if we turn that off? Why does this spreadsheet have macros, business logic, seven tabs labeled “DO NOT CHANGE,” and apparently more operational authority than the ERP?

Small tangent: I do not hate spreadsheets. Excel has probably delivered more business value per dollar than most enterprise software. The problem starts when a spreadsheet quietly becomes an application. It has logic, dependencies, manual inputs, unofficial owners, no testing environment, and one person named Dave who understands why column AH cannot be touched. Then Dave retires, but the spreadsheet does not.

We call a lot of this technical debt, which makes it sound almost respectable. Some debt is intentional. A team knowingly takes a shortcut to hit a deadline and plans to clean it up later. Fine. But much of the complexity I see was never “borrowed.” It accumulated through acquisitions, local decisions, emergency fixes, duplicate systems, vendor changes, and years of adding the new thing without removing the old thing. The scale is bigger than most executives realize. Salesforce’s 2026 Connectivity Benchmark research found that enterprises now average 957 applications, up from 897 the year before, while only 27% are integrated. That research covered 1,050 IT leaders at organizations with at least 1,000 employees. It is cross-industry data, not manufacturing-specific, and I would not read it as 957 equally important systems sitting neatly on one architecture diagram. I read it as evidence that application proliferation is normal while coherent integration is much less so.

And the mess has a real price. McKinsey’s 2025 analysis of enterprise technology economics says companies pay an additional 10% to 20% on top of the cost of technology projects to address technical debt. So we approve a $10 million program, celebrate the investment, and may quietly consume another $1 million to $2 million negotiating with decisions made years ago.

I think we routinely misclassify that money. We call it implementation effort, but much of it is investigation: tracing an undocumented interface, identifying the real source of a field, rebuilding logic hidden in a spreadsheet, finding credentials owned by someone who left in 2019, testing whether the ancient device still carries production traffic, or figuring out why the old router has a handwritten note saying “DON’T TOUCH.”

Here is the part I care about as a strategist. Those costs rarely sit next to the system causing them. They are distributed across future projects, engineering hours, cybersecurity exceptions, consultants, delayed launches, and the extra meetings required because nobody is completely sure what is connected to what. The old system therefore looks cheap because its cost is being charged to everything around it. That creates a bad decision loop. Replacing the system has a visible price tag, executive sponsor, project plan, and risk. Keeping it appears cheap because the architecture sends the bill somewhere else. So the organization keeps it, and the next project pays the tax again.

There is another rabbit hole here that I think matters: we tend to measure systems individually while complexity exists between systems. An ERP can look fine on its own. A historian can look fine. A warehouse system can look fine. Thirty custom interfaces can each look tolerable. The problem appears when you try to change one thing and discover the dependency chain running through all thirty-one. That is why an inventory of technology assets is useful but still does not tell you what your architecture actually costs you.

This is also why I am increasingly skeptical when somebody tells me a legacy application is “fully depreciated” or “basically free.” That might be true from an accounting perspective. Strategically, I care much more about what happens when we need it to behave differently. How many people have to investigate it? How many other systems have to change with it? How many exceptions have accumulated around it? And how often does a perfectly reasonable new idea become economically unattractive because the existing environment makes implementation absurdly difficult?

I am increasingly convinced that one of the most useful questions in technology strategy is not, “How much does this system cost to run?” It is, “How much does this system increase the cost of changing everything that touches it?” Those are very different numbers, and most companies are much better at measuring the first. Maybe the most expensive system is not the one with the largest license bill or maintenance contract. It is the one that makes every future decision slower, every integration harder, and every change more expensive.

References:

Jeff Winter
Previous

When Will Technology Actually Matter? The Two Clocks of Industrial Innovation
Next

A Fine Vintage of Bad Transformation Decisions