Reuse principles that hold in BPM / BAW projects:
- Reuse by dependency, not by copy - toolkits with snapshots; copying artifacts between apps creates versions nobody maintains.
- Reuse stable things - domain business objects, integration facades, UI house style, utilities (logging, error handling, configuration). Processes themselves rarely reuse well; sub-processes / linked processes only for genuinely identical steps (approval loop, document request).
- Small toolkits by purpose, one owner each, semantic versions, additive changes within a version line.
- Interfaces over implementations - a reused service has a documented contract (inputs, outputs, errors, side effects) and a test dashboard; callers depend on the contract.
- Configuration, not variants - one service with EPV / options beats three copies with small differences.
When reuse becomes too much:
- A "common" toolkit that every app depends on and that changes weekly - each change forces every app to re-test; split it.
- Generic services with many mode flags ("action = create|update|delete|validate") that nobody dares to change - the coupling is now in the parameters.
- Reusing a coach view by giving it 40 configuration options - a second, simpler view is cheaper than the option jungle.
- Toolkit dependency chains five levels deep - upgrades take days; flatten.
- Reuse across teams without an owner - the artifact rots; if nobody owns it, inline it.
The yardstick: reuse pays when the reused artifact changes less often than its consumers and has one owner; when the reused part changes with every project, it is shared code in disguise and should be split or copied deliberately (with a note where it came from).
References