-
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 do you care the most?
-
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”