Architecture Diagram: Best Strategy to Build One.
A comprehensive guide on how to draw a perfect architecture diagram for your project.
Have you ever faced a problem while developing a software product, that when your product becomes big and complex, then explaining it without any diagram becomes next to impossible?
Architecture diagrams are the weapon that can be used by a technical person to explain the entire end-to-end components of the project and their integration.
Now to create an architecture, it is required to have proper guidelines, and tools to draw. A solution architect is generally the technical person who creates an architecture diagram for the product, which is then explained to different stakeholders to make business-related decisions.
Now, these stakeholders could be technical/non-technical individuals. Architecture should be simple yet informative enough that even a non-technical person can understand the entire system. There are many types of architecture diagrams that are build based on the stakeholders, who will be benefited from it.
As it is rightly said that a picture can speak a thousand words and that goes with the architecture diagram as well. Just by looking at the architecture diagram, we should be able to understand the entire flow of the system. Code should never be taken as a reference to understand the project. It should be a follow-up plan.
Since there are no universal best practices that could be followed to build an architecture diagram. These rules totally depend upon the individual organizations. These standards which an organization follows should be uniform throughout the organization otherwise, this would lead to confusion in the longer run.
The most important thing while drawing an architecture diagram is uniformity for example a simple arrow can depict many objectives but this should be decided beforehand, and kept as a legend along with the diagram. An architecture diagram may not be perfect at the first iteration, but it can improve with further development, and architecture is just a blueprint of what an actual product might look like. But this does not mean that the architecture diagram which is been drawn is totally flawed and the final product which is been developed is entirely different. This means that the diagram was built without any prior brainstorming.
Although the time spent developing an architecture diagram will help in making the product scalable in long run. With a good architecture diagram, you can make sure that while you are making a change to a particular component how it will affect the other component in the final product.
Let discuss few things to keep in mind while developing an architecture diagram:
Deciding proper legends.
This is as simple as it sounds before even starting to draw an architecture diagram, you should decide what a particular sign or shape represents, even if it’s a small box because at the end when your diagram is ready and different stakeholders are understanding it differently. Creating an architecture diagram will become of no use. A simple shape will represent different ideologies to the stakeholders.
Most of the developers rush into the drawing of the architecture even without knowing the standards that are been followed by the organization. This could be missed by the organization as well, failing to provide proper training to all the stakeholders about the standards that they follow. So whenever a person joins the organization they should be well aware of the companies standard.
Choosing the right tool.
The right tool to develop an architecture diagram is equally important as deciding the standards. Since in the market, there are many tools available that can be used for building/drawing your architecture diagram but this is also an organizational level decision. If you are working for an organization or if you’re working on your project as a freelancer then it’s your decision to choose the best tool among the available options.
Many organization like Microsoft has paid tool for drawing the architecture diagram. But most of the small organizations or startups won't find it comfortable to spent that much amount to spend on such tools for building the architecture diagram.
Personally, I have found this tool i.e. “https://draw.io” which has many out-of-the-box templates and comes with no operating system limitation. Draw.io can be used on any of the popular browsers Like Google Chrome, Apple Safari, Mozilla Firefox, or also you can download the app.
Mostly, you will be able to find a shape already available in the draw.io tool, but in case if you are not able to find that particular shape which you are looking for you can import them.
Never be rigid
The main agenda of an architecture diagram is to explain the interlink between the different components of a software product. During the initial days of the architecture designing, there are higher chances that the diagram could be modified to make it more relevant and help an organization to save its resources like servers, RAM, memory and make the software more optimized.
If you are rigid with the architecture you drew then you won’t be able to modify it. Before finalizing the architecture diagram, you need to implement and experiment with the different design principles of software development and come up with the best, that suits your need.
Even in the first iteration, you have finalized your architecture diagram, there are high chances that in the next iteration when you are trying to optimize your entire system you might need to modify your architecture diagram,
for example, in the second iteration you want to implement caching so that you reduce the API latency. In that case, you have to update your architecture diagram just to integrate that caching layer into your system.
Being very rigid with your architecture and diagram will kill the purpose of designing the architecture diagram at all. While designing the architecture diagram you should be aware of all the stakeholders who are getting benefitted from your architecture diagram.
This could be stakeholders from the product team, DevOps, or the software developers themselves. Design your architecture diagram accordingly that it solves the need of all the stakeholders.
If the stakeholder is not able to understand the gist of your architecture diagram then it is useless, creating the architecture diagram. In that case, you can directly build your product since your agenda looks like just to make the product ready but not to explain it to others. But always remember that product won’t be highly scalable.
Final thoughts:
So an architecture diagram is a blueprint of the final product which you are creating, just by having a good architecture diagram you are saving yourself from the extra work which you have to do once you face any roadblock when the product is fully ready.
Updating an architecture diagram is not that tough as compared to building the product from scratch. If you have a proper brainstorming session before and after creating an architecture diagram it will for sure help you to understand what is the blockers you might face while you are developing the product.
There are many types of architecture diagrams like application architecture diagrams, designs architecture diagrams, etc. Choosing which to draw totally depends upon the requirement of the organization.
If you are a software developer then understanding how to design an architecture diagram is very important for you, and your career growth, in turn, will help you understand the entire system. You can clear your 90% of doubt just by creating a proper architecture diagram.
Hope you got a good insight on why you should spend your time developing a good architecture diagram. That’s a brief from my side, if you have any questions or query you can ask them in the comments.
