Software Architecture Guide

Preface

In the software industry, when people talk about "architecture", they refer to a vaguely defined concept of the most important aspects of the internal design of software systems. Good architecture is important, otherwise adding new features will become slower and more costly in the future.

But the term "architecture" should be treated carefully, because it usually implies separation from programming, or even flashy exaggeration. What we really care about is good architecture that can support its own evolution and is inseparable from programming. So:

• What does good architecture look like?

• How can teams create good architecture?

• How to cultivate architectural thinking in our development organization?

I. What is Architecture?

The definition of architecture has been a topic of endless debate in the software industry. Some think architecture is the basic organization of a system, others think it's the way the highest-level components are connected together. But what is the objective definition of "basic" and "high-level"? So, a better view is the consensus formed by expert developers on system design.

P.S. There's another common definition that considers architecture as design decisions that need to be made early in the project, which is also not accurate enough, as it's more like hoping to make decisions as early as possible in the project.

Ralph Johnson believes that architecture is about the important stuff, whatever that is:

Architecture is about the important stuff. Whatever that is.

Sounds a bit clichéd, but there's some truth to it, because the core of thinking from an architectural perspective is to determine what are the important things (i.e., what is architecture), then invest care to keep these architectural elements in good shape. For developers who want to become architects, they need to be able to identify those important elements, and those elements that would cause serious consequences if not controlled.

P.S. For more information about architecture definition, see Who Needs an Architect?

II. Why is Architecture So Important?

For customers and users of software products, architecture is a tricky issue because it's not something they can immediately perceive. But poor architecture is a major factor contributing to cruft, which hinders developers from understanding the software. Software containing a lot of cruft is difficult to modify, leading to slower feature iteration speed and more defects:

More seriously, since this cruft is spread throughout the codebase, it slows down every feature iteration.

Conventional wisdom tells us that usually high-quality things also cost more. For some aspects of software (such as user experience), this is indeed the case. But when it comes to architecture and other aspects of internal quality, this relationship is exactly the opposite: high internal quality can accelerate the delivery speed of new features, because obstacles from cruft are reduced.

Admittedly, in the short term we can sacrifice quality for faster delivery, but before the accumulated cruft has an impact, people underestimate how quickly it slows down overall delivery. Although it cannot be measured objectively, experienced developers know that attention to internal quality pays off within weeks (not months).

Software with high internal quality delivers slowly in the early stage, but much faster in the later stage.

P.S. For more information about software internal quality and cost, see Is High Quality Software Worth the Cost?

III. Application Architecture

Important decisions in software development vary depending on the scope of context we consider. The common scope is the application, i.e., application architecture.

The first problem in defining software architecture is that there's no clear definition of what an application is. Essentially, an application can be understood as a social structure:

• From developers' perspective, (application) is a pile of code

• From business customers' perspective, it's a set of features

• From investors' perspective, it's a budget plan

This loose definition leads to applications of various sizes, with development teams ranging from a few people to hundreds of people (considering scale as the number of people involved is the most useful way to measure). The main difference from enterprise architecture is that there's a high degree of unified goals around the social structure.

Application Boundaries

One of the unresolved problems in software development is how to determine what the boundaries of software are. For example, is a browser part of the operating system?

Essentially, applications are social structures. We can depict software boundaries in hundreds of different ways (from perspectives of developers, business customers, investors, etc.). In many ways, these boundaries are drawn by interpersonal relationships and politics, rather than based on technical and functional considerations.

P.S. For more detailed information, see ApplicationBoundary

Microservices Pattern

Microservices architecture pattern is a method of developing a single application as a suite of small services, each running in its own process and communicating through lightweight mechanisms (usually HTTP resource-oriented APIs). These services are built around business capabilities, independently deployed by fully automated deployment mechanisms, can be written in different languages, and can use different data storage technologies, requiring only minimal centralized management.

These advantages have made the microservices pattern very popular in the past few years, but costs such as increased distributed costs, weakened consistency, and maturity requirements for operational management also come with it.

P.S. For more detailed information, see Microservices Architecture

Serverless Architecture

Serverless architecture is an application design that includes third-party BaaS (Backend as a Service) services, as well as custom code running in temporary containers hosted on FaaS (Functions as a Service) platforms. By applying these ideas and related ideas such as single-page applications, this architecture eliminates most of the need for traditional always-running server-side components.

Serverless architecture helps significantly reduce operating costs, complexity, and engineering delivery cycles, but at the cost of increased vendor dependency and relatively immature support services.

P.S. For more detailed information, see Serverless Computing in the Eyes of Berkeley Researchers, Serverless Architectures

Micro Frontends Pattern

Doing frontend development well is hard, and scaling frontend development to let multiple teams work on large and complex products simultaneously is even harder.

Micro Frontends pattern is a popular trend that has emerged in recent years to split the overall frontend into many manageable small pieces to improve frontend team efficiency.

P.S. For more detailed information, see Micro Frontends

GUI Architecture

From the initial forms plus controls, to later MVC, MVP and other patterns, UI architecture is also constantly evolving.

P.S. For more detailed information, see GUI Architectures

Presentation-Domain-Data Layering

For information-rich programs, one of the most common modularization methods is to divide it into 3 layers:

• Presentation layer (UI)

• Domain logic layer (or business logic layer)

• Data access layer

So web applications are often divided into a web layer responsible for handling HTTP requests and rendering HTML, a business logic layer containing validation and calculations, and a data access layer managing persistent data with databases or remote services:

The biggest benefit of layering is narrowing the scope of concern, allowing us to consider these 3 parts separately. Since module boundaries are established, the impact scope of switching to different implementations becomes relatively smaller, and it's easier to test independently.

P.S. For more detailed information, see Presentation Domain Data Layering

IV. Enterprise Architecture

Application architecture focuses on architecture within some form of conceptual application boundaries, while enterprise architecture looks at the architecture of the entire large enterprise. Enterprise organizations are usually too large to divide all their software in a cohesive way, so coordination is needed for teams that each own many codebases. These teams develop independently from each other, with independent funding and users.

Much of enterprise architecture is about what kind of centralized coordination is worthwhile, and what form coordination should take. One extreme is centralized architecture division, where all architectural decisions for every software system under the enterprise must be approved. This division slows down decision-making speed and cannot truly understand various problems in the extensive system portfolio, leading to poor decisions. The other extreme is no coordination at all, leading to duplicate work among teams, inability to interoperate between different systems, and lack of skill development and cross-learning among teams.

In response to this, rather than binding control, it's better to decentralize power while strengthening local decisions as much as possible, minimizing the actual costs involved.

Let Enterprise Architects Join Development Teams

Enterprise architecture groups are usually separate from daily development, which leads to their knowledge of development work becoming outdated, and development teams don't have a broad perspective from the whole company. Therefore, enterprise architects may be able to improve efficiency by joining development teams.

P.S. For more detailed information, see Enterprise Architects Join the Team

Changes in the Role of Enterprise Architects in Lean Enterprises

When enterprises adopt agile thinking, enterprise architecture doesn't disappear, but the role of enterprise architects changes:

• Enterprise architects no longer make choices, but help others make correct decisions, then disseminate this information

• Enterprise architects still need to form visions, but subsequently need to build bridges between teams and establish learning communities

• Enterprise architects need to build partnerships with teams, explore new methods in growth and learn from each other

P.S. For more detailed information, see The Role of an Enterprise Architect in a Lean Enterprise

Product Pattern Over Project Pattern

Project pattern is a popular way of organizing software development with funding according to software projects, organizing work into temporary teams responsible only for implementation, funded by specific benefits expected in business scenarios.

The product pattern changes to persistent teams responsible for conception, implementation, and operation to solve continuously existing business problems. The product pattern enables teams to quickly adjust direction, reduce end-to-end cycle time, and verify actual benefits through short-cycle iterations, while maintaining the integrity of software architecture to ensure its long-term effectiveness.

P.S. For more detailed information, see Products Over Projects

Responsibilities of Architects

Many large organizations' IT departments are separated by many floors from senior management with decision-making power, which also separates business and digital strategy from the important work of implementing strategy.

Therefore, the main responsibility of architects is to take the elevator from the top floor to the machine room, stopping wherever support for their digital work is needed: automating software production, minimizing upfront decisions, and influencing the organization while technology evolves.

P.S. For more detailed information, see The Architect Elevator — Visiting the upper floors

References

• Software Architecture Guide