Last time we talked about how to do technical selection, the key is to understand the requirements completely, so that we can pick the most fit among the options. Remember, it's the right fit, not the best, because there is no perfect solution.

Nevertheless, sometimes we don't just make one selection, we have to make a series of decisions, especially when doing a paradigm shift. For example, if we want to decompose a monolith into microservices, then in addition to making technical selections among many databases and backend frameworks, we must also make decisions about service boundaries, communication contracts, and so on.

This series of decisions will ultimately achieve what we started with: decomposing the monolith.

In fact, such a decision making process is called top-down decision making.

Top Down Decision Making

At first, we know exactly what we are aiming for, as we evaluated microservices as a more appropriate architecture for the moment, with a high flexibility and scalability. At the same time, to avoid getting further away from the best practices, we learned the details of microservices and the steps of decomposition from various books and articles.

After making a series of decisions to define the final service blueprint, that is, the N microservices, we then carefully develop a migration plan on how to implement those services from a monolith step by step. The whole process is established from top to bottom.

When designing an architecture, we tend to use top-down decision making.

The most important reason is we know exactly what to do and how to do it right. In order to avoid confusion, we set a complete plan at the beginning and implement it step by step to achieve our goal.

In fact, many of my previous articles on paradigm shift were written with a top-down decision making process.

• Analyzing How to Scale Web Services From Various Perspectives
• Shift from Monolith to CQRS
• Evolutionary Data Infrastructure

These articles cover how to scale a service, how to decompose a service, and even introduce the evolution of a data architecture. The common point in all these decision making processes is to evolve the system when the current architecture encounters a problem that cannot be solved, but we know how to do it better.

Bottom Up Decision Making

Since there is top-down decision making, is there the opposite? Of course yes, that is, bottom-up decision making.

But this is a strange process, isn't it? We first define which services we want to do, then we decide the communication medium between the services, and finally we define the service boundaries.

Well, it's incorrect.

Because in this context, a bottom-up decision process "doesn't fit".

What kind of context is right for bottom-up decision making? Let's take another example.

Suppose we want to build a complete online environment monitoring, with the goal that any problems are detected and started to be solved before they are aware by the customer, then the customer may not even feel the problem or report it and it is solved in a very short time.

First, we try to use top-down decision making to see what happens.

In general, we might start building a monitoring and alerting system that generates alerts and gets people involved when any problem occurs. Hardware metrics such as CPU, memory, and network throughput are basic requirements, while service response latency, error rates, and exception logs are common software metrics.

But is that enough?

One very common malfunction is not covered, i.e., data consistency. In addition, I believe there are various software behavior problems that cannot be disclosed by the basic metrics.

This is where the bottom-up decision process comes into play. First, we analyze the many problems that have been reported, and then set a goal of detecting the same problem next time without being reported.

Through these practices, we can categorize the types of problems and the corresponding practices, and finally generate a set of rules that can be applied to achieve our original goals.

Such a process is a classic bottom-up decision. We cannot define a complete framework to achieve our goals at the beginning, whether the scope is too large to focus or the impact level is too large to cause a big bang, so we eventually find a reasonable framework boundary by accumulating successful practices.

Conclusion

The top-down and bottom-up decision making processes are fundamentally different and therefore apply in different contexts. So how do we know from the start whether to go top-down or bottom-up?

Let me borrow the above diagram to explain, although what I want to express is not equal to the source diagram.

In the context of Box 1 and Box 2, we would use top-down, and conversely, in Box 3, we would use bottom-up. As for Box 4, I believe that we rarely need to touch this box in software development.

Back to the first example of decomposing a monolith, we were convinced that microservices was the most fitting approach and we understood the details of microservices and decomposing a monolith, so we landed at Box 1.

Even so, we may use unfamiliar databases, software frameworks and even programming languages in the process of implementing microservices, so there must be many problems that need to be experienced, and that would land at Box 2, but that does not affect our migration plan, at most we need to make more decisions and experiment more.

But if we only have a practice direction, know how to do it better, but do not have an overall view, then we will fall in Box 3. At this point, what we need to do is to accumulate more successful practices, and then find the rules to make those unknowns known.

Of course, these are ideal scenarios, and most of the time we need to make additional trade-offs in terms of human resources and time, so sometimes the top-down process has to become a bottom-up process. But, no matter what the decision making process is, it is important to choose what is most appropriate at the moment.

Never shoot for the best architecture, but rather the least worst architecture.
—Neal Ford