Achieving 20/20 Vision Through Architecture Viewpoints
The Blind Men and the Elephant
The story of the blind men and the elephant illustrates how six people with very accurate views can miss the big picture.
Was the elephant like a stone wall, as one man observed when he tried to push it over and it wouldn't budge? Or was it like an oak tree, as said the man who put his arms around one of the huge legs? Or was it a snake, a rope, a spear, or a fan as the other men surmised? Yes—but none of the men had 20/20 vision and thus none were seeing the big picture.
Considering a standard set of architecture viewpoints will provide the 20/20 vision you may be lacking. This article outlines seven viewpoints that help you gain a holistic view of a project and to successfully identify and partner with stakeholders. It is written with an architect or senior developer who has some familiarity with UML in mind.
Figure 1: Solution Architecture Viewpoints
The "What" Viewpoints
One of the key principles of software design is to understand the problem before considering the solution. This means that you must put the "what" before the "how." All too often, you follow the impulse to jump to the solution when you haven't yet articulated the problem. The first three viewpoints you will consider will provide a clear view of the problem to be solved.
Functional Requirement Viewpoint
The Functional Requirement Viewpoint describes the high level business requirements or "whats" being considered. The solution architecture that follows should flow from meeting the needs articulated here.
UML (Unified Modeling Language) Use Case Diagrams can be helpful to represent this viewpoint. A Use Case Diagram is a graphical table of contents of the high level functional requirements of the system. A Use Case Diagram answers the key questions of what users will be using the system and what high level functions they will be using the system for.
Figure 2: Sample Use Case Diagram
From an architecture perspective, the functional requirement viewpoint is not about the detailed requirements that are captured in textual use cases, but rather about understanding the users and the high level functions they need to perform.
Another useful tool for capturing the high level functional view of the system is a user interface wireframe or prototype. A picture truly is worth a thousand words in capturing high level requirements.
Non Functional Qualities Viewpoint
One viewpoint often overlooked is the Non Functional Qualities Viewpoint; it articulates the non-functional requirements of a project. These requirements create certain expectations for the underlying architecture.
Whereas the Functional Requirement Viewpoint will tell you what should happen if a single user presses the "Buy Now" button, the Non Functional Qualities Viewpoint will tell you what should happen if 10,000 users press the "Buy Now" button.
Quality attributes, which express the desired non functional qualities of the system, are used to capture the non functional requirements. The questions quality attributes answer includes:
- How many users will be logged on to the system?
- How many transactions will be performed in a given time period?
- What is the expected response time?
- What are the hours of operation?
- How frequently will changes be needed to the system?
- How sensitive is the system to security breaches?
Quality attributes can be categorized into those qualities observable at runtime versus those observable at design time. Examples of runtime qualities include performance, availability, usability, and scalability. Examples of design time qualities include maintainability, ease of integration, testability, reusability, and conceptual integrity. Arguably, conceptual integrity is the most important judge of a solution architecture because it relates to its understandability and longevity.
Page 1 of 3