Views from Two Perspectives
A view is a tool used in enterprise and IT architecture, to display a particular perspective of a system, process, or change in a manner which communicates the most relevant, and therefore meaningful, information to a specific set of stakeholders. TOGAF says it like this,
A “view” is a representation of a whole system from the perspective of a related set of concerns.
As discussed in TOGAF v9, the formal definition for basic architectural concepts (ISO/IEC 42010:2007) shows views as the organizational tool of an architecture description. TOGAF bases its use of artifacts – catalogs, matrices, and diagrams – on this idea, stating that a variety of artifacts are necessary to communicate the architecture to the stakeholders who each have a unique viewpoint and therefore demand a view or a number of views.
While TOGAF does use views, I found the number of possible views to be incredible – 56 possible artifacts! Before reading TOGAF, I had seen views used in a less broad sense for software architecture in the 4+1 View Model of Software Architecture. In 4+1 there are 5 possible views – logical, development, process, physical (4) and use case (+1). In this model, the theory is that you start with the +1 (use case) view which helps capture what the user’s requirements are? Then you create the subsequent four views based on the needs of the architecture’s stakeholders. The stakeholder-tailored approach is found in TOGAF, 4+1, and all frameworks and methodologies that I have come across, so TOGAF’s 56 will never be the right answer for any question of “how many views to use?”
Since there are similarities between the possible views in TOGAF and the five in 4+1, I wanted to take a stab at aligning these two approaches. Below, I’ve taken each of the 4+1 views and listed the TOGAF view (diagrams only) that I thought best matched the 4+1 view. Hopefully, someone will find it interesting, helpful, or even worth commenting. I recognize others could debate which views go where, so please chime in with your thoughts.
Use Case
- Solution Concept
- Business Use-case
- Process Flow
- System Use-case
- Events
- Business Service/Information
Logical
- Class
- Class Hierarchy
Development
- Application & User Location
- Software Engineering
- Application Communication
Process
- Data Migration
- System Use-case
- Process / System Realization
- Processing
- Data Security
Physical
- Communications Engineering
- Platform Decomposition
- Network Computing Hardware
- Environments and Locations
