Back at university I remember starting my thermodynamics course with the laws of thermodynamics. The reason they were useful was that whenever you approached any thermodynamic problem such as axial flow jet engines, these apparently simple laws always governed the ultimate complex mathematical descriptions of these systems. If the application of a law to an equation failed, then the equation was flawed.
We see this in technology architecture just as much as any other discipline. When approaching a complex problem it is very useful to discover the underlying principles or laws that will govern the solution. For example, from my own experience of architecting a distributed system that wanted to exhibit the following behaviour:
- Under normal conditions each control centre would cooperate with others
- In a major crisis, each control centre could operate totally autonomously
- Life criticality would require extremely high availability under extraordinary circumstances
- No single points of failure
- and so on...
As requirements they are like laws in themselves, but after much exploring of the options and pair architecting principles began to precipitate out that would go on to govern the solution:
- Each control centre must have a copy of the entire system's operational data
- All operational data sets would need to be able to be range partitioned
- Each centre would be nominated master for read/write activity against a selection of partitions and only masters could action a write against the partition and issue the update message to all other centres.
- There could be no single database recording the partition range and the nominated master of it - this is achieved autonomously through consensus (otherwise this dataset becomes a single point of failure and therefore needs to be federated to allow autonomy, but what if one centre doesn't receive an update of this lookup data and uses the wrong master? Then it has to become a n-way distributed transaction which won't work for other reasons...)
- Messaging would be used to distribute copies of the data to all other centres
- Messages would describe the intent of the update but not the data
- Messages would be idempotent
- Non operational data sets are not included as the requirements for them could easily be managed through traditional approaches.
- Should it become clear that a particular aspect is becoming astoundingly complex or economically unviable, remember that a combination of people and process may well solve the condition far more elegantly.
- etc.
By discovering the principles and documenting the reasoning behind them you don't have to keep rediscovering them as you go through the different parts of the solution, you can just apply them - like design patterns. They encapsulate a great deal of consideration and can be readily reused, even by people not privy to all that reasoning.
When an architectural discussion starts going down a rat-hole or is getting lost, look to the governing principles: Stop, those messages are not idempotent! Stop, that would break system autonomy! Stop, that is not operational data!