10-Second Overview
Tactical fixes keep things running. Systems thinking stops the same issues coming back wearing a different hat.
| Approach | Best for | Risk |
|---|---|---|
| Whack-a-mole | Live issues, cutover, BAU containment | You end up fixing symptoms on repeat |
| Systems thinking | Recurring problems, design, migration planning | Takes more thought and a bit more patience |
Enterprise Platforms and the Abstracted Data Layer
Increasingly, enterprise applications are whole-of-business platforms that sit on top of an RDBMS, with an application layer that abstracts — and sometimes obscures — how data is actually structured and used.
Whack-a-Mole : Systems Thinking
Good delivery isn’t choosing one — it’s knowing when to switch gears.
Whack-a-Mole vs Systems Thinking
Two ways of solving problems. One feels productive. The other actually is.
| Dimension | Whack-a-mole 🐹🔨 | Systems thinking 🧠🔗 |
|---|---|---|
| Focus | Symptoms | Structure |
| Time horizon | Immediate | Short + long term |
| Behaviour | Reactive | Deliberate |
| Outcome | Recurring issues | Stability |
| Effort | Repeated bursts | Front-loaded thinking |
Whack-a-mole treats outputs as problems.
Systems thinking treats structure as the problem.
Whack-a-Mole or Systems Thinking?
A practical delivery view on the difference between repeatedly fixing what just broke and stepping back long enough to understand why it keeps breaking in the first place.
The pattern
Spend enough years in delivery and a pattern turns up with clockwork reliability. It is rarely the tooling that gives the game away. It is the behaviour around the problem.
Something fails, so we fix it. Then something adjacent fails, so we fix that. Then another little gremlin pops its head up and gets the same treatment. Before long, the whole thing starts to resemble a professional-grade game of whack-a-mole.
To be fair, that instinct is not stupid. In the right context it is exactly what you want. If an interface is wobbling in production, a cutover is live, or BAU is threatening to spill tea all over the carpet, quick containment matters. You do not convene a philosophy seminar while the building is on fire.
Where it starts to creak
The trouble starts when the short-loop fix becomes the permanent operating model. That is when teams stop resolving issues and start orbiting them.
| What you see | What is really happening |
|---|---|
| Data fixes applied again and again | Upstream capture or ownership is still wrong |
| Interfaces repeatedly patched | Sequence, dependency, or state management has not been understood |
| Field lengths trimmed to fit | Nobody has asked why the value grew or whether the target definition is still valid |
| Reporting mismatches corrected manually | Lineage is weak and the system is quietly telling you so |
Each individual fix may be perfectly sensible. The problem is not the fix in isolation. The problem is the repeated pattern. The system is trying to tell you something, and nobody is listening because everyone is busy being productive.
Systems thinking, minus the jargon fog
Systems thinking is not mystical. It is not a room full of people drawing loops on whiteboards to feel important. At its simplest, it is just asking a better question:
Not as an academic exercise. As a delivery question.
Instead of stopping at the visible event, you follow the chain. What triggered it? What state allowed it? What upstream behaviour fed it? What downstream behaviour does it trigger next? That is the shift from reacting to events toward understanding structure.
The practical difference
| Situation | Whack-a-mole response | Systems thinking response |
|---|---|---|
| Data truncation | Trim and load | Check source definition, business use, and downstream impact |
| Failed integration | Retry the job and watch it nervously | Examine sequencing, dependency, and state transitions |
| Duplicate records | Deduplicate the batch | Review creation logic, key strategy, and ownership |
| Reporting mismatch | Adjust the report to match expectations | Trace lineage from extract through transform to load |
The delivery reality
Most programmes do not fail because people lack the intelligence to think systemically. They fail because the environment does not give them the room.
| Pressure | Typical effect |
|---|---|
| Compressed timelines | Teams fix what is visible, not what is structural |
| Late or partial data | Workarounds become normalised |
| Environment mismatch | Defects are treated as isolated incidents rather than symptoms |
| Stakeholder pressure for visible progress | There is little appetite for stepping back to understand cause and effect |
So teams do the sensible thing. They fix what is in front of them. Fair enough. The risk is that, over time, the fixes become the architecture.
A more balanced approach
This is not a sermon against tactical fixes. There are moments when tactical fixes are precisely the right answer. The point is to know when to stay in that mode and when to change gears.
| Mode | When it is useful | What good looks like |
|---|---|---|
| Whack-a-mole | Live incidents, cutover windows, BAU containment | Fast, controlled fixes with minimal collateral damage |
| Systems thinking | Recurring issues, design phases, migration planning, integration hardening | Root cause addressed, pattern understood, repeat failures reduced |
A familiar example
Take something apparently small, like a field length mismatch during migration.
The quick fix is obvious enough: trim the value, flag the record, move on. In some scenarios, that is entirely reasonable. No drama. No need to redesign Western civilisation over one awkward text field.
But if the same issue keeps turning up, then the question changes. Why was the field extended? Is the target definition wrong, or the source uncontrolled? Who owns the rule? What else breaks if the field is changed properly? That is the moment when you stop patching and start shaping.
What this looks like in practice
| Principle | Practical meaning |
|---|---|
| Model first | Understand the shape and meaning before moving data around |
| Map consciously | Do not assume equivalence just because labels happen to match |
| Modify carefully | Change structure once, properly, and under control |
| Prove it | Use reconciliation, lineage, and traceability rather than good intentions |
None of this is exotic. It is mostly discipline, with just enough humility to accept that the system usually knows more than the incident ticket does.
The honest bit
Systems thinking does not always win. Sometimes there is no time. Sometimes the system is temporary. Sometimes the cost of a proper structural fix is simply not worth it.
That is fine, provided it is a conscious trade-off rather than a reflex. Pragmatism is not the problem. Unexamined habit is.
Seminal conclusion
In real delivery, most teams sit somewhere between the two. They stabilise what is breaking, step back when patterns emerge, and fix properly where it matters.
Redesign the board when it keeps coming back.
Closing Thought
A pragmatic end note on when tactical fixing has outstayed its welcome.
A final thought, or perhaps a mildly irritated one dressed up as wisdom.
If the budget gets blown out of the water, there is a fair chance whack-a-mole was not the right approach. Tactical fixes can be perfectly valid for stabilising a live issue, getting through a rough cutover window (execution not solution design), or stopping BAU from wandering into the road. But once the same class of problem keeps returning, each “quick fix” starts charging interest.
I have seen carve-outs where the knowledge was built up during the project, only for each phase to be delivered differently for each carve-out. You can usually find reasons for it in the moment — different pressures, different people, different timing, different local decisions. None of that is entirely irrational. But it is frustrating when you are trained to think in terms of systems, patterns, reuse, and controlled learning.
From that angle, it feels like paying repeatedly to relearn your own lessons. Not ideal. Particularly when the whole point of doing this sort of work properly is to get better as you go, not merely busier.
| Pattern | What it tends to mean |
|---|---|
| Each phase solved differently | Learning is staying local rather than becoming delivery method |
| Budget keeps drifting upward | The cost of repeated symptom-fixing is overtaking the cost of proper design |
| Teams remain busy but not progressively faster | The programme is reacting well, but learning poorly |
| Known issues return in new clothes | The structure has not changed, only the symptom has |
That is really the point. Whack-a-mole has a place, but it should be a mode, not a doctrine. Useful in the moment, expensive as a worldview.
The diplomatic version is this: sometimes delivery has to be tactical. The grown-up version is this: if the same patterns keep returning, and the money keeps going with them, then the system is asking for more than another swing of the hammer.
Learn once if you can.
And if the budget is drowning, stop blaming the mole.
In practice, delivery rarely lives at either extreme. It is usually a blend — moments of rapid, tactical fixes alongside deliberate, structured thinking. The reality is not whack-a-mole or systems thinking, but a constant interplay between the two. The skill lies in recognising when to stabilise quickly and when to step back, understand the system, and change the conditions that created the issue in the first place.
Don’t rely on me — CoPilot has been geared up for Microsoft products and their positioning. So I asked it to verify my assertion for Dynamics, SAP, Oracle
A quick reality check. Tooling advice, especially from embedded assistants, tends to lean toward the platform it sits within. That is not inherently wrong — but it is not neutral either.
Worth keeping a slightly wider lens when assessing migration shape, risk, and architectural choices.
| Platform | Nature of Migration | Systems Thinking Need | Typical Whack-a-Mole Risks | Key Architectural Notes |
|---|---|---|---|---|
| Microsoft Dynamics 365 | Modular cloud migration across Finance, Sales, Operations and related apps | High — multiple interdependent apps, Power Platform, integrations | Reactive fixes to flows, plugins, dual-write and point-to-point integrations; recurring sync and state issues | Dataverse-centric model, API-first, tightly aligned to Azure and Power Platform; requires clear integration boundaries and data ownership |
| SAP S/4HANA | Transformation from ECC or legacy SAP to HANA-based S/4 | Very High — fundamental shifts in data model, processes and custom code | Reconciliation gaps (Universal Journal), broken custom logic, integration failures, process gaps from simplification | In-memory HANA model, Universal Journal, Clean Core approach; encourages process redesign over technical carry-forward |
| Oracle ERP Cloud | Cloud modernisation from EBS or other ERPs to SaaS ERP | High — integrations, data migration and release cadence drive complexity | Integration breakage after updates, legacy data inconsistencies, over-extension via PaaS causing regression | Standardised SaaS model, quarterly releases, Oracle Integration Cloud; extension over customisation |
The common thread is not the platform. It is the behaviour around it.
If the approach leans too heavily on reactive fixes, the platform choice will not save it.