Protecting Your Software Investment. Rule #3: Document

We have covered the first two rules for Protecting your Software Investment from “yourself”: Separate and Control. This week we will round off with the final rule: Document.

What do we document? If you have gone through a certification process, such as ISO 9000, GMP or TS16949, then this is really just applying your Quality Management System to your business IT systems.

We have two purposes to our documentation:

  1. Communicate what the rules are
  2. Keep a record of what we have done

To Communicate the Rules you should”

  • Separate: where are the following items to be kept, and are they allowed, and who is allowed to make these changes/additions:
    • Reports.
    • Extra database tables.
    • Scripts.
    • Changed executables. In this case you want to specify that original versions are to be kept, who is allowed to make these changes and where the originals are to be kept.
  • Control:
    • Software:
      • Where system snapshots are kept
      • How often they are to be taken
      • Who is responsible for taking them
      • How to restore them
    • Interfaces:
      • What interfaces are ‘open’ for use
      • How these are to be used — especially what credentials (eg username/password) are to be used, or where to get legal credentials from
    • People:
      • These rules!

Keep a Record
I find a ‘light touch’ is best on record keeping. While it would be nice to know every detail about who made what change or addition and when, the more burden you place on people, the more likely they are to go around the records rather than keep them, and then you have lost not only the “nice to have” information, but also the critical.

Most of the Separate and Control rules we have put in place are self documenting: meaning the presence of a report in the reports directory is a record of its existence, when it was created and probably by whom. Any uncertainty about what is obsolete/still in use can be cleared up by an email asking people to claim their extensions by a certain date after which they will be removed. What is critical though is to keep a record of any replacements, especially executables: what new file(s) replaced what original(s), and where the originals have been saved.

That wraps up my series on Protecting your Software Investment from yourself. With a little care: some separation around your software systems, some control of who can connect to them and how, and finally documentation of the rules and what is done, as it’s done, you can exploit the information and capabilities of your systems, without risking the future of your business!