Auditing is a facinating topic to me. So much so that I'm writing another blog post on it.
So, let's assume that we have a UI screen that allows a user to update his particulars. And once the user submits, the data are pushed out to be updated.
The logical thing drawn here is that there should be an audit entry indicating the user initiated an update. Simple, easy. So far so good.
Now, what if the update looked simple, but was not? The user might have updated his name, password and telephone number. And assume that the password has to be pushed to an external legacy security system. The telephone has to be pushed to the company address book system. The name to the company address book system, as well as the HR system.
Each update could fail independently of each other. And since it actually push updates to external system, we really should audit them too.
So now we actually have four audit entries. One for the user clicking submit, one for the secuity system update, one for the telephone sytem, and one for the HR system.
But how do we know the other three updates belong to the same user initiated update action?
The problem gets worse when you had another background workflow that does similar update. So you had a system initiated update, a user initiated, and a bunch of interleaved updates. They could be on the same user, or different. The focus here is the audit log. Imagine how painful it would be to decipher which update belong to which action!
We need to group all related actions. In the example above, the user initiated action could generate an action transaction id. And all the sub-actions should be tagged with the same action transaction id. This allows us to view and perhaps even search the audit log by action transactions, giving us greater control.
And as a random thought, perhaps audit entries could be catagorized with detail level too.
Let's extend the update example furthur. Assume that an approval workflow is involved. There will be audit entries for request submission, approvals, escalations and resolution due to timeout, provisioning, and so on.
We could have a level of audit for request workflow. These are request submissions, approvals, escalations, etc.
Next, a level for provisioning. The target systems being updated, and the data changes.
Depending on what one want to view, they could view a 'business action' audit, or a 'technical' audit.
This is something I noticed missing in the few systems customization project I worked in. And we usually had to build this in. And I always wonder why they never think to build this in.
I'll probably be still pondering on auditing in business applications. I hope to be involved in creating an audit friendly application development someday.
Posts
