How to provide good documentation

All the different design steps have some deliveries, usually in the form of a document representing the specific design and explaining the different choices. In order to realize good documents, it’s really important to detail first the logical and physical designs on different technical aspects, as will be discussed later.

Then, you can start from scratch, or reuse some design patterns or templates from previous projects. Most of the projects for small environments are quite simple and almost the same; for example, ones with just a single vCenter, three ESXi nodes, and so on. In this case, a generic logical design could probably be recycled for multiple different projects.

Consider also that simplicity could be the key to a successful project; the more complicated a project is, the more complicated its documentation will be, and the more risks you can have in the deployment and implementation phase, the more complex supporting and troubleshooting it will be, and the more effort the management part will require. Of course, scripting and automation could really help in the deployment and management of complex infrastructure, and good monitoring tools could help to prevent issues and also in troubleshooting. If you still try to keep things simple and clear, you can have some advantages.

For big projects, you need something more, and usually, it’s used as a building block approach with different pods (or blocks) based on some kind of reference architecture, designed from use cases or best practices.