I was reading over Robert Martin's PDF on design problems and solutions to accounting software. I have yet to finish the PDF, but the problem they described was so familiar to me in some ways.
In fact, it is to do with policy/rule changes. Along with scheduled tasks.
Case in point. Two companies had a contract between them, the sale of a particular material at say $x per piece. Payment is usually after delivery, and there is a scheduled delivery two months later.
One month later, and the company signed a new contract, at $y per piece. So, when the materials are delivered, which rate should it be using?
It is entirely likely that the answer is, it depends on what the business wants for that particular contract. For some companies it might be $x, others at $y.
So when we develop such a system, we must first take care to not bind the delivery to a fix rate of $x.
On the other hand we should not bind it to the current value from the contract too. These are such major decisions that the system should avoid making.
In such a case, it would help to escalate the issue to a business user, informing them of the situation, and the choices.
Such a system is of course much more complicated, but it is likely what businesses want. They want automation, and the ability to intervene.
But remember though, for every intervention and decision, it should be recorded and audited, as part of the request history for future reports and audit purposes.
There are of course, many other similar cases where the variables of a system when a task is scheduled is very different from when it is to be executed. Email sending, account creation and deletion, role assignment, etc (mostly in the context of identity management since that is where I'm concentrating on).
But the solution are similar. Avoid binding values at schedule time. Verify that all is the same at execution time. If any differs, leave it to the business users to decide. They may decide to sell at a loss now to earn more later. The system can never advise or decide that.
Posts
