Introduction#

“The world is vast and there is so much to do” - Kim Woo Choong. The world of software development is the same — vast and ever-expanding. If you are committed to pursuing this field long-term and professionally, learning about software architecture is extremely important. Especially in 2025 and the coming years, AI is developing incredibly fast, and repetitive manual tasks can be handled quickly in one way or another. I personally believe that the remaining time of Software Engineers and Software Architects should be spent learning and finding ways to solve architectural problems, so that the systems we build can meet requirements accurately, sufficiently, and enhance user experience in both business and performance aspects. This will be the first article in the Software-Architecture series. In this first post, I will introduce and summarize some concepts and factors that I think are useful and important as a foundation for diving deeper into software architecture. Without further ado, Let’s jump into the content !!!

What is Software Architecture?#

There are many different definitions of software architecture, but I prefer to define it in the most intuitive and easy-to-understand way. Software architecture is a comprehensive process that includes patterns, principles, processes, and the relationships between components in a system to create an overall design (Not very intuitive yet, right? @@ No worries, just keep reading — it will sink in over time). PS: Just like a codebase, software architecture needs to be maintained and evolves with business changes to some extent (of course, there must be evaluation tools — you do not just do whatever users say). The ultimate goal is “solving the user’s problem.”

The Importance of Software Architecture#

The truth is that most developers in the early years of their career hate working with software architecture and just want to jump straight into writing code right away. But typically, if we work this way, the project is very likely to encounter many issues down the road that need to be resolved. It can even become very difficult to maintain and scale. Instead of spending one to two months clarifying user requirements and coming up with a suitable architecture, we end up spending a lot of time fixing bugs, restructuring the software architecture, providing after-hours customer support (this can easily demoralize team members — I have been through this and know the feeling well), and even worse, customers lose trust, the business loses its strength, and if it is your own product, you will be the one bearing the losses. Of course, no one wants any of that to happen, so the question is: what are the factors that help us arrive at a software architecture suitable for the software we need to build? Let’s keep reading !!!

Key Areas in Software Architecture#

The diversity of topics surrounding Software Architecture can be overwhelming and extremely difficult to approach, making it easy to give up. Therefore, I will categorize the factors that influence software architecture as follows:

1. Business analysis: What is the business problem we need to solve? What are the core features, and what are the boundaries (the limits of what we will deliver)?
2. Infrastructure: Do we need to deploy in a cloud-agnostic manner (ready to switch across all Cloud Computing Platforms)? If so, what is the scaling strategy, and what is the maximum budget we can afford? (This is especially important — I will go into detail about how I personally apply this when we dive into each section.)
3. Deployment strategy: Will we deploy the application as a single unit or as multiple small units (single or multiple deployment units)?
4. Solution architecture: Which patterns will we apply, and where will we use them? How do the components in the system communicate, and through which methods?
5. Test strategy: What testing strategies will we apply to the project?
6. Release strategy: How often will we release a version to customers?
7. Teams: How should we organize and divide work among team members? What is the experience and capability level of team members?

Architecture Drivers#

Each project has its own unique characteristics in terms of business requirements, business goals, budget, and many other factors. Therefore, finding an architecture that fits all projects is nearly impossible, if not entirely impossible. That is why we cannot make architectural decisions based on intuition alone. In my experience, there are several factors that influence architectural decision-making. These factors are divided into the following main groups:

1. Functional Requirements These are what the system must do to meet business goals and user needs. Although it sounds simple, in practice, clearly understanding and correctly defining functional requirements is always a challenge. Notes:
   • Do not get caught up in the “how” — focus on what the system must do (“what”).
   • Ask stakeholders clearly: “What does the end user really want?”
   • Use Domain Storytelling & User Stories at this stage — they are very effective. I will have a separate article introducing these two techniques. Below is an illustration of a story using Domain Storytelling. Feel free to explore further on your own.

2. Business Constraints Business constraints are factors such as time, budget, resources, or legal regulations that you must comply with. These factors will limit the scope and how you implement the architecture. Notes:
   • If there are resource limitations, consider reducing the feature scope instead of trying to do everything.
   • Do not focus solely on technical aspects, because business constraints are often what determine the success or failure of a project.
3. Technical Constraints These are limitations in technology or infrastructure that you must take into account when designing the system. They usually stem from factors such as the existing platform, the technology the company is currently using, or specific system requirements. Examples:
   • Must deploy on an existing internal platform.
   • The codebase must be written in C# because all other systems in the company use this language.
4. Quality Attributes Quality attributes define the non-functional characteristics of the system such as performance, scalability, maintainability, etc. These are factors that directly affect user experience and the sustainability of the system. Notes:
   • Do not try to optimize everything — focus on the quality attributes that your project truly needs. Examples:
   • The system must guarantee 99% uptime (availability).
   • Reports must be generated within no more than 7 seconds during peak hours (performance).

How to Apply This in Practice#

Theory is one thing, but how do you apply it in practice? Below, I will outline five key points that I think you can read and keep in mind when designing architecture. In the following articles in this series, we will also practice building a system from scratch, and I will go through each topic in detail. Let’s see what system we will build in the next article. But first, make sure you grasp these five bullet points !!!

1. Start simple: Do not design an architecture more complex than what you need.
2. React to current problems: Focus on the problems you have right now (or will encounter soon), rather than worrying about the distant future.
3. Keep things flexible: Even with a simple design, leave room for change and expansion.
4. Do not chase trends: Do not adopt technology or patterns just because they are “hot.”
5. Understand trade-offs: Every decision has gains and losses — weigh them carefully.

Conclusion#

Software architecture is not just about technology, but also the combination of business, technology, and real-world experience. Architectural drivers not only help you make better decisions but also help you adjust the system flexibly when requirements change. PS: Always ask the question: “What is the most important thing for this project?” And design everything around that answer.