High Level Design Guidance
Architecture Guidelines: Guidance to Steer the Ship
High Level Guidance
Make it lovely not weird: Architecture descriptions should be nice to work with and should look good... Sometimes it is the use of illustrative pictures... Our experiences... tell us that the effort spent in making communication materials look nice will often pay back
Abstraction cuts the Gordian Knot: Master complexity with abstraction. If the system gets larger or more complex, then the level of abstraction of the top-level architectural views has to be increased. There is only a limited amount of complexity an architectural core team can deal with. A possible way out is to choose an abstraction level as high as the system's complexity can still be governed on that level.
Choose the upper deck: If in doubt whether to model on a higher abstraction level or a slightly lower one, always choose the higher abstraction level (this heuristic is also known as "Jesko's Law").
The modeler should stick to ending fast: Never model so deep that the content of the system architecture is redundant with content of engineering documentation of the engineering disciplines. The cobbler should stick to his last, and the architect should stick to the system level.
Go where the money is: Make architectural developments and refactoring of existing system architecture in projects with enough resources and not outside any market-driven activity. The projects whose business case predicts high profit also have the resources to realize architectural improvements.
simplify, simplify, simplify: If there is a choice between a simple and complex concept, the the simple one is most of the time the better one... If the system is complex, then it should be handled by simple means, but not too simple means. Systems become complex when they have to satisfy complex complex requirements. The complexity has to be controlled somewhere. While system architects have to govern the complexity, the stakeholders have to focus on the aspects of the system that are relevant to them via appropriate views. They have to trust the system architects that they will control the overall system and have to be able to live with their limited view on the system. Critics claiming that the system architects are creating too much complexity are often not following this principle of trust. They like to understand the full model themselves, which is often no longer possible with complex systems. Often mentioned quotes carry a lot of truth: "Everything should be made as simple as possible, but not simpler."(Albert Einstein)
(Model Based Systems Architecture, pg 72)
Additional High Level Guidance
Intuitive Architecture
A good architecture should be intuitive. "A good architecture is consistent in the sense that, given a partial knowledge of the system, one can predict the remainder" (pg143, The Design of Design: Essays from a Computer Scientist)
Balance Parsimony with Straightforwardness
Parsimony is a "principle according to which an explanation of a thing or event is made with the fewest possible assumptions". Parsimony is density but not necessarily straightforwardness. You must balance parsimony with straightforwardness. Example: A crossword puzzle is dense but not straightforward and does not hold real utility so it should be avoided in design. "There should be a direct route from what one wants to say to how one says it." (pg142, The Design of Design: Essays from a Computer Scientist)
Great Risks Has Potential For Great Rewards
"The boldest design decisions, whoever made them, have accounted for much of the goodness of the outcome. These bold decisions were due sometimes to vision, sometimes to desperation. They were always gambles, requiring extra investment in hopes of getting a much better result." (pg257, The Design of Design: Essays from a Computer Scientist)
