This chapter is from the book
This chapter is from the book
This chapter is from the book
How to Design a System
As discussed, design requires holistic decisions that keep the big picture and final goal in focus. Although there are many good tactics such as creating designs that are easy to change, we need to ensure the medicine is not worse than the problem. Gregor Hohpe explains that architecture creates options, just like financing alternatives, which is an apt analogy because having options also incurs costs. Sometimes, it makes sense to have options, and sometimes it does not. An architect must have options and the wisdom to recognize when not to use them.
System design is like war: You must know your enemy (the problem, how often it changes, etc.) and your strengths and weaknesses of the team and yourself. Also, you must play the odds. For example, if the cost of being portable is 50% more, but there is only a 10% chance that you will have to move to a different cloud, then the expected cost of being portable early is 150%. However, if we choose to not be portable, then there is a 10% chance that we will have to port later. Let’s assume that to port later we have to do 250% more work. Then, the expected cost of not being portable is (100% + 250 * 10%) = 125%, which suggests that we should go with the nonportable choice.
Chapter 1 discussed the concept of business context, which includes not only TOGAF’s business architecture but also other factors like project timelines, team skills, and competitive threats. It’s this business context along with user experience that add complexity to software architecture. Any given situation will present various trade-offs in terms of costs, which could include time, complexity, required skills, and benefits like performance, stability, and speed to market. The relative importance of these costs and benefits varies depending on the business context and user experience. Making these trade-offs and arriving at the right technical decision require sound judgment.
This book proposes five questions and seven principles that help us understand the context, acting as guideposts for good judgment. Part II and Part III discuss knowledge and explain how it relates to judgment.
As a reminder, the five questions include
When is the best time to market?
What is the skill level of the team?
What is our system’s performance sensitivity?
When can we rewrite the system?
What are the hard problems?
The seven principles are
Drive everything from the user’s journey.
Use an iterative thin slice strategy.
On each iteration, add the most value for the least effort to support more users.
Make decisions and absorb the risks.
Design deeply things that are hard to change but implement them slowly.
Eliminate the unknowns and learn from the evidence by working on hard problems early and in parallel.
Understand the trade-offs between cohesion and flexibility in the software architecture.
The five questions are designed to help us understand the terrain (or the business context). Starting with time, team, and performance requirements, the effects of the first two questions are well understood. Performance comes next because it determines how much precision we need in the design. Many find the fourth question regarding rewrites odd, but I believe there is a natural second phase to all projects, where we can rewrite the system. This question is crucial because it defines the first phase and lets us defer some hard but not immediate problems uncovered by the fifth question to the second phase. I believe this question significantly clarifies our scope.
Once we understand the terrain, the seven principles are about what to implement, when, and how. The first principle tells us we should look at everything from the vantage point of the user and choose only things that are useful for their journey. The second and third principles say that we should iterate, starting with a thin slide, exploring the design space, and getting user feedback. Next is the most important takeaway, making decisions and absorbing the risks. The fifth and sixth principles are about going into depth, and the seventh principle reminds us that most good architectural practices come with a cost, and this principle balances advantages and costs.