Network diagrams have a specific aim and are often used for diagramming the infrastructure or operational view of a System Architecture. I – personally – find it a good starting point for developing architectures. The reason is that network diagrams are a handy “tool” to capture a very high-level view of a system and enable you to refine the System Architecture in subsequent iterations until you reach the level of detail you aimed for.
Software Architectures have an internal and external view. The internal view shows the internal technical and functional structure of the software. The external view shows how the system is embedded into the existing context. This entry illustrates how Network Diagrams can be used in Software Architecture to develop the external view of a system’s Architecture. It is an ideal starting point for the continuing refinement of the system’s Architecture as it gives an end-to-end overview on the Architecture’s individual elements early on.
Network Diagrams are a handy way of diagramming the end-to-end Architecture of a system. Often Network Diagrams are used in the context of infrastructure-savvy Architectures. In this entry I wanted to explain how network diagrams are particularly helpful in developing the external view of a system’s Architecture.
When I start working on the Architecture of a software-based system it is often not clear where to start. In most cases it is due to lack of detailed knowledge about the future IT system. What I need at this point is a utility that helps me capturing high-level aspects of the architecture so they can be refined systematically.
Network Diagrams provide exactly this. They can be started at a very coarse-grained level and in addition be used to iteratively refine and document what is being learned about the architecture.
3. Network Diagrams
Notation for Network Diagrams
Network Diagrams are fairly free-form and have no specific notation. They are best drawn by hand or in a charting tool. Network Diagrams will contain all infrastructure elements relevant for the IT system constructed. Typical elements are:
- Workstations and Servers,
- Networks and Firewalls,
- Infrastructure components – for example load balancers – relevant for the IT system developed, and
- other IT systems relevant – for example interfacing systems.
Step 1: Develop a high-level Architecture
First I crate a draft Architecture for the future system on a very coarse-grained level. The easiest way to do this is by examining the non-functional requirements and deriving an architectural design from those.
Important in this step is to capture the external view of the Architecture; i.e. to identify then physical nodes – workstations or servers – the system is going to be deployed to and their respective locations. For example: The system has a server that is hosted in a computing center, and a client that is deployed to branch offices.
Remember, that the Architecture created in this step is not final, will lack detail and that this is all right. Details will come at a later point.
Step 2: Outline the Target Environment
The purpose of Step 2 is to identify the environment the future system is going to be placed into. The activity is not difficult. Just interview the individuals knowledgeable about the target environment. I will typically do the following:
- Identify locations the future IT system will be placed into (clients and servers), and
- Identify the locations the interfacing systems are located in.
The figure above shows a simplified IT environment. The fictional system consists of a server and a rich client. The target environment contains the following locations:
(L1) A branch office the rich client will go to,
(L2) The hosting environment the server will be deployed to, including an interfacing system (N3) that is hosted in the same location.
In addition it contains schematic drawings of firewalls and a wide area network. Those are potential constraints that will need to be considered when refining the architecture.
Step 3: Add the future system’s nodes to target environment
Step 3 is all about adding the future system’s coarse grained physical components to the existing environment and identifying the connections that are necessary for the system to work.
Step 3a – Place the future system’s physical nodes into the target environment
The figure above shows the environment with the future system’s components added. In addition it shows the connections between those components. Those are:
(N1) the client application, and
(N2) the server application.
Step 3b – Identify the connections between the system’s components so it becomes usable
We have identified a connection between the client and the server (C1). In addition a workshop with the sponsor’s IT Architect has surfaced the existence of an EAI – Enterprise Application Integration – application (N4) that can be utilized to integrate the future system (N2) with the interfacing system (N3). This leads to the connections C2 and C3.
Step 4: Refine
Now refine the diagram iteratively as long as there are open questions. For example network protocols used, technologies chosen, physical aspects such as clustering, infrastructure capacity requirements, and others.
The process of refinement is not something that needs to happen right at this point in the process but gradually over the course of the architecture definition phase.
I have found network diagrams an ideal entry point into the process of developing Software Architectures. Important is to develop breadth in this first step and to avoid going too much into detail.
Use the information available to successively answer the remaining questions and surface still remaining questions in order to refine the architecture.
The more experience you get with developing architectures the easier this process will become. Using architectural patterns will make the process of learning easier as you will benefit from experiences made by others.
[Amb2009] Ambler, S. 2009, “Network Diagrams”, Agile Modeling (AM) Homepage [online] available at http://www.agilemodeling.com/artifacts/networkDiagram.htm
[Pic2010] Pichler, M. 2010, “Documenting Software Architecture for Business Applications”, Documentation of Software Architectures [online] available at https://applicationarchitecture.wordpress.com/2010/02/04/documenting-software-architecture-for-business-applications/
Copyright © 2010 Michael Pichler