Trench Tales: Poor or missing IT documentation can leave you feeling lost

In a previous edition of Trench Tales here at TechGenix, I talked about a friend of mine who has been doing IT for many years and who recently changed jobs, taking on a new position of managing IT for a public company in Vienna, Austria. My friend’s name is Martin Urwaleck and when he arrived at the new company, he discovered that he had his work cut out for him. As we saw previously, one of the immediate problems he was faced with was restructuring the company’s network. This was necessitated by the requirement of bringing the company’s network into compliance with the recently enacted EU General Data Protection Regulation (GDPR) legislation that we’ve talked about a lot on this site.

But that’s not the only challenge that Martin has faced in his new position. Another one that immediately hit him when he joined the company was how poorly the company’s IT systems and processes had been documented. And I’m sure many of our readers who work in managing and administering IT have faced similar problems when they change jobs and move to a new for business and organization. The discovery that your predecessors have not done their job properly and have left a mess behind for you to clean up is a common one, and it’s not pleasant. To illustrate what can go wrong in this area, we’ll start by examining the kinds of problems Martin encountered with respect to poor or missing network and IT documentation at his new employer. Then we’ll look at some of the different kinds of initiatives Martin is taking to try and rectify the problem.

Poor or missing IT IT documentation: Scope of the problem

missing documentation

“Missing documentation has different aspects for me,” Martin says. “The scope includes software, infrastructure, servers, clients, Active Directory, security, and so on.”

Let’s start off with the software development side of things, I said to Martin. “Software development? Only inline documentation inside the code!” he replied. “We have no idea what formulas and algorithms former programmers used for some tasks, which makes reengineering time-consuming and complex. Modifications of existing programs are inevitably risky because we have no complete view of the connection between different modules. So, a fix in one module might break another depending one. And we have a lot of modules, some of them from the late ’80s! I can identify a least three eras of IBM RPG programming in our current codebase.”

And that’s not all. “Infrastructure is another concern,” Martin says. “Having an IP address list is not enough! We have a bunch of LAN components like switches, access points, firewalls, and mail gateways, but there’s no overview of how they all interconnect — not to mention a unified configuration and a documentation of all the different configs.” I nodded my head at this as I’ve encountered a similar situation in many of the established businesses and organizations I’ve worked with or visited over the years.

What about servers? Are they running a recent version of the Windows Server platform? “We are actually just now rebuilding our Microsoft infrastructure by replacing Windows Server 2008,” Martin said. What about client systems? “Windows 7, but we’re replacing them.” And none too soon, I suggested.

“Active Directory is another big area of concern,” he says. The more we use it the more we are impacted by missing documentation. For example, there are a bunch of GPOs linked to different OUs that are interfering with each other. And we even have a modified Default Domain Policy that no one was even aware of.” I grimaced when he said this as the Default Domain Policy should never be modified. “We also have active user accounts that haven’t been used for years. I could go on and on.” Lots to clean up there, obviously!

“Then there’s security,” Martin says. “There’s no written security policy, and as long as I don’t have a written-down policy, I simply can’t stick to it. Security is more best practices than a thoughtful concept.” I asked him also about whether he thought his servers were configured securely. “Well, we’ve found a lot of installed services on them that have never been used and would never be missed. And of course, they expand my attack surface inside our network.”

Solving the IT documentation problems

missing documenttion

It’s time to move on to solutions, so I asked Martin if he could describe how he plans to solve his problem of missing network documentation including which aspects he is prioritizing and how he is approaching them. “I’m doing some tasks right now in parallel,” he replied. “For example, we are now using a tool called DocuSnap for setting up our documentation. This tool allows us to get some information automatically and also add our own when needed. In the long run, I expect to get our disaster recovery handbook out of the information we collect with this tool.”

What about any existing documentation you find lying around? I’m sure that some of it is incomplete or even misleading if it hasn’t been regularly updated. “Yes, all our existing documentation is screened, then unneeded docs are deleted while to-be-updated docs are marked accordingly. New and updated documentation is then reviewed by another peer before releasing it. I expect about six months until this is all finished.” Good process, I thought to myself when he told me this.

“We have also established templates for documentation, and these have to be used when creating new documentation. We are expanding and improving these templates continually.” Aha, that’s another best practice I need to keep in mind when helping companies try and get their documentation processes in order. “Plus, we only approve external work when documentation is delivered end reviewed,” he added. “And preferably based upon our templates.”

I finished off my discussion by mentioning how he had talked about creating a disaster recovery handbook for his new employer. I assumed that was probably going to be a work in progress, and Martin readily agreed. “We actually do a disaster recovery test once a year for both our Windows and IBM environments, and we do this based on our handbooks and documentation to discover any gaps in these documentations.” Now if only I could convince the businesses and organizations I come in contact with to do the same!

Featured image: Freepik

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top