To encourage the reuse and sharing of artifacts among multiple process applications, you create a toolkit. However, it is very tempting to look at an artifact and think “Someone could use that. I’ll put it into a toolkit.” Before you do so, consider the following advice.

A toolkit, such as one called Company BPM Utilities, that contains all artifacts, might seem to have the following advantages:

• There is only one toolkit dependency and all process applications can use it.
• Everyone knows where to put their reusable code.
• Everyone knows where to find their reusable code.

However, the following consequences outweigh the advantages:

• The toolkit grows and grows, making it too large. Remember all the associated toolkits are exported when you export a process application. If the toolkit that a process application depends on is large, the export is large as well.
• If a process application uses only a few artifacts from the toolkit, all the artifacts in the toolkit are displayed in the choice lists, which makes development less efficient because it takes longer to find the required artifact.
• Every time anyone changes an artifact, someone must take a new snapshot of the toolkit and re-release the toolkit, which causes a lot, sometimes hundreds, of versions of an artifact.
• When there is a new version of an artifact, it is difficult to upgrade the process application. How do you know which of the 100s of artifacts changed or how the change will impact your process application?
• Imagine that you are using version X of a toolkit and version Y of an artifact and you need to make changes to the artifact to make it version Y+1. However, these changes require that you take version X+5 of the toolkit because it has moved on. You must retroactively test all the changes to the other components, even if you don’t want to.

To mitigate these issues, follow this advice:

• Give each toolkit a defined purpose, such as SAP integration, Validation, Logging.
• Assign an owner to each toolkit. The owner manages the toolkit, controlling the versions and the relationships with the process applications that use its artifacts. Furthermore, the owner ensures that anything that goes into the toolkit is consistent with its purpose.
• If you depend on a toolkit and people take new snapshots of it often (sometimes multiple times in one day), you likely find development problematic because you need to constantly retroactively test changes.
• If the artifacts to be shared are in development or changing, or it is not certain if they suit the target toolkit, consider placing them in a candidate toolkit, which is not generally released to all process applications, while the artifacts are still changing. When developing those artifacts stabilizes, move them to the main (release level) toolkit. Process applications that need early access to artifacts that are still not considered stable can have dependencies on both the candidate and main toolkits.

One response to “Tips for designing effective toolkits”

1. Can you provide an example of candidate and main toolkits and the moving stable artifacts to the main release level?

   Reply