Summary
Capturing the essence and the detail of the whole architecture in a single model is just not possible for anything other than simple systems. If you try to do this, you will end up with a Frankenstein monster of a model that is unmanageable and does not adequately represent the system to you or any of the stakeholders.
By far the best way of managing this complexity is to produce a number of different representations of all or part of the architecture, each of which focuses on certain aspects of the system, showing how it addresses some of the stakeholder concerns. We call these views.
To help you decide what views to produce and what should go into any particular view, you use viewpoints, which are standardized definitions of view concepts, content, and activities.
The use of views and viewpoints brings many benefits, such as separation of concerns, improved communication with stakeholders, and management of complexity. However, it is not without its pitfalls, such as inconsistency and fragmentation, and you must be careful to manage these.
In this chapter, we introduced our viewpoint catalog, comprising the Context, Functional, Information, Concurrency, Development, Deployment, and Operational viewpoints, which we describe in detail in Part III.