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…
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.