(Originally posted 2015-12-19.)
After writing Reviewing The Situation I got thinking. [1]
I’ve known for a long time the WLM Policy (XML) has timestamps in it. The thought was “maybe there’s value in doing timestamp analysis”.
Here is a fragment of a real customer policy, showing a resource group definition:
It’s pretty easy to read. Obviously the XML elements whose node name start with “Creation” or “Modification” are of interest here.
So I modified my PHP code to produce the following two tables:
I’ve tested this with a couple of customers. Basically it counts which years things were created and also modified.
In the real life example there is a gap of a couple of years – a few years ago – but otherwise the story is one of continual maintenance.
In the case of the other test customer it was interesting to hear them translate userids into names; Some of the people were still working for the customer while others had retired. While this might seem like “tourist information” I do believe quite a bit of the job I do is social.
So these two customer cases aren’t huge leaps forward, but it’d be interesting to see what happens when I encounter a customer who hasn’t maintained their WLM policy recently.
There are some issues with this method:
- The precise items created and updated aren’t reflected in this current report, nor are the precise changes e.g. How a goal’s velocity was altered.
- The granularity of items changed isn’t great.
- For an item that has been modified the data only contains the created and last modified date, with no hint of any intermediate changes.
One thing I could fix is producing a more detailed report; For now I have to hunt for the time stamps in the HTML report I produce. So, for example, knowing when a bunch of classification rules were added could be interesting.
As I said at the beginning it was a thought; I’m not convinced there’s a huge amount of value in this but, as with so many new data, evolving code and more experience with real customer situations I might change my mind.[2]