Simplicity is the ultimate sophistication.
Leonardo da Vinci
Although Leonardo da Vinci wasn’t a ‘technology’ architect, his advice can be applied to architecting solutions in two ways:
- Architect for today’s requirements
- Anticipate future change
Architect for today’s requirements
The solution should be designed to meet today’s requirements, rather than trying to anticipate the future. In other words; don’t gold-plate your solution.
Architects sometimes over-design the architecture to implement “useful” features that might be needed at some point, but these features don’t add value today (and may never do so). In fact these extra features may actually increase the effort needed by the project to deliver the solution. Gold-plating can also increase operation and maintenance costs and reduce quality.
As technology architects, we shouldn’t complicate our architecture blueprints if there’s no need. However, if we are convinced that something should be part of the solution but isn’t currently listed as part of the requirements, then part of our role is to push for the requirements to be revisited.
Anticipate future change
Architecting for today’s requirements is critical, but we must also acknowledge that requirements are probably going to change and evolve over time.
This means that we need to apply good architectural practices now, in order to facilitate this evolution later. This includes ensuring the solution architecture is componentised and extensible. Plus it also extends to having complete documentation, clear naming conventions and so on. When architecting a solution, we should ask ourselves; “if in 5 years time someone looks at my design, will they understand what it is doing?”.
Consequently, if future change has been anticipated, when a new requirement materialises, the task of extending the architecture is not as complex as it could have been. Moreover, it is now entirely appropriate that the effort is expended on extending the solution once we know we need to.
Too simple is just as bad as too complex
Everything should be made as simple as possible, but no simpler.
Albert Einstein
Designing the simplest architecture is not the same as “design the solution as quickly as possible”. The key to successful simplification is to keep things simple, but not too simple. Simplicity brings long-term client value, but oversimplification can result in the solution not fully realising the requirements. Fundamentally, if the solution doesn’t realise the requirements then it is not fit for purpose. Also, Non-Functional Requirements should describe the need for the system to be maintainable, scalable, supportable etc.
The pursuit of a simple architecture is essential, but it is also a bit addictive. An architect must continually focus on the requirements, and not obsess on the beauty of simplicity.
