Master the Conceptual Solution Architecture Diagram

Dan Hughes
January 1, 2022
Man drawing diagram on whiteboard

A solution architect needs to facilitate clear communication at the intersection of business needs and technology solutions. They use conceptual solution architecture diagrams to iterate on a high-level design and share that design with business and technology stakeholders. How do you get from "put whatever you want on the page" to a just-formal-enough notation for conceptual diagrams? Keep reading.

What is a Conceptual Model?

An architecture diagram depicts the conceptual model for a system; in our case, the system is the interconnected technology components creating a solution architecture.

A conceptual model's primary objective is to convey the fundamental principles and basic functionality of the system which it represents. Also, a conceptual model must be developed in such a way as to provide an easily understood system interpretation for the model’s users.


Wikipedia continues with four fundamental objectives of a conceptual model:

  • Enhance an individual's understanding of the representative system
  • Facilitate efficient conveyance of system details between stakeholders
  • Provide a point of reference for system designers to extract system specifications
  • Document the system for future reference and provide a means for collaboration

This definition provides a wide range of interpretations for a conceptual diagram. Based on it, all diagrams depict conceptual models. In this case, we are trying to select the best diagram for the conceptual level of solution architecture. I would then add a few other goals for a conceptual diagram:

  1. Provide a presentation-level "marketecture" view of the architecture, understandable to non-technical audiences
  2. Use a simple notation that is easy to use and easy to read
  3. Clearly describe a solution architecture by trading off precision and completeness for clarity

So, to summarize, a conceptual diagram is an illustration depicting the arrangement and relationships of the significant components of a system by using a basic set of appropriate symbols that are easily understood. Conceptual diagrams are an effective tool to communicate complex information simply.

Conceptual Solution Architecture Diagram Notation

Given the high level of abstraction for a conceptual solution architecture diagram, you usually draw one using a block diagram. A block diagram models architecturally significant components as boxes and the relationships between them with lines. In this sample, architecture tiers are represented as columns.

Sample Block Diagram
Basic Block Diagram

Our recommendation for a conceptual architecture diagram is a tiered block diagram that reads left to right, connecting users to the system building blocks that are creating the solution. In our people-centric solution architecture process, the people are always the star of the show. We only build technology solutions for people, so people need to be the star of any story about our solution architecture.

The boxes represent architecture significant components (usually applications and platforms at this level) that make up the architecture, and the lines connect those components. The tiers we use are users, channels, user experience, middleware, and back-end resources. Let's look at an example, and then I will walk you through our recommended architecture tiers.

Conceptual Solution Architecture Diagram

Conceptual Solution Architecture Diagram

The Architecture Tiers

We order the architecture tiers from left to right, starting with user roles.


As I mentioned, our people-centric solution architecture process focuses on the people. The user roles are either copied from your solution user diagram or are logical groupings of the roles on that diagram. You can group the roles into aggregated role abstractions if multiple user roles engage with the architecture in the same way. Our goal is to create a view that describes how the technology components support the users as simply as possible. We use a custom icon (vs. a box) for user roles to highlight the importance of people in the architecture.


These show how the users engage with the technology components. Most organizations have a static set of channels (e.g., web browser, mobile device, desktop application, ATM), so we use boxes with icons for these. The icons help retain a focus on people and provide visual interest to the diagram.

Front-End Experience

Now we start using those boxes! The front-end experience contains components used by people via a channel. For example, if the user is accessing a web-based user interface, the front-end experience column would include the systems the web browser accesses to deliver the user experience.


This tier contains integration components - like services, data transfer hubs, and managed file hubs - that connect the applications. A few key things to remember here:

  • Middleware refers to enterprise capabilities that connect applications and not services that may be a part of any specific application.
  • Correctly scoping the middleware blocks is essential. You don't want to manage low level details (like individual service names) in a diagram. Still, you also don't want a single box labeled "services" to obfuscate the application connectivity.

Back-End Resources

These are the remainder of the components needed to describe the architecture. The only difference between these and the front-end experience layer is that for the architecture you are depicting, the user is not engaging directly with these components. It is all contextual - an application may be in the front-end experience layer for one architecture and the back-end resources for another.

Basic Shapes

As mentioned above, the notation for a conceptual solution architecture diagram is straightforward. You arrange boxes and lines are in the architecture tiers we discussed above. It is not the notation that is difficult; it is the arranging!

Component. The box in the boxes and lines notation. Each box represents a conceptual level component of the architecture. In a conceptual solution level diagram comprised of integration applications, most typically represents an application, service, or data repository. The label can be a specific component name or a function/capability (or both). As mentioned above, we use an icon as a label for channels.

Connection. The line in the boxes and lines notation. Used to identify a relationship between components. Can optionally include arrowheads on one or both ends to indicate a directional relationship (omitting arrowheads also indicates bidirectionality).

  • We use a solid line to indicate online/transactional connections. These rarely have arrows.
  • We use a dotted linefor batch/bulk connections. These always have arrows on one or both ends.

People. The users on a conceptual solution diagram. Pick the person or people icon of your choice. Treated like any other box in terms of usage, but people like to see where people fit when looking at a conceptual level solution diagram.

Note. Pretty self-explanatory! Used during drafting to capture open questions and when publishing to provide clarifications. It should be used very sparingly on completed diagrams.

Happy Diagramming!

That pretty much covers the basics. I will be covering some advanced techniques for conceptual solution architecture diagrams in a future article and strategies for abstracting the middleware components at the right level. In the meantime, here are a few tips to help you get started.

  • Adding your users is a great place to start a conceptual solution architecture diagram. Then work through any architecturally significant use cases and add components needed to support each.
  • Don't worry about connection details beyond whether they are online or batch. Once you have a conceptual design, you can drill down into more detail, including creating an information flow diagram.
  • When in doubt, leave it out! This view is high-level and abstract. It is okay if it is not 100% accurate or complete. The goal is to communicate the cpnceptual architecture; accuracy and complete coverage can come later.
Dan is the founder of Wittij Consulting. Prior to founding Wittij, he spent a decade in software development before moving into IT architecture, where he created an Open Group recognized architecture method and led delivery of all services for a company specializing in enterprise and solution architecture for 15 years. He is an energetic, thoughtful leader with an ability to engage and motivate people, and has been called a “force multiplier” for his ability to not only deliver great value, but also increase the value and capability of the people around him. Dan is a strong facilitator, able to understand and resolve complex disagreements with diplomacy. He comprehends and communicates clearly both at the detail level and the boardroom summary level to both business and technical audiences. His knowledge of enterprise techniques and technologies is broad and deep, and includes industry expertise in manufacturing, financial services, banking, health care, insurance, regulatory compliance, and NGOs.
Copyright © 2024 Wittij Inc.
crossmenu linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram