I work today with an architecture that, honestly, nobody designed. That doesn't mean nobody ever made architectural decisions - quite the opposite, hundreds of them were made over the years. A new system got added. An integration was built. Some exception had to be handled. A new product showed up. Someone needed data faster. Another team had to hit a deadline. Each of those decisions probably made perfect sense at the time.
It's only years later, when you look at the whole picture, that the question comes up: who actually designed this? And very often the answer is simply - nobody.
Architecture Can Just Grow
Large systems rarely start from scratch. An organization already has customers, products, processes, data and people - you can't pause the business for a few years, draw the perfect architecture, and then hit "start" again. So architecture grows together with the organization. One system is good for CRM, another shows up for billing, an integration layer becomes necessary, later a new sales channel comes along. One process doesn't fit the standard solution, so an exception gets created - and then that exception gets its own exception.
Enterprise architecture is often just an organization's history, written in systems and integrations.
Strange Solutions Sometimes Have Pretty Reasonable Origins
It's easy to walk into an existing environment and say "this makes no sense at all" - I've reacted that way myself plenty of times. In one system I worked on, customers could pay a bill using a specific payment method that carried a fixed fee. The problem was, we also sold products that cost exactly that fee amount. Turning off the payment method wasn't an option, so a mechanism was built that simply didn't charge the customer at all for very small amounts.
Sounds absurd. But economically, it made sense - the company would never have seen that money anyway. Looking only at the code, you'd call it a completely incomprehensible edge case. Only once you know the business context do you start to understand why it exists at all.
With existing architecture, "why?" is often a more important question than "how do we fix this?"
The Most Expensive Workarounds Often Start Innocently
In another case, a portion of invoices, for some reason, weren't being processed correctly. The problem had existed for a long time, and the organization had simply learned to live with it - one person spent practically an entire day manually fixing data in enormous Excel spreadsheets, so large that the computer would nearly freeze on every lookup. The natural idea was to automate the process with RPA. So we had a broken process, a massive spreadsheet, and a person spending hours a day doing manual repair work - and the proposed fix was to build a robot to do the same thing.
As it happened, the person responsible for that process disappeared from work for a few months, and someone had to take over. It landed on me. First I automated part of the work with simple scripts - what used to take about ten hours started running in a few seconds. But only later did the real question show up: why are we even doing this work in the first place?
Once we tracked down the root cause, it turned out we didn't need ten hours of manual work, a script, or RPA. We needed to remove the cause. It's a good example of how architecture and processes can quietly accumulate solutions to problems we stopped questioning a long time ago.
Lack Of Ownership Leaves Traces
Time pressure obviously shapes architecture, and so does shifting strategy. But in my view, the biggest problem is the lack of long-term ownership. If someone owns a system or a process for years, they can say "fine, we'll make this compromise now, but we'll revisit it in six months." They can keep an eye on the consequences, remove things that stopped making sense, and think beyond a single rollout.
Without ownership, an organization is great at adding things and much worse at removing them. A new system gets a project owner. An old system often doesn't get anyone responsible for shutting it down. A new integration has a deadline. Retiring three old integrations usually doesn't. As a result, complexity grows almost automatically.
Sometimes Even The Target Architecture Has No Owner
One of the more interesting cases is when an organization actually has an official target architecture. On the diagram, everything looks great: system A owns one area, system B owns another, integrations get simplified, old solutions disappear. The problem shows up a few years later, when you start asking: why did we actually choose these particular systems? Who made that call? What alternatives were considered, what were the assumptions, what problem was this supposed to solve?
And nobody can answer anymore. The decision still exists; the presentation that justified it probably doesn't. The people who made it have moved on. Market assumptions have changed. Licensing costs have changed. Company strategy has probably changed too. But the organization keeps chasing the "target architecture," because... it's the target architecture.
Architecture stops being a conscious choice and becomes a piece of history nobody wants to question.
Evolution Before Revolution
When I run into a complicated systems landscape, I don't start by designing something new. First I talk to the developers - they very often have deep knowledge of why something works the way it does, and usually some business knowledge too, though not always the full picture. Then I try to document it: a systems diagram, data flows, processes, dependencies. Only after that do I start looking for places worth improving.
I'm definitely more of a believer in evolution than revolution. Not because transformations are bad - sometimes an organization genuinely reaches a point where a big change is needed. But a revolution carried out without understanding the history of the existing system has one dangerous tendency: it's very easy to rebuild all the same old problems, just in new technology.
Software Remembers An Organization's History Remarkably Well
Code remembers a strategy shift from seven years ago. An integration remembers a customer who's long gone. A batch job remembers a process nobody knew how to do differently at the time. A database field remembers a requirement everyone forgot about. A system that "can't be turned off" often remembers a business decision made by people who left the company a long time ago.
Most enterprise complexity is organizational debt, expressed as software.
And that's exactly why you can't get rid of it just by changing the technology.
Final Thoughts
When I look at a complicated architecture diagram today, I don't start with "how do we simplify this?" I try to answer two other questions first: where did all this actually begin, and who in the organization genuinely understands why it looks the way it does? Only after that can you start removing things.
Because sometimes something looks like bad architecture - and sometimes it really is. But sometimes what you're looking at is fifteen years of business history, written in software. And if you don't understand that history, it's very easy to delete something that looks like a problem... but was actually the solution to a problem we no longer even remember existed.