Do you have dependency management nightmares?
- November 6, 2018
- 0 Comments
Editor’s note: This is a series devoted to the migrations from the IBM Digital Process Automation eclipse based designer to IBM Digital Process Automation’s Web Process Designer. To start your readiness check register for our questionnaire here: https://info.bp-3.com/webpd
Well, do you? When did you last check in IBM Business Process Manager (BPM) to see? If you don’t have nightmares then in my experience that is probably because you probably haven’t looked recently. If you aren’t sure how to check this then I recommend you try the BP3 Neches TWX analysis tool which will run a check on your toolkit dependencies for you (for free). I think you might be surprised by what you find. The first step towards sleeping more soundly at night is to know whether or not you have a problem.
What exactly is a Dependency issue, anyway? We define a Dependency issue as having more than one snapshot of a Toolkit within the scope of a Process Application. Most often this occurs when Toolkits are nested. Different Toolkits themselves include different snapshots of the same Toolkit. As a specific example consider a Process Application that includes Toolkits A (v1.0), B and C. Toolkit B includes Toolkit A (v1.1) and Toolkit C includes Toolkit A (v1.2). So, in the scope of the Process Application, there are now three snapshots of Toolkit A!
What we see is that problems with Toolkit Dependencies increase broadly exponentially with the number of Toolkits and the levels of Toolkit nesting. So, if you have a lot of Toolkits – and they include other Toolkits – then the chances that you don’t have some sort of problem are probably vanishingly small.
Once you know that you have a problem then how will this manifest itself? The most common problem is that to fix a defect you either have to migrate to an existing later snapshot of the same Toolkit or you may have to apply a fix to the Toolkit and take a new snapshot. Either way you need to update the Toolkit dependency. If the Toolkit is directly referenced from your Process Application then that isn’t so bad – just quickly re-test the Process Application and re-deploy it.
However, if the Toolkit that has changed is indirectly included via another Toolkit then the problem is more substantial. The enclosing Toolkit will also require to have a snapshot to include the new dependency. However, if this enclosing Toolkit is somewhat out of date then you will inadvertently be introducing a range of other changes that must now be tested in the context of your Process Application – and all of a sudden we have an exponential explosion! The most likely consequence when this situation arises is that you end up expending a lot more effort [regression] testing than you had originally budgeted for. The impact of this will be reduced deployment velocity. Or in extreme cases people skip the testing in order to maintain velocity and then encounter defects in Production!
Another consequence of Dependency Management problems is that you are more likely to be using tracks, which introduces yet another level of complexity in managing your codebase!