Dragon1 Standard: Architecture Visualizations

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 their 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 a conceptual, logical, physical, or implementational level.

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

What is a Visualization?

A visualization is a 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 the technical data of the IT assets on a diagram. In contrast, a financial manager would want to see the financial data of IT assets on a diagram. All because of their concerns and responsibilities in their different line of work.

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

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

Main Types of Visualizations

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 is 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 be the trigger for the business manager to take action.

Another dimension for visualizations is the dynamics that are shown. We distinguish between static, dynamic, interactive, and responsive. Sometimes a picture shows the static structure of a system or entity, and sometimes a picture shows the dynamic behavior of a system 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 or she draws are views of designs, requirements, visions, problems, and plans. These visualizations inform and support decision-making, structure thoughts or startup thinking, and create a common view and understanding. So, if you create a visualization that does one of these, the visualization is a success.

Visualization Framework

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

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

Per subject/topic, you can create or generate stakeholder-specific views (that filter out any unnecessary data for that stakeholder, focusing the visualization on what the stakeholder understands and finds interesting.

Top 20

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 & responsibilities)
• 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 creation 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
• 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

Visualization per Product

Dragon1 defines architecture, strategy, and transformation products.

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

Dragon1 Canvas

Dragon1 promotes architecture visualizations to be created using a context containing strategy and transformation, making a visualization fitter for decision support.

The Architecture Visualization Canvas has a predefined layout.