Read this article if you want to learn how I construct network diagrams, the notation and how I put it together. While the notation itself can be put to a broader use, such as infrastructure architecture and others, it is specifically geared towards Software Architecture.
The network diagram is a commonly found diagram in IT Architecture. It has uses in many architectural disciplines – not just Software Architecture. This article will primarily focus on the Software Architecture view, and not consider any other uses.
In this article I am going to outline the notation I have been using and adapted to my needs over the years. I prefer this notation as it is handier and provides a lot more overview than others, such as UML Deployment Diagrams with which it is particularly difficult to convey this amount of information in concise way.
For me the network diagram is an important document. Before even drawing then I develop network diagrams on a flip-chart or on white-boards together with my clients. This is a good way to quickly model a future environment and iterate over it until it fits the requirements.
First I develop a logical view with little detail about the physical implementation. Over time, the logical diagram will develop into a physical one with more detail added. This activity goes along with modeling the Software Architecture. The Infrastructure Architecture determines which network infrastructure is a given and the Software Architecture determines which additional application- and infrastructure-nodes you need.
Sometimes a Network Diagram is referred to as Architecture Overview Diagram. It is fine if this is the purpose of the Architecture. Mostly, it is just one particular view of the Architecture while there are others. In this case I would not call it Architecture Overview Diagram, but create an Architecture Overview (document) that contains a Network Diagram.
2. Typical Use
This diagram is typically used in the following contexts:
- As a quick way to gain an understanding about an environment and as basis for refinement.
- As a tool for placing deployment units (installable components of the developed software) onto physical nodes.
- As work-document for the entire software development project, such as setting up development environments, test environments, performance test environments, etc.
- As deployment diagram/deployment model for software applications. It will be used as input for other architecture and planning work, such as: infrastructure architecture, infrastructure planning, etc.
- As operational diagram. It will be used as input for the operational planning, technical support structures, and others. It may be enhanced to become a walk-through diagram, i.e. showing the how a request flows through the infrastructure from the user to the last node in the chain, such as an E-Mail gateway, database server, etc. This can be very helpful for problem determination.
- As means to communicate the architecture you created.
3. Notation used in Network Diagrams
This chapter outlines the elements I frequently use for network diagrams.
The example illustrates a simple web-store. I have used the notation described above. Let’s assume the web-store has the URL http://www.domain.com/. The store itself is a dynamic web application and available on the URI /store/. The catalog – the second part of the application – is available on the URI /catalog/.
Users access the store across the Internet (a large cloud we don’t know much about). The protocol is HTTP and HTTPS and uses the ports 80 and 443. User requests are directed to the store (if the URI is /store/) and to the catalog (if the URI is /catalog/).
Both, the catalog HTTP servers and the web application servers are clustered.
The connection between the reverse proxy and web application servers is secured, whereas the catalog is always accessed unsecured. The firewall between the DMZ and Intranet needs to have port 443 inbound open.
The nodes in the web application server cluster access the database via JDBC on port 5000.
I will add detail as I learn more. This may be the physical layout of the clusters, availability features, application software installed, software versions, hostnames, and other details. It all depends on the audience of the chart and the requirements you are trying to validate the diagram against.
I also use colors on network diagrams. Sometimes it helps to color different diagram elements based on commonalities or features, such as infrastructure nodes, application nodes, and others.
[Amb2009] Ambler, S. 2009, “UML 2 Deployment Diagrams”, Agile Modeling (AM) Homepage [online] available at http://www.agilemodeling.com/artifacts/deploymentDiagram.htm
Copyright © 2010 Michael Pichler