Architecture Visualizations

What is a visualization?

A visualization is graphical representation of a model or a view of a model. For instance a visualization of how the modules in an application support the activities in a process with functionality.

A view is a representation of a model given a certain viewpoint. A viewpoint is a set of issues or concerns of a (type of) stakeholder. For instance an IT Manager wants to see technology data of IT assets on a diagram, whereas a financial manager rather would want to see financial data of IT assets on a diagram. All because of theur concerns and responsbilities they have in their different line of work.

A model is a set of related entities and these relationship can be visualized as-is. A visualization of a pure model compliant to a modeling language, without any context or rich icons, if osten unusable for business stakeholders. Therefore we prevail to visualize models and views stakeholder oriented.

So strictly speaking a business model is a model of the business but not a visualization.

Main Types of Visualization

Dragon1 Defines the following type of visualizations:

  • Sketch
  • Diagram
  • Blueprint
  • Landscape
  • Artist Impression
  • Heat map
  • Roadmap
  • Scenario
  • Map
  • Canvas
  • Gram
  • Graph
  • (Score) Cards
  • Catalog (a list of items)
  • Matrix (a table of items)
  • Animation

In architecture, the architect creates formal and informal visualizations, sometimes of the same subject. This in order to increase the involvement of stakeholders. Looking at a formal BPMN process model or UML Use Case diagram does not trigger a business manager to take action. But an artist impression or design sketch or the problem caused by the current process configuration or systems use case, might just be the trigger for the business manager to take action.

Another dimension for visualizations is the dynamics that is shown. We distinghuish between: static, dynamic, interactive and responsive. Sometimes a picture shows the static structure of a system or entity, and sometimes apicture shows the dynmaic behavior of a syste or entity.

Objectives of Visualizations

As an architect is a designer of total concepts and supervisor of the realization of enterprise-wide integral business IT systems, everything he draws are views of a design, requirements, vision, problems, plans. These visualizations are meant to inform, to support decision making, to structure thoughts or to startup thinking and creating common view and understanding. So if you create a visualization that does one of these, the visualization is a success.

The Difference between a Visualization and an Architecture Visualization

Not all visualizations you create as an architect are architecture visualizations. A visualization is only an architecture if it shows concepts and or their (concept) principles and the key elements (of the concepts).

It could be that the theoretical concept is shown or the applied concepts as a solution is shown, or that a failing or working principle is shown. In all cases we call this an architecture visualization. It could be that the visualization is at conceptual, logical, physical or implementational level.

As criteria if a visualization is an architecture visualization, can be answere by: is a (part of a) concept or principle visualized? If so: then it is an architecture visualization.

Dragon1 Architecture Canvas (Architecture View Layout)

Dragon1 promotes architecture visualizations to be created using a context containing strategy and transformation, and with that making a visualization more fit to use for decision support.

The Dragon1 Architecture Canvas has a predefined layout, formerly known as the Architecture View Layout.

Visualization Framework

An overview of many common subject/topics where all the types of visualizations can be created for are:

Industry Organizations Chain / Network Enterprise Organization Domain Area Program Project Market Clients / Customers Stakeholder Governance Business
Function Issue Need Decision Requirement Rule Goal Objective Document Activity Identity Mission Vision Priority
Initiative Product Process Service Capability Information Information System Application Data Interface IT-Infrastructure Network Storage
Cloud Server Client Robot Security Finance Human Capital Service Delivery Concept Principle Pattern Component Standard Technology

You can create a visualization for one item (like a process or an application) but you can also create a visualization for a subset of or all processes and all applications. This goes for all the subjects/topics above.

And per subject/topic you can create or generate stakeholder specific views (that filter out any unnecessary data for that stakeholder, focusing the visualizaton on what the stakeholder understands and finds interestering.

Top 20 Visualizations For Starting With Enterprise Architecture

The top 20 visualizations (not taking different views or states into account) for starting to work with EA, are:

  • Enterprise Context Model
  • EA Product Roadmap
  • EA Process Diagram (projection of a method onto the organization, with roles & responsbilities)
  • Strategy Map
  • Business Model (Canvas) Diagram
  • Meta Model
  • Architecture Framework Diagram
  • Enterprise Structure Blueprint
  • Enterprise Architecture Blueprint
  • Domains Standards Diagrams (including Architecture Layers)
  • Concepts Overview
  • Principles Overview (Tiles of Details Diagrams)
  • Business Functions Diagram
  • Stakeholder Onion Diagram
  • Stakeholder Needs Requirements Diagram
  • Business Processes Overview
  • Business Capabilities Diagram
  • Application Landscape
  • IT Landscape
  • Data Landscape
  • Security Landscape
  • Principle Details Diagrams
  • Architecture Layer Diagrams
  • Line of Sight
  • Process (Information) Application Landscape
  • Project Landscape Map (per project)
  • Solution Architecture Diagram
  • Functional Solution Overview Diagram
  • Technical Solution Overview Diagram

It is common to put these visualizations in an architecture dossier

Architecture Visualizations Matrix - To Organize and Plan

Below is a popular Dragon1 Architecture Visualization Matrix. It has helped hundreds of organizations to organize the work and plan the creating of architecture visualizations

Visualization per Architecture Working Process

Dragon1 has defined architecture working processes and per process what types of pictures should or could be created (MOSCOW). Below we have listed the most important ones.

  • Line of Sight picture
  • Strategy Map
  • Business Model
  • Business Case
  • Concept Design Sketch
  • Principles Details Diagram
  • Process Landscape
  • Application Landscape
  • Process-Application Dependency Landscape
  • IT Landscape
  • Architecture Vision Poster (Big Picture)
  • Structure Vision Poster
  • (Target) Operating Model Diagram
  • Enterprise (Architecture) Blueprint
  • Governance (Architecture) Blueprint
  • Business (Architecture) Blueprint
  • Process (Architecture) Blueprint
  • Service (Architecture) Blueprint
  • Information (Architecture) Blueprint
  • Application (Architecture) Blueprint
  • Data (Architecture) Blueprint
  • Security (Architecture) Blueprint
  • IT Infrastructure (Architecture) Blueprint / Technology blueprint
  • Architecture Working Processes Poster (maturity level)
  • Concept Design Sketch
  • Agile Projects Overview
  • Technology Roadmap
  • Transformation Roadmap

Visualizations per Product

Dragon1 defines architecture products, strategy products and transformation products.

The Architecture Design Book, the Architecture Glossary Document, the Architecture Principles Document and the Solution Architecture Presentation (PXA) are the most import products in Dragon1. These documents contain various visualizations.