Let’s start with a statement that canÂ be made about any design: good design makes sense, it is coherent, it is self-evident and doesn’t need a lot of explanation.
While aÂ simple IAM solution would be a fine thing, the reality is that we must deal with complexity in technical connectivity, data, business rules and processes, and what’s more, all these aspects should be expected to change over time. I firmly believe that good solution designÂ means doing everything I can to minimiseÂ complexity by, for example,Â being fastidiously consitent with schema and naming conventions, doing similar actions in a similar way throughout the solution, and keeping all changeable configuration parameters and logic rules in one place.
I find the most efficient way to identify poor design is to try and explain, or even better, demonstrate it to someone else. Sometimes just hearing my own explanationÂ is enough for me to think “that sounds ridiculous” – without even having to take their confused expressions into account.
Another fantastic way to improve design is toÂ write the Operations Guide. If it takes you 5 pages to explain how to perform an operational taskÂ you have done it wrong.
The key point is that you should be doing thisÂ as part of designing and building the solution. If you leave the demos and operational documentation until you’re at the point of going into production, you’ve left it far too late.