I've been harping on to the guys at work about the importance of creating deployment diagrams for most, if not all, of the projects we get involved in. At Intergen we work on a wide range of projects from simple web applications to complex integration projects. However, they all have a common requirement of understanding and communicating what is going to be deployed and how to a number of different audiences (other developers, clients, technical services staff).

Creating a deployment diagram shouldn't take long (an hour or so) but can save days of effort resulting from miscommunications and misunderstandings.

If you end up doing these diagrams on paper or in the whiteboard that's fine - it's the communication and thought processes that's important. The diagrams above were created using Sparx Enterprise Architect - it's a fantastic product and very reasonably priced. Check it out.

At its simplest, a deployment diagram shows the artifacts (applications, web sites, components...) and the nodes (servers) onto which they will be deployed.

deployment_simple2

Additionally, if servers need to be provisioned or the items being deployed have specific requirements it can be useful to include configuration details. I usually do this by adding constraints to the node objects in the diagram (using Enterprise Architect you can turn on/off showing constraints on the same diagram).

deployment_simple1

It's amazing how many times you draw up one of these diagrams and while discussing it with others you discover things you hadn't thought about. For example,

  • Is that web server going to be load balanced?
  • So, if you deploy the web services here that means this server over here needs access to it
  • So should what version of SQL Server are we working against?
  • Can this solution be deployed in our share hosting platform?
  • A new developer is joining the team and wants a quick overview of the solution
  • The client is hosting this system and wants to know the specifications of the servers they need to purchase
  • Identifying the artifacts up-front forces you to think (at a high level) what you are going to build (or not build)

A final point - these diagrams are a means to an end. They are not meant to be hung from the walls and framed. They are intended to be a clear and non-ambiguous mechanism to communicate the needs of your solution on the environment into which it is to be hosted.