Introduction

As a software development practitioner, one frequently faces a fundamental question — how to reconcile ever-changing requirements with rapidly evolving technology. This question often devolves into two extreme programming paradigms: customer-driven development and technology-driven development. Customer-driven development, dominated by Agile and Scrum as its guiding philosophy and toolset, is rooted in user requirements and emphasizes the MVP (Minimum Viable Product), constantly sprinting and iterating while neglecting system evolution and ignoring the accumulation of technical debt. Technology-driven development is the exact opposite — over-emphasizing technological iteration while overlooking the end user's experience.

This tension leads to endless disputes between product and engineering teams, with the ball ultimately being passed to the architect. This is precisely why I want to launch this series — how to think and solve problems like an architect — because so many balls have landed on my desk, and I'm sure many other developers and architects face just as many. As the first chapter in the "Think Like an Architect" series, and the first topic in this collection, I've chosen "Budget-Oriented Design." This is also the very first question every architect needs to consider.

Thinking Like an Architect

How does one think like an architect? Before answering this question, let's first examine what an architect actually is. A technical guru? A business expert? Or someone who coordinates various development teams to build enterprise-level applications?

All of the above! In fact, within an enterprise, there are generally three different types of architects — Enterprise Architects, Solution Architects, and Technical Architects (also known as Functional Architects):

  • Enterprise Architects — Focus on aligning enterprise IT strategy with organizational vision, overseeing the current state and evolution of the entire IT architecture to drive and support the company's business vision. For example — how can artificial intelligence, IoT, or blockchain strengthen and consolidate a company's competitive advantage in its industry.
  • Solution Architects — Serve as the bridge between Enterprise Architects and Technical Architects, focusing on how to translate IT architecture vision into implementation across individual business units while identifying relevant stakeholders to collaboratively bring architectural solutions to fruition. Like Enterprise Architects, they require strong communication skills and broad technical knowledge. For example: whether to build a private data center or adopt cloud-native solutions, being able to clearly articulate the pros and cons of each approach and which is most effective for the organization.
  • Technical Architects — Focus on the details of architecture implementation, requiring deep industry and technical expertise as well as the ability to organize teams to build effective, evolvable system solutions from the ground up. For example: how to use cloud-native technologies to build a complete set of highly available microservices, how to integrate resources and implement end-to-end tracing and error handling.

The responsibilities of these three types of architects overlap, and organizations may have positions with different titles but similar duties. As you can see, these three architect roles form a progression from high-level to low-level, from business to technology, each with a different skill tree. Enterprise Architects need excellent communication skills, broad technical vision, and keen business acumen. Technical Architects need solid technical depth and the ability to integrate resources, architecture, and future development plans. Solution Architects sit between the two as coordinators, requiring a balance of all these skills.

At this point, some readers might feel confused — where should one start if they want to become an architect, and which direction should they choose? If you read the descriptions of the three architect types carefully, you'll notice they all share one common trait — the need for excellent communication and coordination skills. Why is communication so important? This brings us back to the reason for this topic — architects need many qualities, but the most fundamental one isn't mastery of technology or understanding of the product (though those are certainly important), but rather "compromise." You read that correctly — compromise is an essential rite of passage for any qualified architect. There is no perfect architecture in this world, just as there is no requirement that cannot be trimmed. A qualified architect needs to know when to compromise with requirements and incur some technical debt, and when to compromise with technology and trim some requirements.

So the question becomes: what is the basis for "compromise"? The answer is — cost. That's right, this might seem at odds with all the process areas and input/output frameworks in software engineering literature. However, the reality is that money is the ubiquitous language in software engineering. Whether developing new features or refactoring, the first thing we should always consider is cost. If you're familiar with the resource triangle in software development — budget, time, and scope — all are closely related to cost. Cost determines whether we should adopt a monolithic architecture or microservices, whether we should use CQRS and Event Sourcing or a relational model, whether we should use MySQL, NoSQL, or NewSQL, whether we should build in-house or buy an existing mature product. Every technical decision must be centered on cost — this is the inherent nature of any software enterprise.

In this "Budget-Oriented Design" topic, I will introduce 7 enterprise software design patterns along with their currently popular variants. I will also explain and compare the development and maintenance costs of different enterprise application design patterns. After learning these 7 design patterns, you'll discover that popular approaches like microservices, middle platforms, and CQRS all have scenarios where they are and aren't applicable — even the same pattern will have different use cases in different enterprises. Once we have these 7 patterns firmly in mind, whether we're building in-house or going cloud-native, whether we're designing a small application serving tens of thousands of users or a large-scale system handling tens of billions, whether it's a flash-sale system or an offline system, we can have a clear understanding of the technology choices, future development trajectory, and cost control.

Finally, stay tuned!