A manifesto
Architecture is employee experience.
A grounded flight. A stalled shipment. A manager staring at a schedule she cannot trust. Nobody calls these software problems. After nearly two decades across airline technology, logistics, healthcare, and workforce platforms, I have found that they usually are. These are the ten principles I build by.
01
Friction never disappears. It picks a different victim.
Complexity in an enterprise stack is conserved. If the architecture does not absorb it, somebody downstream does: a scheduler reconciling two systems by hand, a manager double-checking numbers she cannot trust, a support agent apologizing for a record that never synced. The question is never whether the complexity exists. It is who ends up carrying it.
02
Every legacy system has a shadow org chart.
Around every aging system sits an informal structure of workarounds: side spreadsheets, group chats, the one person who knows why the export fails on Mondays. That is human debt, and it is invisible to every inventory you will ever run. Replace the system without mapping those behaviors and you will faithfully rebuild the friction in a newer interface.
03
Employee experience is decided upstream.
The quality of someone's working day is set by integration decisions made years earlier in a room they were never in. A clean screen on top of an unreliable data flow is not a good experience; it is a well-lit one. Fix the flow and the screen gets easier on its own.
04
Judge a system by what it absorbs, not what it displays.
The right measure of architecture is how much exception handling, reconciliation, and ambiguity it resolves before a human sees anything. A system that surfaces every conflict to a person has not solved the problem; it has delegated it to the least-equipped party.
05
Fairness has to be modeled, not assumed.
Most recognition and performance systems measure output without accounting for opportunity. Someone with the best shift, the best territory, or the best inbound flow will win, and the system will call that merit. Separating actual performance from opportunity to perform is a data modeling decision, and it has to be made deliberately.
06
Integration reliability is a people policy.
HRIS, payroll, scheduling, point of sale, property management: when these agree, staff trust what they are told. When they disagree, an organization slowly teaches its people not to trust its systems, and once that lesson lands it is expensive to unteach.
07
Modernization is measured in steps removed.
A modernization program succeeds when a manager's day contains fewer steps than it did before. Not more dashboards. Not more configurability. Fewer steps. If you cannot name the steps you deleted, you refreshed the paint.
08
AI is not software, and planning for it as if it were is the mistake.
Probabilistic systems are not deterministic, not obedient, and not nearly free to scale. Decide up front what an AI system can reach, which of its outputs you will treat as authoritative, what evidence it leaves behind, what an answer costs to serve, and how much of it you genuinely need to build yourself.
09
You cannot prompt your way out of an architecture problem.
A model cannot reliably distinguish your instructions from the untrusted content it reads. Containment is structural: least-privilege access, separating the component that reads from the component that acts, constraining what an output can express, and human review wherever the system can spend, change, or send.
10
Great systems only come from teams that trust each other.
Architecture quality tracks team honesty. Engineers who can say 'this design will not hold' without cost produce systems that hold. Everything above is downstream of that, which is why I measure myself as much by the leaders my teams produce as by what we ship.
Cite or continue
Quote any of this with attribution to Anil Kumar Karumuru. The research behind principles 08 and 09 is published in the Global Business & Economics Journal and the Hampton Global Business Review.