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 consistent 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.
