BPM Patterns: Replacing Systems
John Reynolds, now at BP3, previously wrote this post on LinkedIn on replacing core business features over time. In the context of legacy systems, replacing core business features is a much more complicated proposition. Effectively you’re stepping into the territory, as well, of replacing systems.
This is one of the core BPM Patterns- using BPM to define the business functions and features independent of specific legacy systems. The end result is a representation that is independent of technology (BPMN / DMN / CMMN), and a roadmap for gradually implementing the core functionality, and/or decommissioning the old systems.
“This scenario of replacing existing business functionality is very common, and it’s a scenario that complicates Agile’s tale. With Waterfall, users stayed on the old systems until the full replacement was ready – With Agile, functionality comes online as it’s ready to use. This is both a good thing, and a bad thing.”
John lays out the roadmap for how this works perfectly:
- If both the old and the new system can now be used to perform a task, the user has to decide which system to use.
- If the “replaced” functionality is “turned off” in the old system, then the user now has to navigate between the two systems (and that’s generally a lousy user experience).
- The third option is to keep the old system running until the new completely makes it redundant, and then move users over – but that destroys much of the value that Agile brings.
Check out his post for the rest!