AI Translated Document

This document was translated using an AI translation tool.
Due to the nature of AI translation, some sentences or terms may be interpreted differently from the original intent.
There may be mistranslations or inaccuracies, so please refer to the original text or consider additional review if accuracy is critical.
Your suggestion for a better translation would be highly appreciated.

Original Document in Korean

Architecture Is a Structural Solution¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
Draft: June 2018 / Revised: December 2025

[Author’s Intent] This article was written to highlight how failing to view problems structurally—before adding features or choosing technologies—can make complexity spiral out of control.

Executive Summary¶

In software systems, architecture defines the structure of organized processing, even for applications or small modules.
Architecture is not about scale.
Architecture is not a reference point for imitation.
Architecture is not just a diagram for explanation.
Architecture presents a universal solution to common problems in applications/systems.
This approach is different from achieving functional/performance goals at the code/feature level.
The universal basic structure of problem-solving is: 'problem definition', 'root cause analysis', 'solution derivation', 'execution', and 'evaluation'.
General tasks, such as feature implementation or writing manuals, have a single defined problem and goal.
In software architecture, however, the goal is a universal solution to common problems in applications/systems—a collective property.
- For example, an approach like "a solution with 80% universality for 70% of the application's problems."
- Therefore, software architecture must be able to handle situations outside the specification from the start (very different from building architecture).
Thus, solutions provided by software architecture are quite abstract, systematic, and structural.
Abstraction: No specificity. Specifics are given in individual implementations, so architecture only discusses rough procedures.
Systematicity: The result operates as a complete system, so a certain order flows within the architecture.
Structurality: The relationships and dynamics among components in the solution are defined, influencing the overall order—a higher-level concept (like social structure).
Of these, the structural aspect is the hardest.
Architecture is highly summarized, inherently lacks specificity, and cannot lack systematicity due to its results.
So abstraction and systematicity are naturally acquired.
But structural solutions—solving common system problems in the infrastructure, not just implementing features—require deliberate effort.
In well-chosen architectures, the Pareto principle (80/20 rule) is observed: 20% of the infrastructure handles 80% of the work.
Compared to non-infrastructure situations, this means the work scale (labor hours) is reduced by a factor of several to more than ten.
If you hate overtime, structural solutions are the answer.

The Essence of Architecture: Structural Solution¶

Most developers see architecture as a huge structure to be chosen or imitated, thinking that copying a structure will solve many problems. But architecture itself has upper, middle, and lower levels, and even a DLL for a specific service can have its own architecture. This is like how laws are classified by hierarchy: constitution, law, decree, ordinance, rule, administrative rule. In other words, architecture is not determined by scale.

Meanwhile, as names like MSA, Restful, and Flux become trendy, there is a tendency to imitate indiscriminately. But you cannot gain the advantages of an architecture by simple imitation, because architecture is an abstract answer to abstract problems and cannot solve concrete problems directly. If you choose an architecture that does not fit the specific information processing flow of your project, or do not meet external support requirements like organizational structure, architecture can even introduce new problems.

Sometimes, people mistake the diagram for the architecture itself, but a diagram is just a way to convey the abstract order that is architecture. Understanding architecture as a diagram is like looking at the finger pointing at the moon, not the moon itself.

The essence of architecture is not just listing components or choosing a tech stack. Architecture gathers the recurring, common problems a system faces and defines patterns and rules so those problems are handled consistently. Because of this, architecture tends to scale up, but there are also small-scale cases—highly irregular libraries, for example. While individual software using a library may handle only a few forms, the library itself often has a flexible architecture for generality.

Regardless of scale, architecture is characterized by universalizing problems and providing universal answers.

The Basic Structure of Problem-Solving and Architecture¶

General problem-solving has a common skeleton:

Problem definition
Clearly define what the problem is, its symptoms and scope. Set goals and success criteria.
Root cause analysis
Identify the fundamental cause, not just surface phenomena. Formulate hypotheses and test them with evidence.
Solution derivation
List possible alternatives, compare effects/costs/risks, and choose the optimal one.
Execution
Make a plan, allocate roles/schedule/resources, and execute.
Evaluation
Measure results to see if success criteria are met; supplement or retry as needed.

The same basic structure applies from an architectural perspective, but the scope and viewpoint are expanded.

Architecture deals not with individual problems, but with common, universalized problems, leading to expansion. Even the problem definition sets a certain proportion of common problems, not the whole system's problems. Since each solution cannot be optimal for all cases, about 70–80% universality is pursued. Thus, in architecture, you must include handling of out-of-spec cases within the solution. Execution also requires applying to all concrete problems, and evaluation must consider not only statistical results for the group but also how rare cases were handled and at what cost.

How Architecture Differs from General Solution Derivation¶

General problem-solving is usually approached from a short-term, local perspective. Most problems, even outside development, are not macro in nature.
But architectural problem-solving is long-term and holistic. Decisions consider not just implementation, but future maintenance costs, team work patterns, and extensibility limits.

One architectural approach is to introduce structural constraints to prevent future mistakes. For example, strict interface contracts may slow initial development but prevent meaningless losses from mistakes.
Another approach is to clarify abstraction layers and boundaries to control complexity—changing or redistributing the sources of complexity to reduce recurrence of problems. This helps software maintain predictable behavior as it grows.

The key difference is that the focus of decision-making shifts from "components" to "relationships." Architecture is not about optimizing individual functions or classes, but about designing data flow, boundaries, and information flow between modules. Thus, the effect of the solution spreads system-wide, not just to a single element.

Abstraction¶

Architecture is inherently abstract, because the initial problem definition is collective in nature.

But whether the architectural choice was appropriate is determined in concrete matters. The components, dynamics, processing flow, and information flow in architecture are not concrete—they define the environment, not the specific actions. Yet environmental constraints are often more powerful than a few specific prohibitions.

For example, consider the competition between democracy and communism. In computer science terms, it's like having a system with the "democracy" architecture and another with the "communism" architecture. The system's characteristics are not determined by the physical modules. Whatever the political system, you can't eliminate human desire, and services must ultimately implement their intended functions. But architecture acts as an environmental constraint. Whatever the configuration, you can adapt to implement your service, but the effort required is not the same.

Architecture is not defined by listing every constraint or guideline for each case. It is defined at a macro level by components and relationships, roles, responsibilities, authority, processing, and information flow.
For collective problems, it provides answers for the members of the set.

Abstraction comes from the nature of the problem.

Systematicity¶

Architecture is inherently systematic. It is simply not economical to build software as a simple list of hardcoded features. Architecture aims for effective production and maintenance, so it directly builds systematicity.

This systematicity is very different from a simple list. First, design decisions are integrated to avoid contradictions. Every decision simultaneously determines various inseparable aspects. For example, deciding to physically distribute web servers requires either a session-sharing mechanism or pure stateless development—these are inseparable conditions. A distributed web server that is neither stateless nor has session sharing cannot exist. One decision requires or constrains another.

But it's not enough just to avoid contradictions. Every service has its own business purpose, and is designed and implemented to achieve it. Thus, architectural decisions are made with clear purpose. Integrated design decisions for a specific purpose make up the architecture. Each element is defined by what it provides for the purpose and roughly how it achieves it, so architecture, though omitting details, has sufficient systematicity.

Thus, software architecture must maintain a stable dynamic relationship where all decisions require or support each other for the same purpose. If you implement concrete details according to an abstract, systematic blueprint, you naturally get systematic software. Conversely, to realize a systematic business, the architecture you prepare must be systematic.

Systematicity comes from the nature of the result.

Structurality¶

The architectural solution is neither a specific case nor a directive, nor is it just an abstract cloud. It exists between abstract problems and concrete implementations, serving as the bridge. A solution that is concrete enough yet abstract enough is a structural solution—defined by roles, responsibilities, authority, processing, and information flow, omitting the concrete.

Even if you often hear about "structural solutions" in design and design patterns, many do not understand the meaning. This is likely due to confusion in terminology—developers often think of "structure" as data structures or the 'struct' keyword in C. But here, "structure" is closer to the social science concept, or to infrastructure at the national development level.

Structure in social science

Usage: power structure, labor structure, capital structure, logistics structure

Basic definition
Beyond individuals or single events, it means a stable network of relationships and institutional frameworks that make social phenomena repeat and reproduce. Institutions, norms, roles, power, and resource distribution are organized in patterns, and individual choices are constrained or incentivized by this structure.
Key components
- Institution: Law, market, family, education, state, etc.—formal/informal rule systems
- Norm/Value: Social expectations of what is desirable
- Role: Expected behaviors by status
- Power/Resource: Who controls/distributes what
- Relations: Interactions among hierarchies, organizations, networks
Relationship between individual and structure
- Structural constraint: Limits the range of possible actions
- Structural opportunity: Makes certain actions advantageous
- Individual actions can reproduce or transform the structure

Technically, design patterns are good samples for understanding how different structures are proposed for different situations.

In design patterns, concrete implementation objects are not specified—they are called Concrete Classes. The actual instance at runtime is omitted, and the solution is presented as a model through roles, responsibilities, authority, processing, and information flow.

Structurality comes from the method of deriving solutions.

The Practical Effect of Structural Solutions¶

Borrowing from social science, individual modules and classes in architecture are constrained and incentivized. Implementation in direction A is harder, in direction B is easier, so implementations tend to cluster toward B. Thus, architecture gathers code quality, stability, maintenance cost, extensibility, etc., in the direction the architect wants.

These incentives and constraints must be decided according to the business purpose, nature, cost structure, workforce structure, and other contexts. When the right architecture is applied—when you get enough structural benefits for the price of proper incentives and constraints—work efficiency rises and required effort drops.

There are three intuitive states related to this. These states can be used to sense whether the architecture's incentives and the needs of individual implementations are in conflict or synergy:

Worst: Simple features are cumbersome to implement, and hard features are very hard or impossible.
Normal: Simple features are reasonable to implement, hard features are hard.
Best: Simple features are simple, and hard features are relatively easy.

Structural solutions aim to avoid the Worst, at least achieve Normal, and if possible, aim for Best. This is achieved by accurately identifying the common nature of problems, business goals, performance goals, etc., and deciding on appropriate role allocation and processing flow, so that as much as possible is handled in the common infrastructure in a normalized/standardized way. As the use of common functions increases, delegation in individual feature implementation increases. But this is not about increasing the amount of common module code or making common modules more complex. If there is too much code or branching, the risk just moves, and you cannot say you have achieved systematization based on normalization. In practice, only the location of errors changes.

Strictly speaking, architecture is not a perfectly sealed container, so it is always possible to develop in ways that do not follow the architecture. In such cases, losses outweigh benefits. Therefore, architecture is not the architect's exclusive domain—every developer on the project must know it.

Conclusion¶

If you hate overtime, structural solutions are the structural solution.

A structural solution is not simply about developing features or implementing services well. It is something that can be achieved even by spending long hours hardcoding.

A structural solution is about thinking more, but achieving greater results with less effort. Systematically separating and formalizing recurring problems is certainly difficult. It’s not a matter of how much time it takes or whether you’re familiar with it; the intellectual difficulty itself arises from the complexity of the problem the service aims to solve.

However, if you break it down and properly formalize—structure—it, the system’s flexibility increases dramatically. Developers often encounter cases where a combination of well-formalized minimal units flexibly solves larger problems. With just 95 reserved words defined in C++23, it’s not impossible to create the Internet. What about Minecraft or Roblox, where you can create games within games? This means much more than simply increasing the reuse rate of elements.

For developers, the ultimate tangible effect of a structural solution is the realization of the Pareto principle. The fact that 20% of the code solves 80% of the work means much more than just reducing the amount of code written through reuse. If there is a lot of code and each element is different, readability drops, consistency is lost, and complexity increases, causing a multiplier effect that exponentially increases communication, debugging, and maintenance costs. But a structural solution that formalizes problems allows a small infrastructure to absorb recurring issues. At the same time, it ensures consistent rules are applied throughout the system. Instead of relying on memory to recall where things are, you can easily rediscover them through rules, even if you’ve completely forgotten. It also allows you to focus on the essential business logic.

As a result, coding and testing time are reduced, but the overall quality and productivity of the system improve dramatically. In other words, you work with your mind, not just your fingers.

Author¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
https://js-seth-h.github.io/website/Biography/

Over 20 years in software development, focusing on design reasoning and system structure - as foundations for long-term productivity and structural clarity.

Researched semantic web and meta-browser architecture in graduate studies,
with an emphasis on structural separation between data and presentation.

Ph.D. in Software, Korea University
M.S. in Computer Science Education, Korea University
B.S. in Computer Science Education, Korea University