Software Architecture: The Important Stuff

Martin Fowler defines software architecture as “the important stuff, whatever it is.” It sounds a little playful, but the other definitions he uses to arrive at it make the point clear:

• Software architecture is the system design that expert developers share an understanding of.
• Software architecture consists of the design decisions that must be made early—or the decisions that later make you say, “I wish we’d thought that through more carefully at the start.”
• Software architecture is also the set of decisions that are difficult to change.

Ultimately, software architecture is about deciding what matters.

Why is it important?

If we can’t explain why something matters, perhaps it doesn’t. So let’s consider why software architecture is important. Coupang documented its journey toward a microservices architecture in a post titled “Our Journey to Find Happiness”. It’s a worthwhile read. In other words, architecture matters because it helps developers build better products. But creating good architecture isn’t easy. Consider this passage:

“Here are two products, one inexpensive and one expensive. The expensive product has a carefully considered software architecture; the inexpensive one was built without much thought about system design. Yet from the outside, the two are indistinguishable. To customers, they look the same, have the same features, and perform equally well. Which should they buy?”

Customers won’t choose the more expensive product for the happiness of the engineers who built it. Nor is it very persuasive for an engineer to tell colleagues, “For me to be happy, we need good software architecture, even if it costs more time and money.”

To build shared understanding of why architecture matters, we have to make the economic case. If someone says, “We need more features in this release, even if we sacrifice some internal quality,” responding with “No, we engineers need to do this more professionally” is a losing argument. In a contest between craftsmanship and economics, economics has always won.

[caption id="" align="aligncenter" width="618"] Cumulative functionality over Time[/caption]

Developing without considering architecture may let you add features quickly at first, but that pace gradually slows. Existing features and code become obstacles to adding new ones. By contrast, if you keep a good design healthy, refactor regularly, and maintain clean code, feature development need not slow down. It may even accelerate as clear boundaries and modularity make it obvious where changes belong. New engineers can understand the system sooner and add features more quickly and safely. Ultimately, development teams need to think deeply about good design and architecture so they can deliver more features to customers faster over the long term.

What is the best software architecture?

There is no single correct architecture. The right answer depends on the situation. Microservices may be a good choice, but they aren’t the answer to everything. Equally, a system isn’t behind the times simply because it is monolithic. Every choice involves trade-offs.

Imagine designing a wired communications system. In a country with excellent internet infrastructure such as Korea, Skype offers free, high-quality calls—even video calls. Just as you’re about to declare, “Long live Skype! Internet communication is always the right choice!” the power goes out. Your declaration might reach the house next door, but not much farther. Traditional landline systems, meanwhile, may be slow and lack video, but the telephone line supplies its own power, allowing calls during an outage. Places that absolutely need communications during war or other disasters may still need traditional telephone lines.

Banking is another useful example. Why is it so complicated—passwords, phone verification, one-time passwords? Wouldn’t it be convenient if the system simply remembered your password and kept you signed in? The reason is security: your assets matter. Usability and security often require a trade-off.

The appropriate architecture depends on the product, system, environment, timing, and constraints. Choosing one architecture means giving up something on the other side of that choice. That’s why architecture cannot be considered only as a technical matter. It requires a deep understanding of the business the system is intended to support.

What are you going to do?

Changing an established architecture is extremely difficult. You need a detailed understanding of what already exists, must accommodate business requirements, and must keep existing functionality working throughout the transition. You also need agreement with the engineers who contributed to the system and must persuade many people to fund work that may produce no immediate visible change.

Buzzvil recently formed an Architecture Task Force. We plan to analyze, research, plan, and implement improvements to our overall design, building a shared structural understanding across development teams. Regular communication will maintain alignment across the company, while systematic documentation and guidelines will help every team member participate and grow. Ultimately, we want an architecture that lets all teams and company-wide projects move faster, delivering more features sooner.

There is still much to do, but with thoughtful planning and fast execution, I believe we can achieve good results. Even if the changes are not immediately visible, thinking carefully about good design—and acting on it—is the right way to move faster toward the vision and goals we ultimately want to achieve.