![]() ![]() The infrastructure diagram is a “what you see is what you get” model. ![]() These diagrams also help developers who are new to a domain and offer insightful context into what they will be building. Be sure to label the personas, the workflow, and any assumptions of how the business process gets from one step to the other. This type of diagram tends to be lower level, as it includes more detail than the others. Make use of swim lanes to show the different actors in a workflow. The architecture persona diagram dips into the BPMN model a little bit. Showing them a graph of who does what, when will perfectly describe what your system is doing. They are focused on personas and how they interact with the system. This is your best tool for proving that you’ve taken the business into consideration when developing your solution.īusiness oriented individuals and product owners are the intended audience for this type of diagram. A persona diagram describes a chronological view and actors in a particular workflow. It is important to show that your architecture solves the business problem. This is all about the services that make an application run. Label which services communicate with each other and be sure to make the distinction between services your company owns and services that are external.ĭetails into how the services work are not necessary in this high level diagram. When building an architecture service diagram it’s good to list all the microservices that make up your application or ecosystem. They want to know connections between major applications and there is nothing better than the service diagram to represent those connections. I often use this diagram to describe how systems work to executives. They care about any connections you’re making to outside services, plus they need to know if any internal connectivity needs to be monitored. IT and network engineers tend to be most interested in this type of diagram. This is a diagram intended to show the internal vs external services used in an application. It does not show any detail into how the workflow or service works, but instead shows the major pieces at play. The Service DiagramĪ service diagram illustrates connectivity from a high level. It shows how data flows through the system. No details are described in how the pieces interact with each other, but it does show the connections. In the case of our serverless AWS environment, we label each managed service and which ones communicate with each other. The major component to the architecture flow diagram is to include all the moving parts. It may be used to pitch an idea to an architecture board or describe how a business process works to a developer. ![]() The audience for this type of diagram is generally technical. This diagram illustrates the moving parts in a business process. It is a medium-high level diagram that shows all the pieces of a workflow. The most generic and generally broadest reaching diagram you can make is the flow diagram. 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. Today we are going to talk about the 5 different types of diagrams you should make depending on 5 different audiences. If you want to get your idea across to different sets of people, you must make multiple versions of your diagrams. Your diagrams must take that into consideration. 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. Architecture diagrams are not a “one size fits all” solution. I needed a visual.īut not just any diagram. I was trying to build a mental model while following a train of thought. Words get lost when explaining complex conceptual architecture. I understood the words coming out of their mouth but they don’t make sense strung together. They were explaining the solution using hand gestures and a lot of “and this piece communicates with this one by…”. It had about eight different components to it and they all interacted with each other in multiple ways. I was having a conversation with a relatively new solutions architect who was trying to describe a system they had come up with. Have you ever been in a meeting where someone is trying to explain how a software system works? ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |