A Case for Logging

clip_image002I have been writing off and on about a report processing automation project we are working on for our engineers. As far as report production goes, this is a pretty complex task. These reports go through a healthy review cycle and then they have an afterlife where they feed separate analysis and review processes for years to come. One of the features we added to this process this past week is a Log List.

You might ask “do you really need to log this activity?” – I mean a workflow controlled process is pretty easy to review. The process is driven by a status field, a task list and it feeds a few libraries; surely a quick look in those places will tell you what is going on with any particular document. True, but why make someone look in all those places when we can let them look in one place and see everything? Are we recording duplicate information in this log? Yes! Is this log necessary for control or auditing purposes? No! Did the users ask for this feature? No! The users did not ask for this feature, but I am betting that when we review this with the department manager next week, he is going to say “I like that”.

Logging is a function that we have been making greater use of recent years. It used to be that you logged transactions; period. That was because you needed to log transactions and logging was somehow expensive. Log files take up space. If you don’t think that is a serious concern, ask your Systems Administrator about log files. Logging activity requires extra code. A log database or list has to be built, information has to be gathered and somewhere, a line of code is added every time a log entry needs to be made. Logs need to be explained. Depending on the function being logged, the log files range from self-explanatory to cryptic. At the far extreme, we have Microsoft, whose system logs have spawned an industry that builds log analyzers and log reporting applications. At the opposite extreme though, is the workflow log that simply says “workflow complete”. Our target is somewhere in between, something with enough detail to chart the progress in layman’s terms, but not something that requires the completion of a course in log reading.

What about Dashboards? That question came up in our internal discussion, and we decided that there is an important difference between dashboards and logs. Dashboards are snapshots, a delightful view of critical information that you can quickly check and get happy or become concerned with something you are responsible for. Logs are more historical and more detailed in nature; logs are meant to support a more thoughtful review.

What about Auditing? When something needs to have an audit trail, it’s because somebody want to see that audit trail. They want to know specific things, but I don’t think an audit trail needs to support a thoughtful review. Audit trails are more like a Watchman’s Clock, they record activity for compliance sake. A useful process log is just that, useful. It contains the information that charts the progress of a process, points to where something went off the rails, and tells you about activity between milestones. That last point is important. If we simply look at document status or the activity of a workflow that is driven by document status, we will notice when the status changes. In our log, we also track when the document is saved but the status wasn’t changed. This indicates two things. First, our workflow is working, and second, that the document owner is still working too. No one needs to wonder if the owner just forgot about this document or is ignoring this task. That’s a simple example, but it’s the kind of information that is useful in an environment where people travel and there is no opportunity to simply visit someone’s cubicle and ask “how are things going with the … report?

We introduced this type of log in a transaction processing system over a year ago, and it has captured some interesting results. One pattern of activity we see tells me that they system doesn’t work well enough in support of the user. Too many attempted (or perhaps test) transactions are being performed. As I discuss this with the user, I hope to make this system better. I’m not sure what the process log in SharePoint will tell me, but if it helps us improve the process down the line, it will have been worth our time. If it proves to be useless, we can always delete it.