The Trouble with Toolkits
- October 30, 2018
- 0 Comments
Editors 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/
The trouble with Toolkits in IBM Business Process Manager (BPM) – is that sometimes it is just too easy to create another one!
That is a big statement and it requires some qualification so let us first take a look at what constitutes some examples of bad practice with Toolkits.
- If a Toolkit includes other Toolkits then you are probably going to exacerbate Dependency Management problems down the line. Of course, it isn’t always possible to isolate your Toolkits entirely, but just bear in mind that it will generally be much easier to manage 10 Toolkits with no dependencies than 3 Toolkits that include another 5 Toolkits as dependencies
- Upgrade your Toolkit dependencies as soon as you possibly can. If you don’t then you run the risk of building up considerable technical debt that will increasingly inhibit your future deployment agility
- Having a large number of Toolkits in and of itself is not necessarily a problem – it all depends on how you build them
The worst examples that I have come across – based on code customers have shared with me via our Neches TWX analysis tool – have perhaps as many as 40-50 Toolkits in total. A single Toolkit can include up to as many as 15 other Toolkits which may, in turn, be nested up to 5 levels deep! I think it is safe to say that they are overdue for rationalisation and reorganisation to reduce the number of internal dependencies and the nesting depth.
They might, ultimately, end up with a greater number of more tightly focused Toolkits but, as above, it isn’t the absolute number of Toolkits that is necessarily the problem. Even a larger number of more focused Toolkits will result in the overall estate being easier to maintain and will open the doorway to improved development and deployment agility meaning that changes can be deployed to Production both more quickly and more accurately.