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.

Have you worked on a software development project where there was a cloudy or unbalanced view of what needed to be accomplished? Did the architecture flow from the requirements? Was the architecture fully described? Were the right stakeholders engaged? Was this project successful?

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.

Domain Model Viewpoint

The Domain Model Viewpoint is a depiction of the high level business domain and problem space. It includes the major entities such as customer, supplier, purchase order, and so forth, and their relationships with one another.

UML Class Diagrams or Entity-Relationship diagrams may be used to document the high level business domain. From an architecture perspective, the domain model viewpoint is not about detailed class diagrams of the system or data model diagrams. The purpose is to understand the business problem which needs to be solved.

The domain model viewpoint will be helpful in the solution in many ways, including:

• Naming architecture components
• Understanding how data will be mapped back to operational systems
• Developing message formats for integrating with other systems
• Understanding multiplicities between entities such as purchase order and order item which might affect performance

The “How” Viewpoints

You showed restraint and didn’t prematurely jump to a solution. With an understanding of the Functional Requirements, Non Functional Qualities and Domain Model viewpoints, you have a good understanding of the “what” and are now ready to consider the “how.” There are four viewpoints to consider for articulating the solution.

Conceptual Viewpoint

The Conceptual Viewpoint provides a static view of the solution and the major architectural components. This viewpoint is the central viewpoint. All of the “what” views flow into the conceptual view. All of the “how” views flow from the conceptual view.

To arrive at the chosen solution, a number of candidate solutions should be considered. In evaluating the architectures, particular consideration should be given to how the architecture meets the needs articulated in the functional requirements and non functional qualities. The domain model view will help to name architectural components appropriately. Another key consideration in evaluating alternatives is cost and time constraints. However, try to think more long term about the solution and its total cost over time, not just the initial cost to deliver.

There are a number of diagramming techniques that might be used to represent the conceptual architecture view, including boxes imposed over architecture layers, UML package, or component diagrams; or simple boxes and lines. Often, the conceptual viewpoint is initially formed from white board discussions.

Figure 3: Sample Conceptual Diagram

Architecture Scenario Viewpoint

Whereas the Conceptual Viewpoint is a static view of the solution architecture, the Architecture Scenario Viewpoint is a dynamic view that illustrates how the architecture components interact to perform business or technical functions.

There should be several architecturally significant scenarios from logging on to the system, to making a purchase, and so on. Each scenario can be depicted through UML Sequence Diagrams to show the messages passed between architecture components.

Figure 4: Sample sequence diagram

Architecture scenarios help to identify areas of architecture risk that may need to be proven out through an architecture baseline or performance testing.

Deployment Viewpoint

The Deployment Viewpoint is a logical view of the hardware/software environment. It includes all the major nodes (for example, clients and servers) and the software components observable at runtime that reside on them. UML Deployment diagrams can be used to depict the deployment view.

Figure 5: Sample deployment diagram

An instance of the solution architecture environment as sketched in the deployment viewpoint will be needed to support each phase of the software development lifecycle including development, integration, quality assurance, staging, and production.

Infrastructure Viewpoint

The Infrastructure Viewpoint is a physical view of the hardware/software environment. It depicts all of the redundant hardware devices used for load balancing and fail over. UML Deployment or network diagrams can be used to illustrate this viewpoint.

Stakeholders

You’ve now reviewed the three “what” viewpoints (Functional Requirement, Non Functional Qualities, Domain Model) and the four “how” viewpoints (Conceptual, Architecture Scenario, Deployment, and Infrastructure). Unlike the blind men, you now have 20/20 vision and can effectively engage various project stakeholders.

The following table illustrates how a given viewpoint helps an architect engage with different stakeholders.

Summary

The story about the six blind men teaches you to be careful of having a myopic view. Architecture viewpoints provide a broadminded view of both the problem and the solution. The Functional Requirement, Non Functional Qualities, and Domain Model viewpoints provide a high level understanding of the “what”. The Conceptual, Architecture Scenario, Deployment, and Infrastructure viewpoints clearly articulate the “how.”

Figure 6: Solution Architecture Viewpoints

Each viewpoint helps the architect successfully partner and engage with other project stakeholders including business analysts, project managers, developers, data modelers, and other key roles.

Do you suspect that you have blind spots on your project that could impede its success?

If so, then consider using architecture viewpoints to gain a holistic view of the project and to successfully identify and partner with stakeholders. The rest is up to you!

References

1. John Godfrey Saxe (1816-1887), The Blind Men and the Elephant
2. Software Engineering Institute, Architecture Documentation

About the Author Jeff Ryan is an enterprise architect with over twenty years experience architecting and implementing thoughtful solutions to business problems. He has published over twenty articles on enterprise architecture, SOA, XML, XSLT, Java, and other subjects.