Modernizing Applications with Minimum Disruption to Business
Digital disruption is the biggest concern that CXOs have today. Modernizing core systems is the most daunting aspect of any digital transformation as applications often run on outdated technologies. Old systems like IBM Mainframes or AS/400 are not only difficult to change but often enough it is hard to find the relevant skill sets to manage them. However, the biggest question troubling customers is how do they change their large monolithic systems with minimum impact to their businesses.
From my experience, I feel that the problem can be solved by looking at the frequency of change that a monolithic application or a cluster of applications/functionalities undergoes over a period of time as a result of changes in the business. Enter the Gartner Pace-Layered Application Strategy, which categorizes applications according to the rate at which they need to change
- Systems of Records (SOR) change in-frequently, possibly in 5-6 years.
- Systems of Differentiation (SOD) change in 1-3 years’ time and are typically used to create differentiation in the market place
- Systems of Innovations (SOI) change frequently (in less than a year’s time) and are driven by changes in the consumer requirements
For a detailed understanding of the categories , refer to the GARTNER PACE layer strategy.
Now let us see how does this solve the problem for our customers when they want to modernize monolithic applications with minimum disruption to business.
Let us consider the example of a policy administration system from the insurance industry:
- The front end layer that serves content across channels needs to be designed as a system of innovation so that it can be changed every time a new channel is added. With the advent of mobile devices, many of the front end systems had to be rewritten in order to provide a digital experience to these mobile device owners.
- Insurance companies often bring differentiation with new products in the market that offer conveniences such as simplified forms or forms that support auto fill up. Functionalities like pricing engine or product configuration are other examples of systems of differentiation.
- The back end databases on mainframes that store policy data are seldom prone to changes and are possibly the same for all insurers and therefore would be the systems of record.
Given the above mix of functionalities, it would be prudent for the CXO of an insurance company to identify the SOIs and SODs and move them out of the mainframes in a phased manner and let the SORs such as back end databases and data access logic remain. The SOD and the SOI can be moved to a more configurable layer that integrates with the back end SOR through APIs.
Here are the advantages of this approach:
- Changes can be made only where is it impactful to the business and end consumers directly.
- In case of there are multiple systems that are classified as SODs, they can be further prioritized and then isolated from the rest through APIs
- The functionalities that are moved to a layer outside the mainframes can be made configurable and later replaced by Commercial Off-the-Shelf (COTS) products, if necessary
- One can continue maintaining the SORs on the mainframes and apply techniques to optimize them
- The cost of such transformation can be aligned with the business impact and not all the outgo has to be in the first year
The next challenge for the CXO is to identify the SODs. Here are some characteristics of SODs.
- Impact the end users’ experience: This functionality has direct impact on important KPIs for the business
- Change frequently: A configurable rule based system will help make changes faster and without errors
- Are business critical: Any changes in these systems are considered critical since downstream systems depend on this application
There could be other characteristics of SOD applications that are tied to the business domain of the customer. However, this framework helps customers migrate out of monoliths with ease and without undue disruption.