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

Software Architecture Is Decision-Making, Not Imitation¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
Draft: July 2022 / Revised: November 2025

[Author’s Intent] This article was written to reveal why following successful cases or trendy architectures as they are can actually be an act of avoiding responsibility for decision-making.

Executive Summary¶

Software architecture is often called "decision-making," but most just imitate something else.
Such "mimicry" chases only the surface of success stories, ignoring the organization's context, team capabilities, and business goals, and pays the price in cost.
Every business has its own flow, and there is a structure that fits that flow. Therefore, reflection on "understanding the problem" and "the goals to be achieved" is essential.
To reach the right conclusion, you need accurate problem recognition, sufficient background knowledge, and awareness of various best practices and their adaptations.
Understand trade-offs and pursue benefits.
When making choices, only accept costs you are willing to pay.
Sometimes, even if you take a loss, achieve harmony and make things coexist.

What Is Decision-Making?¶

In software architecture, decision-making is not simply choosing a technology, but a process of comprehensively considering various constraints, goals, and organizational situations to determine the optimal direction. Simply put, it is the act of skillfully balancing in the middle of trade-offs. Therefore, if you do not know what trade-offs your decision brings—what losses and gains on two or more axes—then it is not "decision-making," but mere mimicry.

At a minimum, 'decision-making' means knowing what you pursued and what you accepted.

Why Do We Settle for Imitation?¶

Seeking maximum benefit is almost instinctive for humans.
So why do we settle for mimicry without knowing the gains and losses?
It's because, even if we understand the structure of best practices, we do not understand the decisions within them.

Restful API, Monolithic, MSA, RPC, and many other methodologies coexist, and the very fact that none is universally adopted proves there is no silver bullet.

All have advantages. Each promotes its strengths.
But more important is that every choice has disadvantages—sacrifices. If you do not see the trade-offs, you end up copying only the appearance.

Why Do Projects Fail?¶

A design is just a drawing of decisions. Conventional mimicry achieves neither the best nor the next best. Everyone has their own circumstances and costs they simply cannot pay.

With luck, you may succeed by paying similar costs as the best practices if your situation is similar. But in projects, avoiding reasons for failure is more important than reasons for success. If you adopt a technology "because everyone else does" and cannot offset its drawbacks, you are likely to fail.

What Is the Unique Flow of a Business?¶

Every business has its own workflow and requirements. A wiki system and a shopping mall system have completely different flows. So do a bookkeeping system and an automotive entertainment system. Businesses with different main processing flows should have different structures.

However, in real development, most projects try to use Restful APIs. At least half the time, this is an inefficient choice. And among those who bear this inefficiency, almost none have read Roy Fielding's REST style proposal, understood its trade-offs, or understood his suggestions for overcoming them. If they did, they wouldn't do it that way.

Every business has a computing pattern most commonly found within it. Perhaps this is because humans have grouped certain types of work together as they evolved. You must choose a backbone appropriate for the task. You can't support a cat's body with a fishbone. Would any architect try to modify WordPress to make a relational database?

How Do You Gain Background Knowledge?¶

There is almost only one way to gain background knowledge: read textbooks. The history of computer science is very short—less than 70 years. It is also an almost isolated field, barely overlapping with others. All the basics are in there. Any library or framework is built on these basics, so those who know them and those who don't will inevitably have very different understandings.

How Do You Learn Best Practices and Adaptations?¶

Best practices can be learned in many ways: technical books, official documentation, communities, conferences, open source, and real project results. If great developers have thought through their problems and produced the best results, most of those are best practices. However, the "bill" for those practices does not specify the costs.

So how do you learn adaptations? The answer is deep domain knowledge. No one can explain all adaptations. But essentially, the "bill" for best practices is a trade-off, so if you understand that, you can adjust. Knowing how to optimally adjust for your own situation is knowing adaptation. Again, design is "decision-making"—finding the balance point, not choosing from a fixed blueprint. So, adaptation is not something to know, but a capability.

Maximum Benefit¶

The ultimate goal of design is to achieve the greatest effect with limited resources. For example, introducing a large-scale distributed system to a low-traffic service is a waste of resources. Pursuing a direction that exceeds the team's capabilities also cannot yield maximum benefit. If most developers are used to backend template engines, choosing React.js is not cost-effective. Pursuing Restful APIs in a system with frequent data modifications, required transactions, and little use of caching is also a huge waste.

Whether it's manpower, operating costs, or development time, you want certain things. Get as much as you can for as little cost as possible.

How Do You Make the Right Decision?¶

You can never have it all.

As long as trade-offs exist, you cannot maximize every aspect. To increase productivity, you must reduce detail; to pursue stability, you must increase time and operating costs. You cannot make software that is the most detailed, the most stable, the fastest to develop, and the cheapest to operate all at once.

Most things in the world are inseparable, and software development is no exception.

Architecture must find balance among elements, and sacrifice is always necessary. The important thing is to clarify your priorities and make rational choices accordingly. Clearly distinguish what cannot be sacrificed from what can, and make system goals coexist within the adjustable range. In other words, get what you want and pay only the costs you can bear.

Conclusion¶

Every architecture pays a price.

Port and Adapter architecture pays the price of predefining the limits of each interface's extensibility.
Restful pays the price of difficulty in multi-resource processing.
Linux's X Window design is slow in GUI, while MS Windows pays with blue screens.
MSA (MicroService Architecture) pays with more communication costs and more operations staff.
Monolithic structure has the limitation of no horizontal scaling.
Asynchronous IO necessarily requires an event polling mechanism.

Have you ever thought about what price you pay when adopting best practices? If not, you are more than 50% likely to regret it.

Even in choosing clothes, you consider T.P.O. (Time, Place, Occasion). The average software lifespan is 5–10 years, and its architecture is hard to change during that time.

If you had to wear one outfit for seven years, would you just imitate others?

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,
emphasizing 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