Revise
Overview
Revise builds further on the Refactor approach with the critical difference that functionality is added or significantly changed. The change in functionality could be a small functional addition, but it could equally be a very significant up-lift - e.g. a new user-interface, an extension to the scope of the functionality or a re-working of existing functions.
These changes might also include some incremental change to the underlying architecture with new technologies added or some technologies changed, but critically the “Revise” option will typically persist with the original core underlying technical architecture.
Benefits
| Time to migrate |  |
| Technical difficulty |  |
| Strategic Value | |
Revise is the first of our patterns where are changing business function. The value of a revision is entirely dependent on the added value of the business function, and any IT considerations take second stage to the potential business benefit.
A Revise will need to be driven by a business sponsor and not by IT, and there will almost certainly be a full business case justification for the changes.
Revise projects will be a joint Business and IT collaboration and will likely be a significant change management project associated with the changes - e.g. for the new functionality there may be a need for user acceptance, user training, end-user education and if the application is customer facing, then a full public release play and activities will be required
The benefits of a Revise project will be limited by the potential of the underlying technology - sometimes Revise will be combined with a replatform to enable new or changed functionality.
The will also be some limitations on potential business benefit by the basic structure of the current application. The more extensive or divergent the new business requirement, then the more likely that a revision may not meet the full business requirement. In this case, a re-build, a replace or a re-imagine might be a better approach.
Challenges
The challenges of a revision are predominantly aligned around the need for business interaction. Where our first few options (Rehost, Refactor, replatform) can all be achieved with minimal business involvement, Revise requires a full business/IT project team; this is inevitably a much greater change than a pure IT change.
In addition, the fact that we have opened up the core functional specification to change means that the impact on any integrations with our system may be impacted. For example if any core data structures have changed, then this may impact upstream or downstream systems, and so where we might have got away with minimal regression testing in the previous options, a Revision is likely to need integration testing, system testing and end-to-end process training. This will be substantially more expensive than regression test.
Even more, if the end-to-end business process or corporate level data has changed as a result of the revision, then surrounding systems will also likely to be impacted, and so this at the more complex end, a Revise becomes a multi-system change project.
Use cases
- any situation where business functionality is being changed or added