As an engineer, I don’t particularly like paperwork; the best aspects of my world are implementations, integrations, and the like. In short, I enjoy the “real engineer meat” of the work. Unfortunately, without papers and documents, there are many opportunities to make mistakes, especially during complicated implementations in brownfield environments.
During my professional career, I have developed a methodology based on experience and mistakes. Everyone makes mistakes; what’s important is to draw conclusions from them. So, what kind of documents do I develop for projects and during implementations? Well, it depends on the kind of project and how complicated it is.
Documentation like HLD (High-Level Design) and LLD (Low-Level Design) is nothing special. During the preparation phase, the first document is the HLD, where I describe how the solution will look and what will be implemented, without specific details. After the HLD is approved, the next document is the LLD, where the entire design is elaborated in detail. Usually, the LLD document is more or less similar to the post-deployment documentation. During implementation, something can change, which is why these documents can have some differences.
HLD and LLD documents are developed during the preparation phase. What about the implementation phase? Ninety percent of the time, implementations involve brownfield environments, so you have to integrate with the existing environment or migrate from one system to the new one. Implementations or migrations always involve some risk. Behind IT systems are business operations, so if I break the network, it will disrupt some systems, and as a result, business operations will be interrupted.
To minimize the risk associated with implementations, I always develop a document called the “Migrations Playbook,” where I specify each step in detail, assign responsible persons, and so on. The template looks like this:
What are the benefits of my playbooks? When I put everything on paper, I think several times about the whole process and its details, so I can often predict some problems or even identify some mistakes. There is definitely some power in seeing it on paper. During implementation, when a lot of business depends on your service quality, there is always some level of stress. Let’s imagine that you are working on a Saturday night to implement something, and if you fail, Sunday morning 2,000 stores will have problems selling products. I have been in such a place many times, so it definitely generates some level of stress. And stress is not a good partner for focus. Using the playbook, I have a detailed step-by-step plan. I’m sure the plan is correct, so I just follow it. At the end, the most important part is verification — verification done by me and verification done by the Customer to check applications/systems availability. Precise verification means no morning phone calls after implementation.
To summarize, there are much more enjoyable things in my work than creating documents, but good quality documents can save your ass 🙂