‘Change is the Only Constant’ is the statement we all make. We make this fundamental statement & forget about it, especially in our product/solution designs. This single oversight, has resulted in a huge tech debt burden on banks and other orgs.
There is very little support in today’s databases for change. There is no history of changes made to a table structure & no historical table structure view, no support for storage of data being prepared, constructed, accumulated, to be approved before being actually persisted into actual tables. Support for these is left to the solution designer.
Transitions may be micro transitions within a database transaction (enveloped by a Begin Transaction and a Commit) or long running transitions (spanning across a process being run) or bigger transitions like Process Re-Engineering, Banking Product / Service Amendments or Retirements or even Enterprise Level Transitions of Replacing Enterprise banking systems like Core banking.
Transition Design is about providing support to business-as-usual operations during the period with transition is happening.
Most often, transition design is not in the thought process of designers and is also missing in RFPs. Planning and Supporting obsolescence are crucial to reducing technology debt on Organizations and thereby on all of us. We cannot see a single Enterprise Class System where retirement of the system is supported for a gradual and risk-free migration to a new system.
Several Design Patterns have been used by us at Patterns in this much ignored area of Design – Transition Design. For example: TBA Store Design Pattern is used to house Data Yet to Be Approved / Authorized before it is inserted into / updated into database tables. TBA Data plays a crucial role in supporting operations during the period of transition. Transition Bridge Design Pattern can be used to provide support Enterprise Level Migrations involving data mapping, function mapping, process mapping, product / service mapping, etc between the two systems – retiring system and the new system.
Transitions usually bring in reduction in end customer service quality and increased exposure to operational risks. Complexity in transitions and migrations force organizations to keep on using legacy systems, building endless layers of wrappers and continuously increasing complexity and running costs. Technology Debt burden is clearly visible when the running costs in a single year are many times the build cost of a solution.
We can use Hyper Automation with Transition Design Patterns to support large transitions, gracefully and mitigating operational risks during the transition period.
