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!