Enterprise systems are usually simpler than yours.
That is not what most people expect to hear. The assumption is that large organisations are where complexity lives — layers of process, legacy decisions, accumulated technical debt. And they have all of that. But they also have something smaller organisations rarely develop: someone whose job it is to say no.
Governance, architecture review, a CTO with standards and the authority to enforce them. Constraints that force clarity. Nobody builds their own special solution because the system won’t allow it.
Free · 4 minutes
Do you know where AI is already being used in your business — and what it can see?
Fourteen questions on shadow AI, data exposure, oversight, and governance debt — the gap between how fast AI is arriving and how much control you have over it. Banded finding on screen, full sheet by email.
The small or medium-sized business has none of that. It has ambition, urgency, and developers who solve problems without a framework telling them how. Every decision made in isolation makes sense. The result, in aggregate, rarely does.
What I find
Three patterns appear consistently, often together.
Five ways to price something. What started as commercial flexibility — different rates for different customers, different channels, different deal structures — gets encoded into the system one exception at a time. Each exception made sense when it was added. Nobody counted them. Five pricing models means five code paths, five places for bugs, five things to test, five things that break when the business changes direction.
An overcomplicated deal structure. Complex commercial logic gets handed to developers who didn’t fully understand the business intent, by business people who didn’t understand what they were asking the system to carry. The result encodes ambiguity as rules. The rules interact in ways nobody predicted. The edge cases multiply.
Layers of business logic that should not exist. Workarounds for the workarounds. Conditions handling scenarios that probably no longer occur. Logic that was added to fix something, then logic that was added to fix the fix. Nobody removed anything. The system grew in all directions.
How I explain it
I don’t tell organisations their system is complex. I tell them what simple looks like.
Migrating a product catalogue between systems is usually an afternoon’s work — mapping fields, joining the dots, running a transfer. In a well-structured system, that is what it is.
In a system like the ones above, I arrive and find that three other systems need to be corrected before migration can begin. The pricing logic is inconsistent between the webstore and the accounts platform. The ERP holds a deal structure that no longer matches how the business operates. None of it can move until it is resolved.
The client does the arithmetic themselves.
Who built it
Usually the person still in charge.
The founder, the original developer, the head of product who grew into a leadership role. The system reflects their decisions and their thinking at each stage of growth. Pointing at the architecture is pointing at them.
This is why the conversation has to start with cost, not quality. The original decisions were not wrong — they solved real problems at the time. What matters now is what it costs to carry the complexity forward. Every new feature takes longer than it should. Every integration requires negotiation with existing logic. Every developer hired needs months before they can be trusted to touch the core.
The system is doing the job. It is also doing it expensively.
A few rules
These are not retrospective criticisms. They are the constraints that prevent the problem from developing in the first place.
One pricing model, with defined exceptions. If you cannot explain your pricing in a single sentence, there are too many pricing models. Exceptions are not architecture. They are debt.
Encode the rule, not the negotiation. Business logic in code should reflect how the business actually operates — not the edge case from a deal three years ago that no longer applies.
Complexity added for flexibility is only valuable if the flexibility is used. If the five pricing paths serve two active scenarios, the other three are maintenance liability.
Before adding logic, ask what can be removed. Good architecture is defined as much by what it refuses to carry as by what it supports.
If a migration is not straightforward, the problem is not the migration. Treat the difficulty as a diagnostic. It is telling you something about the system you already have.
Richard King is CTO at Sixteen Pillars — technical leadership, architecture, and governance for organisations that need it without the overhead of a full-time hire.
Most technology problems are not technology problems. They are control problems.
The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.