How to make architecture decisions

Good decisions need context. Experienced engineers know that the answer to most technology choices is “it depends.” Knowing the pros and cons of a particular technology isn’t enough—you need to know the local details too. What are you trying to do? How much time, money, and patience do you have? What’s your risk tolerance? What does the business ne

Drive architectural decisions, which are the primary unit of work of architectural activities. Continuous Architecture recommends explicitly focusing on architectural decisions because if we do not understand and capture architectural decisions, we lose the knowledge of tradeoffs made in a particular context. Without this knowledge, the team is inh

For example, enterprise architecture boards make far fewer decisions than product-level governance boards. Note that the scope and significance of architectural decisions also increase with scale. However, most decisions that can impact an architecture are driven on the ground by development teams. The closer you get to implementation, the more dec

Creating visibility of architectural decisions at all levels of the organization and sharing these decisions among different teams will greatly reduce the probability of significant architectural compromises occurring. It is not technically difficult to create visibility; all you need to do is agree on how to document an architectural decision.

In the end, making some decisions early on is irresponsible. For example, settling upfront on architecture, such as using Microservices, or trying to create generalized solutions and modeling abstractions, is wrong. These decisions should be postponed until we prove that those choices are justified and necessary.