What Are the Colours of Architecture?

By Stephen Dougall

A few years ago, I had the privilege of attending a conference where John Zachman conducted a seminar on his enterprise architecture framework. One key takeaway that has stuck with me since that seminar is his approach to architecture models. In the world of architecture, we often find ourselves dealing with a multitude of stakeholders, each with a unique perspective on the architecture. This collection of perspectives typically includes various processes, flows, sequences, roles, technologies, and information, among other elements. This presents a significant challenge for architects: how to disentangle this complex web of elements and effectively communicate the architecture to stakeholders while ensuring consensus among them.

Stakeholders in architectural discussions come from diverse backgrounds, such as executives, business managers, technology experts, and developers. Attempting to merge these various architectural perspectives into a set of views without first comprehending each perspective individually can lead to confusion and make it difficult for stakeholders and architects to reach a consensus on the architecture.

Hence, it is imperative to be able to communicate the fundamental perspectives of the architecture to stakeholders before delving into views that combine these perspectives. This is where the concept of Primitive and Composite models, as articulated by Zachman, provides valuable insight. While Zachman’s framework primarily addresses Enterprise Architecture, I believe that this concept holds equal relevance in the context of solution architectures.

In essence, Primitive models represent architectural perspectives, offering a clear and singular perspective of the architecture. On the other hand, Composite models combine elements from the Primitive models to provide a more holistic understanding of the architecture and explore alternative solutions.

It’s worth noting that in this article I focus on “views” rather than models, since in practice, it’s the views that serve as the primary communication tool with stakeholders. While models underpin the creation of these views, it’s the views that form the essence of communicating the architecture to stakeholders. I also use the term “Primary” rather than “Primitive” when classifying views as “Primary” indicates that these are often the initial views we consider when designing an architecture.

To draw an analogy, think of this approach as akin to painting with colours. There are primary colours that stand on their own and cannot be created by mixing other colours. Similarly, we can create a set of Primary Views, which are views in their own right, concocted using a small set of architectural elements for a specific aspect of the architecture. Subsequently, by utilizing elements from these Primary Views, we can construct Composite Views that depict multiple perspectives of the architecture and facilitate the exploration of alternative architectural solutions.


Primary views offer a singular perspective of the architecture, and these perspectives typically align well with the following aspects:

  • Why – the motivation behind the architecture, why it’s needed.
  • What – the composition and structure of the architecture.
  • Who – the stakeholders and actors involved in the architecture, addressing organizational design.
  • How – the behaviour of flows and activities within the architecture.

Addressing views using a “Why,” “What,” “Who,” and “How,” approach, allows for a systematic and manageable way of gaining consensus with stakeholders by addressing one aspect at a time. The following sections provide examples of some commonly used views using a car workshop scenario to illustrate this approach further.

Setting the Stage for Effective Architecture

Before embarking on any architecture assignment, it is crucial to understand the underlying motivation, or the “why,” behind the architecture. This motivation often stems from the business strategy and vision, which outline its objectives.


These objectives serve as the cornerstone for defining architecture principles and requirements. Whether it’s a simple list of objectives or a cascade of goals, reaching an agreement with stakeholders on these objectives is essential for a successful architecture project.

The Concept of Capabilities

The concept of capabilities plays a pivotal role in architecture, encompassing processes, people, and technologies. A capability, in essence, defines “what” a business does to create value.


Creating a capability map helps structure these business capabilities. While these capabilities involve processes, people, and technologies, our focus here is on understanding what the business needs to do to deliver value, rather than delving into the intricate details of how it’s achieved. Creating primary views for capabilities helps stakeholders understand what is required to create business value.

Understanding the Organizational Landscape

The organizational structure in an architecture is often expressed in actors. This addresses the “who” aspect by describing those who interact with the elements in the architecture. These actors may be roles, departments, companies or other types of organisational entities.


Visualizing this can be done through organizational charts, helping ensure that all stakeholders share a common understanding of the organization. Creating primary views for these actors helps stakeholders understand who will work with processes, technology or solutions in the organisation.

Navigating the Realm of Information

Information, in architectural terms, can be represented by classes or objects. A conceptual information view defines the information within the architecture, addressing the “what” aspect.


These views clarify the relationships between information objects and provide descriptions for each object. This common language aids in fostering shared understanding among architecture stakeholders about the information structure. Creating primary views for information helps stakeholders understand information which is required by the organisation and how that information is related and structured.

Mapping the System Landscape

A system landscape provides an overview of applications, systems, and solutions, including their relations. This view defines the systems within the architecture which also addresses the “what” aspect of the architecture.


It illustrates which systems exist and their relationships, even if the view may not provide specific details of the types of relationships. Each system has a clear description, facilitating stakeholder agreement on the required technology to support business operations. This view works equally well for system components.

Exploring Process and Flow

Processes and flows articulate the sequence and pathways of activities, addressing the “how” aspect of an architecture. Flows provide a description of behaviour within the architecture.


This view provides stakeholders with an understanding of how the architecture behaves in various scenarios, and is applicable to both organizational and technical processes.


As we move beyond individual aspects of architecture and are tasked with solving specific problems, a single perspective is no longer sufficient. Composite Views emerge as a way to combine elements from Primary Views, which stakeholders already understand and agree upon. By leveraging these elements, architects and stakeholders collaboratively create different solution alternatives. These Composite Views are composed of elements from several Primary Views, building upon the foundational understanding provided by the latter.

Illustrating Workflow with Information

Consider a scenario where we want to establish a service for processing customer orders, building on the Primary Views. The following shows an example of a composite view detailing workflow and information.


This view provides a visualization of the activities in the workflow and the required information at each stage. The emphasis here is to show “how” the service operates, “what” information it utilizes, and when it’s employed.

Visualizing Workflow and Technology

In the context of the same customer order service, we can explore which systems support the workflow as orders are processed. Additionally, we may identify the roles or actors that require access to the system for their work.


The Composite View above illustrates another view of the same customer order service, but this time it shows “how” the workflow activities, “which” systems are used, and “who” utilizes them.


Working collaboratively with stakeholders on Primary Views lays the foundation for consensus on the fundamental architecture structures and behaviours. It offers a platform for addressing more intricate architecture challenges. However, Primary Views alone do not provide solutions.

Composite Views, on the other hand, offer a means to explore numerous alternative solutions for a given assignment. Their effectiveness is enhanced by stakeholders’ familiarity and agreement with the Primary Views.

Working with Primary and Composite views is an iterative process, since it is unrealistic to design all Primary Views up-front. The design process will involve evolving and revisiting the architecture model and views in each step of development. This leads to refining architecture models, and incorporating new insights into the model, driving the creation of new Primary and Composite Views. In this way, the architecture evolves, and views help in understanding the consequences of change in alignment with stakeholder needs. This is akin to mixing colours on a palette, allowing architects to shape the architecture into diverse solutions as understanding deepens.Top of Form


The concept of Primary and Composite Views is a guiding principle, which allows us to break down complex architectures into comprehensible visualizations. Primary Views capture the essence of single perspectives, while Composite Views enable us to piece together a holistic view and explore innovative solutions, much like an artist mixing colours to create a masterpiece.

This offers a platform for architects and stakeholders to collaboratively navigate intricate architectural challenges using an iterative process where Primary Views provide a firm foundation, and Composite Views allow us to paint a diverse array of architectural solutions, adapting to evolving stakeholder needs.

In essence, just as a skilled artist creates a masterpiece by blending colours on a palette, architects can shape an architecture that meets the multifaceted needs of their organizations and stakeholders using Primary and Composite Views.

Stephen Dougall is an EA consultant with CGI in Sweden. He has been a practicing architect for over 20 years in a number of industry sectors and is passionate about furthering the architecture profession.