A PM's Perspective on Core System Operations Record 3: Configuration is Not the "Optimal Solution" — Architecture as an Accumulation of Decision Making

I am often asked "Why is this structure the way it is?" regarding core systems.
In reality, the current architecture wasn't completed in a single design phase, but was formed through accumulation of responses to real-world challenges: troubleshooting, performance improvements, cost constraints, and organizational circumstances.

In this series, we've been looking at core systems from the perspective of how to manage ongoing operations. In this article, as an extension of that, I'll interpret the current configuration not as an "optimal solution," but from the viewpoint of architecture as a history of decisions.

Configuration is Not a "Design Result" but an "Operational Achievement Point"

When looking at the structure of core systems, many engineers might feel:

• Couldn't we have created a more modern architecture?
• If we organized the dependencies, wouldn't it be simpler?
• Isn't the separation of responsibilities inadequate?
• etc...

The answer is all Yes and simultaneously all No.

Yes in the sense that it's not the "ideal form," and No in the sense that pursuing the "ideal form" is not possible.
When measured against the ideal form in an engineer's mind, the core system configuration can hardly earn a passing grade. This shows that core systems are not designed from an original pristine state, but are entities based on the state of operational achievement points refined through the rough waves of reality.

What exists is not a logical design result, but a structure as a history of decisions arising from various constraints.

Why Can't We Achieve an Ideal Configuration?

The thinking that typically comes to the minds of general engineers and developers is almost always the thinking from a creation standpoint.
It implicitly assumes visibility of all currently manifesting:

• All demands
• All requirements
• All constraints
• All operations

Indeed, if all these were visible, an ideal structure could be built.

However, throughout the process of creating and changing this core system, there has never been a time when all the aforementioned demands, requirements, constraints, and operations were fully visible. Not even once.

We cannot see everything and don't know what the future holds. Yet decisions have been made continuously. The current state of the core system is a history of these decisions. The "ideal form" can only be conceived by fixing a single point in the flow of time.

Furthermore, core systems have unique constraints. That is not stopping the currently running system and its operations. When creating or developing, starting from scratch is hardly permissible in core systems.

• Strong constraints of existing assets (legacy code, operations)
• Migration costs and risks (if creating a new system)
• System and operational downtime tolerance
• Business priorities (business opportunities often take precedence over stable operations)
• Constraints of organization, human resources, and skills (resources are always very limited in non-profit sectors)

Core systems require improvements while considering these factors.

As an engineer, it's correct to feel, "Why has it become such an irrational architecture? We should pursue the ideal form." But at the same time, you must have an answer to the following question:

"The current system and operations may not be ideal, but they're working. What is the value of making it 'ideal' at additional cost?"

Decisions Always Rest on Trade-offs

I want to be clear that I'm not saying we shouldn't or aren't pursuing ideals. We do seek optimal solutions in each situation, within what we can see. However, a state that is optimal across all time frames simply doesn't exist.

I wrote that the state of a core system is a history of decisions.
And it's important to remember that decisions always involve trade-offs.

• Availability vs Cost
• Speed vs Stability
• Simplicity vs Compatibility
• Future optimal vs Current optimal
• etc...

For example, input fields introduced with future scalability in mind might increase complexity and difficulty for operational staff, resulting in unsuccessful operations that fail to achieve the original purpose. Conversely, simplifying input fields might lead to arbitrary operations that degrade data quality.

Accumulation of Local Optimizations Creates the Overall Structure

As operations progress, various new demands and requirements emerge. This is an unavoidable fate for systems that are being used. By definition, core systems are "systems that continue to be used," making continuous modification ("maintenance") essential.

And each modification inevitably involves additions and exception handling. Inevitably.
This is because conflicts arise with existing functions and operations.

There's a need to adapt to existing operations, or minimize impact, while meeting new requirements. This environment easily leads to local optimization. And the accumulation of such local optimizations creates the overall structure.

Another point not to forget is that dependencies created by locally optimized decisions don't easily disappear or can't be removed. For example, suppose there's a situation A, followed by functional expansions B and C. In this case, B is often created based on the existence of function A. And C is based on B. As a result, C depends not only on B but also, in fact, on A.

Dependencies created by a single decision are thus woven into subsequent derivative functions.

The idea of seeking zero-based, drastic overall optimization therefore conflicts significantly with core systems.
If you could halt business activities for several years, such approaches might be possible, but by definition, core systems can't do that.

Even if the state of a core system appears chaotic, it's not "subsequently distorted" but the result of "continuous transformation".

Understanding Configuration Requires Reading "History"

As I plan to detail in Part 4, for example, Class Method's SFA/CRM is divided between HubSpot and Salesforce.

Looking just at this, some might find it puzzling to use two similar SaaS solutions.
Indeed, having two SaaS solutions has created various challenges, both in the past and present.

However, there are various "historical circumstances" behind this.

• Why was that technology adopted?
• What were the constraints at the time of decision?
• Why does this structure continue to exist today?
• etc...

No one can predict the future. History is an accumulation of what were believed to be optimal solutions (decision-making) at each point in time.

Even if the current state isn't ideal, we can't simply discard it. This is because even to discard it, we need a temporary scaffold.

Configuration Improvement is Re-decision-making, Not Redesign

I hope you understand that creating an "ideal form" is almost impossible.
So, should we leave the chaos (= uncool structure) cultivated by historical circumstances as is?

The answer is No.

Imagine cleaning your room for a better understanding.

Your room is probably not in an ideal state.
It bears the marks of a history of accumulated decisions.
Even that cluttered storage box was likely purchased with clear intent and purpose.

Would you abandon such a less-than-ideal room?
Probably not. At the very least, you'd continue to clean it.
And you'd try to improve it little by little.
That's because you're using it.

Each time, you'd refresh the room from the perspective of "what decision would I make now?"
Core systems are doing the same thing.
In other words, improving structure is a daily effort, not "redesign" but "re-decision-making."
This involves reconciliation with various constraints, not just technical correctness.

By the way, a complete overhaul has an impact equivalent to "moving house."
It's easy to imagine that this involves considerable resource consumption and risk.

Summary: Changing the Perspective on Configuration

It's very rare for the current state and configuration of a core system to be purely the result of technical choices.
Instead, in most cases, it's a history of decisions made under various constraints.

The first thing a PM should grasp is the historical context that led to the current configuration and operations.
And be aware that the decisions you make as a PM will also become part of history. Resist the desire to rebuild from scratch. Even if you did rebuild, it would likely result in almost the same historical repetition.

In the next article, I'd like to detail the actual configuration of core systems, the historical context that shaped those configurations, improvement strategies, and more.