Using Views Effectively

There are several tools that exist for architects to create/design, communicate and assess their architectures more effectively. The vast majority of the BTABoK is actually focused on what we call the Red Thread of Architecture... which has much more to do with business, technology, strategy, value, and stakeholders than with detailed views of a system itself.

The following few articles and canvases I will be authoring seek to rectify this situation. After thorough utilization and feedback from architects and architecture practices, the goal is to integrate these fully into the BTABoK in version 4.0.

Views Article: https://iasa-global.github.io/btabok/views.html

My good friend and co-author in the BTABoK is doing wonderful things in this topic as well on his blog: https://architecturality.blog/

Views and Concepts and Canvases, Oh My

There is some confusion about the adoption of these techniques in architecture practices. We have made it as simple as possible, but not simpler, which isn't saying very much. :-) So, let's start with a few definitions of what we mean.

Views and Viewpoints are on official standards managed by the IEEE and ISO. A viewpoint is a part of an architectural description that focuses on a particular concern. For example, a security viewpoint is a kind of template of thinking about a system from a security perspective (what the standard calls a stakeholder concern). It may contain many 'model types' such as a UML sequence diagram or a C4 context diagram, as well as text and other descriptions of the viewpoint. A view is an 'instantiation of a viewpoint', which is basically a filled-out version of the viewpoint for a particular system. A good example would be the security view of the retail commerce system at a large company. So a viewpoint is a generic template and a view is a specific instance of the template for a particular system.

Whew... told you it was going to get deep. But this level of formality is absolutely necessary in Tier 1 Safety systems such as aircraft, vehicles, and other safety-critical systems.

Concepts in the BTABoK are critical ideas and techniques which architects use in their practice. So Views and Viewpoints are Concepts. Decision Records, Requirements, Value Management, Patterns and Lifecycle are also concepts. These are the articles that make up the engagement model of the BTABoK. You may contrast these with competencies in the competency model we use to measure architect's skills and seniority. There is a great deal of overlap in those lists, but just remember, concepts are how we measure an architecture practice and competencies are how we measure an architect.

Canvases (and Cards) are tools in the BTABoK for making architecture quicker, easier to document or communicate. Canvases and cards represent thinking, communication and sometimes documentation tools, but they seldom represent either a complete concept or viewpoint which tend to be much bigger. The Structured Canvas Approach(TM) is the connections between these canvases which make them even more powerful. However, the SCA does have its limits so be careful that efficiency does not replace efficacy.

Building Better Views

This will be one of many articles on views and viewpoint development. Think of it as an introduction to the kind of tools we are adding for organizations and individuals to use to be more effective.

There are a large number of potential viewpoints an architect can use to think and to communicate architecture and decisions. While the decision record is an excellent tool for making, communicating and storing actual decisions, the views are an exploration of the design space.

Architecture Design Space

Design is a tricky and complicated concept. It involves breadth, depth, and balance. The design space in the BTABoK describes the combination of objectives, requirements, options and decisions. But exploring this in a natural way is about thinking of the architecture from different perspectives... what the ISO standard calls concerns. For example, I might think of my architecture from a security perspective or from a functional (both features and API) space. Or I might look at it from a data perspective. Most architects naturally use these design perspectives - views - without thinking about it. However, it is possible to document commonly used design and exploration tools into viewpoints. So a security viewpoint would include a model (or set of models) and associated descriptions which would illuminate the critical elements of the security design. The same can be done with numerous 'types' of views. These we call viewpoints. Lets look at a few examples.

The Context View or Logical Component View

What is commonly called the context view is effectively a logical software/hardware component view. This includes physical locations, a set of contained relationships (a node.js system runs IN a container runs IN kubernetes which runs ON a cloud provider), components and component types at the level of granularity necessary for understanding how the components connect. The viewpoint contains 3-4 primary elements.

• the context diagram and the context description
• the key elements
• associated decision records
• applicable patterns (optional)

The primary context diagram:

The context diagram above (which is quite old) shows location, connection, connection types, protocol, and payload. The legend clearly indicates the meaning of the shapes used.

Example Sub-Section: React Front-End

Example Sub-Section: React Front-End

Overview

A React component designed to capture, communicate, and visualize critical architectural decisions for complex web applications. The component provides a structured, interactive interface for documenting the rationale, context, and implications of key architectural choices.

Decision Overview: Microservices Architecture

Adopt a microservices-based architectural approach for front-end integration.

Key Motivations:

• Enable independent service deployment
• Support team autonomy and parallel development
• Improve system scalability and resilience
• Facilitate technology stack flexibility

Applicable or Connected Patterns

(This is a section to explore patterns applied to the component)

• Micro-Frontend
• Backend for Frontend (BFF)
• Event-Driven Architecture
• GraphQL for flexible data querying
• Optimistic UI Updates
• Circuit Breaker for resilient communication

Other Example Context Diagrams:

The Performance View

The performance model explores the connections highlighted in the context view from a performance perspective. The diagram is not meant to be accurate just informative. The idea behind the performance view is to explore the performance related decisions across one or more complex pathways and design areas where performance can be optimized.

Enter the Canvases

We are building a landing page in the BTABoK for each viewpoint. We are open to any viewpoint from anyone. However, the submissions must be robust enough to be accepted into the library.

In addition to the viewpoint library, we are building a set of canvases for specific, prevalent viewpoints. The goal is to create one-page views that help us understand the most critical aspects of the viewpoint topic area. These will be accessible on each of the viewpoint pages.

Expect future installments to include:

• Infrastructure Viewpoint
• Security Viewpoint
• Data Structure Viewpoint
• Integration Viewpoint
• Resiliency Viewpoint (Reliability, Scalability, Availability, Performance)

Do you have a viewpoint you find extremely useful? Contact the BTABoK committer team by submitting the viewpoint as an upgrade in the issues section of the github library or doing a public pull request.