Solutions Architect Tips The 5 Types of Architecture Diagrams

manna magi

Have you ever been in a meeting where someone is trying to explain how a software system works?
I was having a conversation with a relatively new solutions architect who was trying to describe a system they had come up with. It had about eight different components to it and they all interacted with each other in multiple ways.
They were explaining the solution using hand gestures and a lot of “and this piece communicates with this one by…”
I understood the words coming out of their mouth, but they didn’t make sense strung together.
Words get lost when explaining complex conceptual architecture. I was trying to build a mental model while following a train of thought. I needed a visual.
I needed a diagram.
But not just any diagram. Architecture diagrams are not a “one size fits all” solution.
We’ve discussed recently that a significant part of being a solutions architect is effectively communicating your ideas to both technical and non-technical audiences.
Your diagrams must take that into consideration. If you want to get your idea across to different sets of people, you must make multiple versions of your diagrams.
Today, we are going to talk about the five different types of diagrams you should make depending on five different audiences.
We will take an example from my fake business but real API, Gopher Holes Unlimited, where we add a new gopher into the system to be tracked.

  1. The Flow Diagram
    The most generic and generally broadest-reaching diagram you can make is the flow diagram. It is a medium- to high-level diagram that shows all the pieces of a workflow.
    This diagram illustrates the moving parts in a business process.
    Example of a flow diagram
    Photo by the author.
    The audience for this type of diagram is generally technical. It may be used to pitch an idea to an architecture board or describe how a business process works to a developer.
    The major component of the architecture flow diagram is the inclusion of all the moving parts. In the case of our serverless AWS environment, we label each managed service and which ones communicate with each other.
    No details on how the pieces interact with each other are described, but the diagram does show the connections. It shows how data flows through the system.
  2. The Service Diagram
    A service diagram illustrates connectivity from a high level. It does not show any details on how the workflow or service works but instead shows the major pieces at play. This is a diagram intended to show the internal vs. external services used in an application.
    Example of service diagram
    IT and network engineers tend to be most interested in this type of diagram. They care about any connections you’re making to outside services. Plus, they need to know if any internal connectivity needs to be monitored.
    I often use this diagram to describe how systems work to executives. They want to know the connections between major applications, and there is nothing better than the service diagram to represent those connections.
    When building an architecture service diagram, it’s good to list all the microservices that make up your application or ecosystem. Label which services communicate with each other and be sure to make the distinction between services your company owns and services that are external.
    Details on how the services work are not necessary for this high-level diagram. This is all about the services that make an application run.
  3. The Persona Diagram
    It is important to show that your architecture solves the business problem. A persona diagram describes a chronological view and actors in a particular workflow. This is your best tool for proving that you’ve taken the business into consideration when developing your solution.
    Example of a persona diagram
    Business-oriented individuals and product owners are the intended audiences for this type of diagram. They are focused on personas and how they interact with the system. Showing them a graph of who does what and when will perfectly describe what your system is doing.
    The architecture persona diagram dips into the BPMN model a little bit. Make use of swim lanes to show the different actors in a workflow. This type of diagram tends to be lower-level, as it includes more detail than the others. Be sure to label the personas, the workflow, and any assumptions of how the business process gets from one step to the other.
    These diagrams also help developers who are new to a domain and offer insightful context into what they will be building.
  4. The Infrastructure Diagram
    The infrastructure diagram is a “what you see is what you get” model. It represents everything that has been implemented. A low-level diagram in nature, it is meant to be inclusive of everything that exists in a service/application/ecosystem.
    The purpose of this diagram is to show what has been built and how the system currently works. Consider this a blueprint of the application you built.
Comments (8)
No. 1-8


Eye On Government