Some years ago I attended a conference where John Zachman gave a seminar about his enterprise architecture framework. Something which stayed with me from that seminar was his approach to architecture models. It is common when we work with architecture that we meet a great many stakeholders. We gather information from the stakeholders regarding the architecture and it tends to present itself as a mix of lots of stakeholder perspectives. A mixture of processes, flows, sequences, roles, technologies, information, and so on…. This is the challenge for the architect, how to untangle this information and communicate the architecture to the stakeholders, and how to reach an agreement with all stakeholders on the architecture. Stakeholders may come from different roles, for example, executives, business managers, technology experts or developers. If we mix many architecture perspectives in a single view without first understanding each perspective on its own, the view we communicate to these stakeholders may be confusing or difficult to understand. It is also likely to be challenging for stakeholders and the architect to reach an agreement on the architecture.
It is therefore important for stakeholders to understand the fundamental perspectives of the architecture, before working with views that combine perspectives. This is where the concept of Primitive and Composite models by Zachman provided me with some inspiration (Enterprise Architecture Defined: Primitives and Composites ).
The primitive models of the architecture provide a single perspective of the architecture. Composite models use a combination of perspectives from the primitive models, elements from the primitive models can be combined to gain insights into the architecture and consider alternative solutions.
Using this concept, I like to think rather like how colours are used when painting. There are the primary colours, these cannot be created by mixing other colours. They are colours in their own right. These colours can be mixed to produce other colours. So if we think about this in architecture terms, perhaps we can create a set of Primary Views, which are views in their own right, we cannot create these views by mixing lots of different architectural elements. Then using the elements from the primary views we can create Composite Views, views that show several perspectives of the architecture and can be used to explore alternative architecture solutions.
Note that I have switched from models to views, the reasoning behind this is that it is the views that provide the communication with stakeholders. We still use a model or multiple models to create the views, however, views provide a communication with stakeholders which is the essence for forming the architecture and meeting the stakeholders needs. The views are the communication method, the models are the architect’s tools.
It is important to note that although Zachman addresses Enterprise Architecture, I think that primary and composite views are just as useful in solution architectures.
Primary Views
Primary views show a single aspect of the architecture. I generally follow the “Five Ws and 1H” when considering aspects of the architecture:
- Why – why we need the architecture (motivation)
- What – what does the architecture consist of (structure)
- Who – who are the stakeholders/actors in the architecture (organization)
- When – when are flows/activities performed (timing)
- Where – where is the architecture used (location)
- How – how are flows/activities performed (behaviour)
Out of these six aspects, I normally focus on views that provide answers to Why, What, Who and How, in that order. I find that it is easier to gain agreement with stakeholders when addressing a single aspect at a time. The following sections show examples of some views I commonly use.
Strategy and vision
Before we start an architecture assignment it is important to know why the architecture is needed, in other words, the motivation behind the architecture. The strategy and vision of a business describe the objectives that are to be achieved. This drives the reasoning for the architecture and is the basis for developing architecture principles and requirements. In its simplest form, this may well be a list of objectives, or cascading objectives. Agreeing on the objectives with the stakeholders is the foundation of any successful architecture.
Capabilities
Capabilities are an interesting aspect of architecture and there are several definitions of what a capability is. In my view, a capability consists of processes, people and technologies and describes “what” a business does to create value. A capability map can be used to detail the structure of business capabilities, and identify which capabilities a business needs in order to achieve it’s objectives.
So the focus is placed on what the business needs to do to create value, and not so much on how it does it.
Organisation
The organisation is often expressed in actors or roles. This describes “who” engages with the architecture. This may be expressed as an organizational chart with communication relationships which help us understand how people interact, their responsibilities, and perhaps even the skills they possess.
This view can be used to describe the structure of the organization, and ensure that stakeholders have a common understanding of the organization. The focus is placed on who will be engaging with the architecture.
Information
Information is expressed in classes or objects. The following conceptual information view shows the structure of information in the architecture. This is what stakeholders create, read, update, or delete as a central method of communication with other stakeholders.
The conceptual information view shows the relationships between the information objects and contains a description of each object. This provides a common language for architecture stakeholders and a common understanding of the information structures used in communication.
System Landscape
A system landscape describes applications, systems and solutions with their relations. This describes which (or what) systems that the stakeholders in the architecture interact with.
The view shows which systems exist in the architecture and the relationships between these systems. It may be enough to detail that there is a relationship between systems without going into details, for example, which information flows between systems, or the nature of dependencies. Each system should have a description which details the purpose of the system, for example, sales support, booking system, human resources…. This allows stakeholders to agree on the technologies that are needed, or exist to support the business.
Process and flow
Processes and flows describe a sequence or pathway through a series of activities. These describe “how” the architecture behaves in a particular scenario. In a primary view we show the control flow of activities, providing a focus on how the activities are performed.
This provides a common view to stakeholders as to how the architecture behaves in certain scenarios. This may be applied to organisational processes, or technical processes.
Composite Views
When we are asked to provide a solution to a specific problem it is no longer sufficient to consider a single aspect of the architecture, we have to consider how these aspects can be combined to create solutions. Having worked with the primary views, stakeholders together with the architect can start to combine elements from the primary views to create different solution alternatives. Since the stakeholders already have an understanding and agreement of the primary views, it is easier to work with fitting the elements together in more complex views, or what I would call Composite Views. Just as the name suggests we create views composed of elements from several primary views. These are more complex views but if we understand the primary views we have a foundation to work from, and by combining elements from the primary views we can create implementable solutions.
Workflow with Information
Imagine we are taking the primary views from the previous section and want to consider creating a service for taking customer orders. In the first instance, we might want to consider the workflow for the service, and the information that is needed at each stage.
The diagram above is an example of a composite view, showing the workflow and the information required for a Customer Order Service. Notice that the concern here is with, how the activities in the service will execute, what information will be used in each activity, and perhaps even when the activity occurs.
Workflow and Technology
Another aspect of a Customer Order Service might be which systems we expect to support the workflow as orders are processed. We may even consider the roles or actors which require access to the systems in order to perform the work.
The diagram above is an example of a composite view, showing the workflow, systems and actors required for a Customer Order Service. Notice that the concern here is how the service will work, which systems will be used and who uses the system.
Other composite views
The example composite views show one possible implementation of the Customer Order Service, but there are many combinations and alternatives we can create by mixing the elements from the primary views. For example, perhaps we want the Mechanic and the Chef Mechanic to work with workshop planning, perhaps the customer order information should also be available in the workshop planning, or perhaps the customer can interact directly with the Sales and Order System.
The value of Primary and Composite Views
Working with stakeholders on primary views allows the architect and stakeholders to agree on the fundamental structures and behaviours of the architecture. It provides a platform to stand on for solving more complex architecture problems, but these views do not provide solutions on their own.
Composite views provide a way of exploring many alternative solutions for a given assignment. Since the stakeholders are already familiar and have reached an agreement on the primary views, it is easier to work with the more complex composite views.
This is not a sequential way of working with architecture but an iterative method. After working with composite views we will find ourselves returning to the primary views and refining them or adding new pieces of knowledge. This in turn may provide us with new composite views. This is how we evolve an architecture, and at the same time build models to help us anticipate the consequences of change together with the architecture stakeholders.
As the architecture evolves we gain a greater understanding of the primary views. We can then use these views to shape the architecture into composite views providing many alternative solutions, just like an artist mixing the colours from a palette.
Architecturality 