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.
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
Wikipedia continues with four fundamental objectives of a conceptual model:
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:
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.
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.
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.
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.
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:
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.
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).
to indicate online/transactional connections. These rarely have arrows.
for 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.
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.
