This then is my view on how to achieve designs that fall in the category of "simplicity", that is, designs of systems that can be understood by the relevant audience(s), and additional audiences, if needed.
Much of my interpretation is derived from the philosophies or religions on Taoism that were composed by Lao Tse or Lao Tzu.
It is difficult to explain, "simplicity", but I need to give it a try, since it is part of my driving principle, being "Beauty by simplicity".
Every design starts by defining the "system" at hand, and we should give it a name that is easily understood by those concerned. This will take some time of problem and goal analysis, until we understand what needs to be solved and be designed in terms of a solution (or alternative solutions). Once we have agreed upon a name for the system, we should develop a short definition if you want, that describes the system as agreed upon. The description will have some themes that each describe the essential parts of the system in just a few words. And these essential themes are the triggers to decompose the system into parts, parts with much cohesion and little dependence on each other. This is much like what we call today (and especially in the 80s) the object oriented approach for developing software systems. But this approach can (and should) be applied to all systems, if we want to achieve "simplicity". An interesting book on decomposition of systems can be found in "Zen and the art of motor cycle maintenance", by Pirsig. Interestingly enough, Taoism and Zen (bhuddism) are different philosophies ;-)
Once you have an idea of the essential parts of the system, or the sub-systems as we call them, the process for achieving simplicity is repeated for each sub-system.
During this process, iteration will step in, meaning that the system will be redefined as we have become familiar with its parts; this leads to an improved system and its parts.
Also, it is important to define the relationships between the parts at every level; these can be viewed as sub-systems as well.
In some ideal sense, the decomposition of the system, in case of software systems for example, should be limited to say, 5 levels of abstraction and it will give you the architecture of the system. We should take into account that the decomposition covers the aspect areas of processes, applications and technology. Also, we may need to describe several points of view as related to the different types of audiences (for example: the client, architect and designer).
Achieving simplicity resembles the music that was composed by J.S. Bach, and I can only refer to this idea by way of listening to Bach's music. An example of this music is found in (an example) of his works as known by "The well tempered clavier", which was chosen rather randomly. Another example is Bach's music as you can hear in the movie "The silence of the lambs".
And if you prefer the jazz equivalent of Bach, you should listen to "The Jacques Loussier Trio", also a random choice, but random is good enough.
The key note of each piece of music resembles "the system" which is the key note of the derived architecture.
During the years that you practice this guideline that I now have written for you, you will find that your designs will improve in reaching simplicity. However, even given this narrative, I think that you will need at least 10 years of practice and experience to come close to the quality of simplicity as I appreciate it today. And I'm still practicing it and learning, to improve my level of quality as related to simplicity.
Another joyful experience of simplicity as we architects (and others) know, can be found in "San Francisco".
Can be understood by everybody.
Free of interpretation.
Less is more.
Cannot add or remove elements.
High level of complexity.