We need to augment with more views on the system (such as the next diagram) so that we can better visualize and convey the architecture of the system.

IEEE 1471-2000  "Recommended Practice for Architectural Description of Software Intensive Systems"  defines the relationship between the Stakeholders, their concerns, viewpoints, views and models:

(IEEE 1471 model adapted from a presentation by Rich Hilliard )

By the way, the fact that we need to look at the architecture from different viewpoints doesn't  necessarily  mean that the documentation isn't just POW("plain old whiteboard") - The formality of the documentation is driven by the project style (agile/formal) and other stakeholder constraints (company standards, customer requirements  etc.)

Since models participate in views (which in turn conforms to viewpoints -  which address the stakeholder's need/interested in) I consider choosing the views a prerequisite for modeling. Thus, on the next post on modeling I am going to talk a little about choosing views (suggested minimal set,  viewpoint library etc.). Once I'll get that off the table I'll try to talk a little on architectural styles and patterns and follow that with some strategies for dealing with quality attributes before moving to the next SAF phase (Mapping).