I thought I would spend a little time discussing an aspect of dependency modelling theory. I have spent that last couple of weeks working with a client on modelling their business for business continuity purposes. There was a great deal of discussion regarding how to model dependencies within the organisation (internal dependency). We use a specific technique for this which is far more effective than other less structured techniques we have seen.
People often make this type of dependency far more difficult to comprehend than it actually is. They tend to note far too much detail due to their own knowledge of how the business operates. Let us assume that the activity for which you are responsible depends on the finance team to pay your suppliers. Often you will see this noted as an internal dependency with mention made of the finance team themselves. This is of course incorrect. Your activity does not depend on the finance team but actually depends on the Finance Department delivering a process called Supplier Payment. You should depend on the process not on the team which in part delivers it. This is the correct approach for a number of different reasons:
1. You do not have perfect knowledge of how finance delivers this process. Beyond the finance team there will almost certainly be other resources that finance consumes for which you have no knowledge. It is for finance to determine these not you.
2. You do not have knowledge of how this process may be delivered in the future. It may be outsourced, or modified in some way. As long as the process behaves in the same way you do not actually care how it is delivered. Imagine if you and others modelled the dependency in detail making mention of the finance team. Now every-time the supplier payment process changed you and others would need to update it, making the upkeep of the model unmanageable. In essence you have now carried the dependency through to your model which will only create the same types of coupling problems there.
Related posts:
Recent Comments