Designing a system is chaotic, which creates a need for a strategy.
1. Find a design that satisfies
As software is never completed, it's only released. It can't be made perfect. So only design the architecture that is sufficient and good enough.
- Solutions are experiments that need validation, the faster the better.
- Reduce the risks
- Simplify and breakdown problems
- Iterate quickly
- Think problems and solutions together
2. Decide how much to design up front
It's all about finding the sweet spot.
When no time is given to architecture designing, the rework will be high and consume a lot of time. When too much time is given, development time is less and overall timeline increases. The sweet spot is between these two extremes.
For small projects this spot is towards less time in architecture, as being less complex or small, there'll be less rework. But if software is complex or big, this spot is towards the right, meaning spending more time in architecture will give more benefits.
3. Let Risk be the mast of your ship
There are always risks, if not, leave that architecture as you are not required. Instead of overthinking the risks, list them down. Follow the format - <Condition>, might <Consequence>. The condition must be true and exist. Consequence must make sense.
4. Create a plan
A plan is necessary, not a perfect or formal one, but to help guide and move in the right direction.
- Stopping conditions - Define when to stop, when architecture is sufficient, how much time to give, time-box it or it will be a continuous effort.
- Artifacts - What diagrams, templates, docs are sufficient. Where to store and maintain
- Timeline - Overall timeline and how it fits with other processes in the complete solution delivery
- Top Risks
- Start with notional architecture and then refine