• Define the scope of the problem

    • Avoid ambiguous words when defining your scope, for example, a maintainable solution … what is that?

  • Make a solution able to adapt to changes and requirements.

There is no such thing as the perfect architecture, but there are definitely bad architectures. Identify them as soon as possible.


  • Identify what matters for your system.

    • What do you care the most?
      • performance?
      • resiliency?
      • consistency?
      • something else?

  • What matters changes from system to system.

  • Don’t spend extra cost on performance (or some other metric) if that’s not required.

Identify the key characteristics of your system and let that guide your architecture


  • An architect should also organize teams, because a team structure should reflect the solution architecture.
    • A system is the reflection of the organization that created it… so you must change your organization if you want something “different” or “new”