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

How to Become a Software Architect¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
Draft: January 2025 / Revision: January 2026

[Author’s Intent] This article was written to show that what truly makes someone an architect is not their role or title, but the kinds of judgments they have repeatedly made.

Executive Summary¶

The way to become a software architect is described very vaguely. Mostly, it is said to require a lot of development experience, learning architectural patterns or principles, understanding past architectures, documentation, communication, leadership, decision-making experience, etc...
But isn’t half of this description about what you have to do, not how to become one?
And do we describe doctors, lawyers, prosecutors, accountants, tax accountants, or teachers in such ambiguous terms?
Strictly speaking, the way to become a software architect is not institutionalized, and even before institutionalization, the qualification requirements have not been defined.
Therefore, becoming a software architect can be seen as a self-declarative achievement with conviction. At least, that is the case from personal experience and observation.
Thus, I cannot provide an objective explanation. But a subjective perspective can be explained.
Software development/design faces many contradictory situations, such as conflicts of interest and technical constraints.
A software architect needs self-confidence to respond consistently to contradictions based on their own standards, and is declared on that conviction.
From personal experience, the necessary and sufficient conditions for conviction can be listed.
Knowledge: Accumulate a wide range of computer science knowledge.
Knowledge: Accumulate knowledge about projects, personnel management, etc.
Knowledge: Accumulate knowledge about education and leadership.
Wisdom: Doubt knowledge. Textbook expressions are compressed and omit a lot.
Wisdom: Doubt knowledge. Knowledge is usually tailored to the learner’s level.
Wisdom: Do not stop at memorizing knowledge, but repeat until you reach sensory understanding and intuitive adaptation – probably a preparatory process for mastery.
Wisdom: Do not stop at memorizing knowledge, but be able to flexibly connect and utilize it according to causality, sequence, and association – probably a preparatory process for mastery.
Mastery: Broaden your horizon of understanding (Hans-Georg Gadamer) so that even if your self-formed worldview of technology, organization, personnel, etc. collides with a new worldview, you can accept and interpret it.
Mastery: Integration of the intrinsic trinity of Thinking, Architecturing, and Implementing.
Mastery: Ability to understand and coordinate the inseparability of decision-making.
Mastery: Ontological judgment about software components.
Mastery: Decision Making Reproducibility is required. Architecture should not be chosen by intuition, but by clear criteria, grounds, and logic, so that ‘reproducibility’ is established even in contradictory situations.
As a result...
- Intuition – Decision-making is naturally induced -> Occurs through accumulated experience
- Transferability – Able to reconstruct and apply existing decisions to new problems -> Not mechanical repetition, but structural flexibility based on deconstruction and recombination
- Explicability – Able to explain decisions and reasons to others -> Must be able to verbalize
- Consistency – Do the same standards work in other contexts? -> Reproducibility of judgment
Architects do not have an institutional license.
However, when you are able to consistently understand and coordinate entities, relationships, flows, initiative, data, and information in reality and the digital world, you realize that you are not copying architecture, but creating it yourself.

General Theory: To Become an Architect¶

Commonly, a software architect is defined as someone who defines the structure of a software system, makes technical decisions, and guides various development teams to properly implement the system architecture, and is introduced as having the following roles: * Responsible for core system architecture design * Selection of technology stack and setting technical direction * Prioritizing quality attributes (performance, scalability, security, etc.) and designing solutions optimized for them * Acting as a bridge between stakeholders and developers

And it is said that to become a software architect, you must meet the following conditions:

Accumulate various development experiences. You need to broaden your technical breadth and depth by playing various roles in multiple projects.
Learn software design principles and architectural patterns. You need to understand key concepts such as SOLID, design patterns, microservices, and clean architecture.
Deeply understand the structure and operating principles of systems. You need knowledge of the entire system, including databases, networks, security, and infrastructure.
Have documentation and communication skills. You must be able to clearly convey design intentions and communicate effectively with various stakeholders.
Leadership and decision-making experience are required. You must be able to make technical judgments, lead teams, and take responsibility.
Continuously learn the latest technology trends. You must actively embrace new technologies such as cloud, DevOps, and containers.

Critique of the General Theory¶

However, the commonly introduced ways to become a software architect focus more on 'what to do' rather than the actual 'process of becoming.' They merely list the roles and responsibilities of an architect, without providing practical guidance on how to reach that position.

In reality, there are no institutionalized standards for becoming a software architect. Furthermore, it is true that software architects have traditionally been considered a domain of talent or genius. Thus, there has been little reason to clarify the process. Most explanations end up listing abstract and comprehensive conditions such as experience, competence, leadership, and communication.

Doctors, lawyers, prosecutors, accountants, tax accountants, and teachers have clear qualification requirements and institutional procedures, but software architects do not. Ultimately, the path to becoming a software architect relies not on institutional or objective standards, but on personal experience, self-confidence, and self-declarative achievement. This inevitably varies according to each person's growth process and inner reflection, and there is no official methodology that applies equally to everyone, making it fundamentally ambiguous.

Nevertheless, there are always baseline standards that a group can agree upon. At least, that is the case from personal experience and observation. Therefore, although there is not just one path to growth, I hope that by articulating as many necessary conditions as possible through personal retrospection, this can provide a goal for some, inspiration for others, and a breakthrough for yet others.

Personal Experience¶

It took quite a lot of time and experience before I could confidently identify myself as an architect. In short, it took 18 years of formal education from university entrance to a Ph.D., and another 16 years of company project experience.

To be honest, even as an undergraduate, I stood out in terms of development ability. Whether it was due to talent or not, I started from a relatively high starting point. I encountered design patterns around my third year of university and had no problem memorizing and using them. Frankly, just following them appropriately made things work well. By the time I graduated, I may have lacked deep understanding, but I knew most of the textbook content and could explain it to juniors. In graduate school, I learned a wide range of non-mainstream fields not covered in undergraduate studies.

At the same time, while working at a company, I experienced the gap and integration between theory and reality. At this point, I personally did not find computer science knowledge difficult, but project and personnel management were separate issues.

By the time I finished my master's, I was already proficient at creating architectures using existing systems, able to achieve goals with very little code. For example, in my SCIE paper, "LIDAB: a user-friendly display system for linked multimedia data and its application in education (2015)," the LIDAB semantic web browser required two URIs—a semantic data URI and a visualization definition URI (a kind of frontend)—to operate. All elements for technical demonstration, including example HTML, CSS, and server, were implemented in 8,524 lines, about 100KB. This was achieved by appropriately delegating most tasks to various libraries and databases.

However, making things efficiently and having complete control over the architecture are different matters. Anyone can make trade-offs or decisions in conflicting or contradictory situations. But whether those decisions can be maintained without wavering as new facts emerge during development is another issue. If you lack confidence in your decisions—if your control is insufficient—you are easily tempted to reverse past decisions as new facts are discovered. Since the cost of modifying architecture is quite extensive, this is not at all positive for self-confidence. At that time, I had not yet achieved Decision Making Reproducibility, because, like most developers, I was focused on extensibility.

Later, I came to see the fundamental fixity inherent in software as a deterministic system. Only after verifying my own architectural design process did I confirm the long-standing challenge of achieving reproducibility in decision-making. After that, I could confidently call myself an architect.

Knowledge¶

Broad acquisition of computer science knowledge

To grow as a software architect, it is essential to learn the core theories and principles of computer science extensively. From basic fields such as data structures, algorithms, operating systems, networks, databases, and software engineering, to the latest trends like distributed systems, security, AI, and cloud, you must be well-versed. This knowledge must go beyond mere memorization and be understood deeply enough to apply to real problem-solving.

Theoretical knowledge forms the basis for structurally analyzing complex problems encountered in practice and designing optimal solutions. It also enables quick adaptation to new technologies or paradigms. Since architects must clearly present the grounds for technical decisions, the breadth and depth of computer science knowledge become the source of trust.

Practical experience in project and personnel management

An architect does not only deal with technology. By experiencing various projects, you must understand the entire software development process, including requirements analysis, schedule management, risk management, and quality assurance. By playing various roles in multiple projects, you realize the importance of personnel management, such as communication, conflict resolution, and resource allocation, in addition to technical issues.

Project experience helps you recognize the gap between theory and reality and develop the ability to respond flexibly to unexpected problems. It also helps you grow in leadership, such as identifying team members' capabilities and placing them appropriately, and in communication skills for collaboration. Since architects must have a perspective that encompasses technology, people, and organization, it is necessary to gain direct experience in various aspects such as development process, difficulty and personnel allocation, and communication with non-experts (non-developer groups).

Education and leadership are not what you think they are.

Knowledge of education and leadership

A software architect is also responsible for effectively conveying their knowledge and experience to team members and raising the capabilities of the entire organization. The most important thing is to ensure that members clearly understand what they should and should not do. The most important thing for an architect is to lead the development organization so that members can take advantage of the infrastructure by conforming to the current project's architecture. Operational efficiency is the second priority, service scalability is third, and the long-term growth of individual members is about fourth.

Therefore, this is quite different from the common educational concept of human resource growth. It does not mean applying textbook teaching-learning theories or reading computer science textbooks to others. Human growth is not that simple, nor does it happen quickly. There is a daily limit to the amount of knowledge that can be absorbed, and the anchoring effect of context is significant (e.g., JIT Learning). There are large differences in the fields where individual exploration abilities are exercised, and differences in background knowledge are also a major variable. Sometimes, improving habits brings greater change than memorizing knowledge. Also, a company is a profit-seeking organization, not one for teaching students. Therefore, it is impossible to operate for purely educational purposes.

As a result, the most important thing is education/leadership focused on work productivity, guiding personnel to obtain the benefits of architecture while assigning them to get the work done. To do this well, you must first accurately understand the constraints and advantages of the current architecture. Second, you must adjust your delivery to the recipient's context (background knowledge and experience) so that they can understand. Through this, you must adjust the development direction of others so that the project proceeds as intended by the architecture.

Note

For reference, the content of common leadership training is almost useless in the context of software development.
Development organizations are very different from other types of organizations. Each developer directly produces output. In manufacturing, equipment has a greater impact, and in service industries, individual performance is less pronounced. But in development organizations, it is totally different. Individual intellectual ability is almost directly reflected in output, so if personal productivity is not felt at all, almost no other means of encouragement are effective.

Wisdom¶

Professors never explain everything they know to undergraduates. They know it cannot be understood anyway.

Wisdom is not just about knowing a lot. Knowledge is information given from outside, but wisdom comes from doubting, reinterpreting, and applying that knowledge in your own context. For a software architect, wisdom means the following:

Recognize the limits of knowledge and do not blindly rely on textbook definitions or authority. Understand that all knowledge has context and omissions.
As seen in Feynman's interview (https://www.youtube.com/watch?v=3smc7jbUPiE), always be wary that knowledge can be simplified or distorted depending on the level and purpose of the communicator.
Do not stop at memorizing knowledge, but repeatedly apply it to real problems, understand it sensorially, and adapt intuitively. Do not fear trial and error or failure in this process.
Flexibly connect causality, sequence, and association to reconstruct knowledge according to the situation and derive new interpretations.
Admit that existing knowledge or experience may not always fit new problems, and have the courage to discard or modify it if necessary.
Do not blindly trust others' advice or industry trends, but verify them with your own experience and logic.
Ultimately, wisdom comes from never stopping to ask "why?" It is important to constantly check the grounds for every decision and choice and seek better directions.

This is the first stage of wisdom.

Definition of Wisdom

Wisdom means an integrated system of perception, experience, and values for making appropriate judgments in context. It is not just knowledge, but the ability to know "what, when, why, and how to apply."

To talk about the next stage of wisdom, I have to mention a bit of philosophy. Philosophy comes from the ancient Greek philos (love) + sophia (wisdom), meaning 'love of wisdom.' As the name suggests, it is a field that explores "why?", especially when not related to the material world. Modern computer science deals with abstract logical models, and most application software reflects social structures to some extent, so it is both distant and close to philosophy, which is the foundation of social science.

In fact, philosophy is a history of asking questions. It is not a perfectly integrated system. But it has constantly asked "why?"

Architecture design consists of countless choices and judgments, some due to physical constraints, but more often due to logical constraints. For example, there is no physical reason to use the abstract factory pattern. The question "why is this choice right?" naturally expands thinking into metaphysical, epistemological, axiological, ontological, constructive, existential, and pragmatic domains. If you think architecture is decided purely in the technical domain, that is too naive.

If you use too many philosophical terms, developers won't understand.
I know... but sometimes borrowing concepts is unavoidable.

Architects do not need to use philosophical terms extensively. However, it cannot be said that their internal thinking does not reach the level of philosophy. If the first stage of wisdom is integrating and flexibly applying different knowledge and experiences, the second stage is about system—order. Unlike pure philosophy, which is aimless and scattered, software development and architecture have a clear purpose: realizing a service. Therefore, integrated knowledge and experience can be organized into a system. Like the Three Laws of Robotics, you can build other theories on top of absolute propositions. Once this system is formed and stabilized, Decision Making Reproducibility becomes possible.

Decision Making Reproducibility

Even if I face the same situation again, I will make the same decision.
In other words, I am confident it is the best decision and do not regret it without reason.

Anyone who has developed software has probably regretted something for no clear reason because the work was more troublesome than expected.

Mastery¶

Mastery goes beyond simple acquisition of knowledge or accumulation of experience; it means internalized, integrated capability. Here are five types of mastery that I personally find effective.

Mastery of World Crash¶

Whether you have a long academic background or a lot of experience, you will have your own technical, organizational, and personal worldview. Software architects are no different, but they are not just experts in a particular field. Software development always creates different services, so the worldview is never the same. Probably, architects experience more worldview clashes than any other experts. Therefore, when your familiar worldview collides with a completely different perspective or new environment, you need the ability to interpret and accept it flexibly, not reject it.

In fact, when joining a new project or organization, past success can often become an obstacle. What is needed is not to insist on your own way, but to understand the context and background of the new situation. For example, architectural principles that worked in a large company may not fit at all in a startup. In such cases, rather than applying your standards unilaterally, you must accept the requirements and constraints of the field with an open mind and derive the optimal interpretation within them.

Hans-Georg Gadamer's 'expansion of the horizon of understanding' is a philosophical and theoretical explanation of the process by which one worldview meets another and broadens one's perspective. Architects need not only to be open to expanding their worldview by analyzing/learning different structures and encountering different business purposes, but also to master the process of expanding their worldview so they can effectively absorb other worldviews.

Common sense is just your opinion. In reality, common sense differs by field.

Mastery of Development¶

Architectural exploration is based on the integration of the intrinsic trinity of Thinking, Architecturing, and Implementing. Thinking identifies the essence and variability of service requirements, architecturing logically and technically designs them, and implementing realizes them as actual code and systems. In architectural exploration, these three stages are not separate, but different perspectives/densities of the same thing, so they are essentially the same.

Simply put, one of the main tasks of an architect is to determine the architecture, impose constraints and incentives on individual modules and classes within the project, and have developers follow them. For example, if you make implementation in direction A harder and direction B easier, the overall implementation will be biased toward B. This is only possible if you can sense what kind of force is applied at the implementation stage the moment you decide on the structure.

On the other hand, listing service requirements is usually vague and ambiguous. The list of requirements never has system integrity in itself, because it is generated from market needs or competition. Often, scalability is implied or easily anticipated. Taking all these into account, you must decide on a structurally complete solution, that is, the architecture.

Moreover, these two processes cannot be considered separately. When exploring architecture, you must simultaneously check whether the current diagram can accommodate business requirements, whether expected expansion is possible, and whether it is really implementable. Drawing a diagram one day and then checking the next day if it can be implemented is not a sensible way to work. As you look at requirements, you must be able to immediately visualize the diagram in your head, and as soon as it is drawn, identify whether it is implementable or not.

As a result, the stages of Thinking, Architecturing, and Implementing must occur almost simultaneously and continuously in the architect's mind. Thus, an architect needs the ability to finish development (Development) even before starting to code (Implement).

Vēnī. Vīdī. Vīcī. — Julius Caesar, BC 47

Research vs. Development vs. Implement

Research – Systematic inquiry to discover new knowledge, principles, or technology
Development – The process of turning research into practical products, services, or technology
Implement – The concrete execution that makes an actual system or product work

Mastery of Inseparable¶

Almost all choices in the world are not independent.

Where the needle goes, the thread follows.

If you physically distribute web servers, you must set up a mechanism to share session state between servers or develop in a purely stateless way.
If you introduce asynchronous messaging (queues, event-based), you need logic for message deduplication, order guarantee, and failure recovery.
When introducing a cache system (e.g., Redis, Memcached), you must consider cache invalidation policies, data synchronization, and consistency issues.
If you introduce database sharding, you need distributed transaction management or eventual consistency strategies to ensure transactional consistency.
If you adopt serverless architecture, you must design for function execution time limits, cold start issues, and state storage (stateless/stateful).
If you introduce i18n for multilingual/multicultural support, you must design for resource file management, runtime language switching, and date/number/currency formatting.

This is not a problem limited to development. But, putting other fields aside, it seems that quite a few developers do not sense this well. Knowing or not knowing that you are choosing properties that are bound together has a big impact on stabilizing services/systems. The joke (or reality) among developers that "fixing one bug creates another" is a different context, but as in the examples above, if you cannot properly handle inseparable elements due to fundamental structural characteristics, you can never stabilize the system.

Of course, inseparable elements, including operational dependencies, must be considered together in Thinking, Architecturing, and Implementing. Such inseparable choices can also arise in organizational structure and business objectives. Inefficiency in development or contradictions in service can result, so you must not only consider technical elements.

The architect is the first gatekeeper to check whether a service or implementation is feasible. Therefore, you need an intuitive ability to detect inseparable elements.

Mastery of Ontological Insight¶

Ontological judgment is the ability to deeply reflect on the reason for existence and essential role of each software component. Beyond simply meeting functional requirements, you must consider what meaning and value each element has in the entire system.

For example, you must ask fundamental questions about why a particular module or service is needed and how it contributes to the essential purpose of the system. Architects must clarify the reason for existence of each component, reduce unnecessary complexity, and aim for design that focuses on the essence.

The reason this ontological judgment is important is that it is almost the only basis for deleting modules. Epistemological, axiological, constructive, existential, and pragmatic approaches mostly look for reasons to exist. But as the representative ontological question "Why should this exist?" shows, it explores deletion. The more modules there are, the more complex the system becomes, which needs no explanation. Therefore, the insight to ask about the essence, boldly remove unnecessary elements, and focus on the core is hard to replace with anything else.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. — Antoine de Saint-Exupéry, Wind, Sand and Stars (1939)

Mastery of Reproducible Decision Making¶

There is a big difference between intuitively feeling that a decision is right and accurately grasping its causal relationships and accepting the pros and cons. Especially when merging contradictory opinions/advantages/disadvantages, it is impossible to take only the advantages of everything. Disadvantages inevitably arise, and facing the disadvantages of the final product is completely different from the intuition of correctness, which is usually biased toward advantages. Therefore, even in contradictory situations, you must not only grasp the essence but also calculate the costs according to consistent standards for decision-making to be reproducible.

If you do not calculate the costs, you will face a storm of regret at the implementation stage.

In my experience, when decisions are based on intuition, as development progresses and things turn out a little differently than expected, you begin to doubt your intuition. You wonder if it would have been better to choose another alternative, and whether you should change it even now. In such cases, it is difficult to maintain the architecture to the end, and even if you do, it consumes a lot of mental energy. However, switching to another alternative is not necessarily better. Changing the direction of architecture can greatly affect implementation, so it is not desirable. In fact, most architectures have their own advantages, but also costs to maintain the structure. The points that most people find inconvenient are these costs. But if you change the structure, the alternative also requires its own costs, so without rational decision-making that includes costs, you are likely to end up going in circles.

Because of this experience, I used to feel that I wrote the architecture but did not fully control it. At decision points, I could not make decisions based on established facts, so I doubted my own decisions and sometimes made different decisions in the same context, especially influenced by recent experiences. In the position of having to convey the validity and benefits of deciding and using architecture, such situations lead to a lack of control over technology.

Therefore, being able to reproduce architectural decisions based on facts and evidence, not intuition, was a major turning point for me. Not only does it go beyond intuition, but at this point, I came to see the costs of architecture as essential infrastructure costs, not just as inconvenient code. For example, many people find the amount of code in Redux or RTK to be boilerplate and very inconvenient. But if you look at each piece, it is actually configuration information for automated functionality, and strictly speaking, it is not boilerplate. If you overlook the costs required for benefits, you cannot make confident decisions and will only doubt them. Thus, decision-making reproducibility is the result of meeting demanding prerequisites and implies a lot.

Self-Confidence as an Architect¶

Self-confidence as an architect is formed when your own design principles are clear and decision-making is reproducible, based on layers of accumulated experience and knowledge. In this profession, which has no institutional certification or official external validation, self-confidence is the most important factor in proving your own qualifications.

Such self-confidence is not mere arrogance or dogmatism, but inner stability based on numerous failures, trial and error, and the lessons learned in the process. Architects do not have an institutional license, but when they deeply understand entities, relationships, flows, initiative, data, and information in reality and the digital world, and can consistently coordinate even contradictory situations with their own clear design principles, they are truly qualified. From this moment, architects can handle contradictions with confidence, design and lead systems according to their own principles, without being swayed by external evaluations or standards.

Conclusion¶

The path to becoming a software architect is an essentially introspective and experience-based journey, with no formal qualifications or set route. But architects are not completed by technical knowledge or practical experience alone. Knowledge, wisdom, and mastery are required. In my case, perhaps due to the order of personal acquisition, reproducible decision-making in contradictory situations felt like the biggest challenge.

If the core competency of an architect is defined as not just understanding and following existing architectures, but exploring optimal structural solutions to the unique problems of each project before development, then architects must be able to make decisions with consistent standards and logic in various contradictory situations, and not waver when disadvantages emerge. This may be a high standard reflecting personal preference, but it is also a sufficient basis for self-confidence.

Each person’s growth path may be different. However, the roles required of architects are somewhat consistent. Therefore, the required abilities are also consistent, and the foundational abilities to perform them will be similar. For this reason, although this is an extremely personal experience, I hope this article will serve as a small milestone for those who wish to walk the path of an architect.

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