For most people in IT, documentation is not any fun and we wish it would go away (at least that is how I always felt). As our company has grown, I've realized the importance of documentation and the benefits it provides.
When I was an EDI programmer, I was responsible for creating data flow diagrams to show how the EDI documents would get picked up, get sent to the translator, get processed, and what their destination was. Its sole purpose was to allow another programmer to see what I had done, and support the process if I wasn't available. This type of documentation is very limited in scope - it showed one process in my little corner of the world. This is how I think many people view documentation, segregated and static, which is funny for those of us in integration, where it is all about, well, integration.
Rather than using documentation just to set rules and expectations, provide training, or visualize a current process, why not use it to provide insight such as…
- Revealing bottlenecks or redundancies
- Creating ideal state scenarios
- What does the system look like now and if this were a perfect world, what would the system look like in the future?
- What small improvements can we make to get to our ideal state?
- Managing change
- If I make a change to B, how does it affect C, D, etc.?
- Identifying process improvements
- Although a system works fine now, is there room to make it even better?
- Developing an understanding of how data is used
- How are the users that get my output using it?
- Can I give them better, more, or different information that would improve their process?
When I was doing research about the subject of documentation, I ran across a term that I really liked … Documentation Maturity Model. Although the web uses the term for something different, I think it fits my example. As shown in the graphic, as you increase the scope of your documentation, the use of it becomes more strategic.