Part 2 | Application Rationalization – A Pit-Stop in the Journey to Transform Enterprise Applications in the Cloud
Part 2 | Application Rationalization – A Pit-Stop in the Journey to Transform Enterprise Applications in the Cloud
Rationalization is a critical part of the App Migration & Modernization journey for an Enterprise seeking to reap the benefits of Cloud and to modernize its applications. The precursor to the Rationalization process is building an inventory of the applications. There are many ways to build the inventory, spanning from using a CMDB, a data collection tool like Movere, or a spreadsheet that is maintained by the EA team.
The Rationalization process defines the “future state of an application”. The future state provides a preview of how the application will look after the migration process is complete. The Rationalization process is largely driven by two primary objectives, the Business objectives for Modernization and IT objectives for Modernization.
As an example, the business may be in a race with its competitor to release new features to a product and gain market share or has a set target to increase the user base for a service or a subscription by x%. It may be looking to exponentially grow the business by releasing the product to new untapped markets or be in midst of a signing a contract that requires the application to adhere to new compliance requirements. These business objectives will influence the Rationalization process.
The IT objectives overlap with the business objectives in all cases and translate into IT objectives besides having IT specific objectives. Agility, automated deployment process, auto scaling solutions, high performant design, providing a compliant & secure environment, and a platform for innovation are examples of IT objectives.
Rationalization can be broadly classified into 7 “R’s”.
The process lends to landing an application in a particular ‘R’. Rationalization is an iterative process. Applications start in a particular ‘R’ may be re-classified to another ‘R’ in the next iteration. Since the overall primary objectives differ from an Enterprise to another one solution may not fit all, there is no set “golden rules” to reach a conclusion, however, general guidelines will navigate the decision making process to a logical conclusion.
Retire – The fundamental question to ask here is “Does the application still provide value to the business?”. Value can be defined on basis of usage. If the application has less than 5% server utilization in 90 days or only a small portion of its functionality is used it may be a candidate to combine it with another application and/or Retire the application altogether. Even if the application cannot be retired the lower environments may be retired and it maintained in only one environment. You may also consider under provisioning the environments to minimize the operating cost.
Retain – An extension to the Retire reasoning is to ask, “If an application is needed should it be migrated, or should it remain on-premises?” It may be a low risk low impact application which is not worth the effort in migration. On the flip side, the application may be using components or may have hardware requirements that is not supported by the cloud provider, it then can be categorized as Retain.
Combing through Retire & Retain candidates narrows the scope of the applications that are truly migration & modernization candidates.
Repurchase – One of the benefits of the Cloud is to lower IT operating costs by outsourcing the maintenance of the environment to the Cloud provider. However, it is still the responsibility of the IT team to maintain the application’s functionality, stability, and health. So, a logical question to ask here is, “Can the application functionality be offloaded?” With the proliferation of SaaS providers, you may find a match for your internal IT applications such as a home-grown ticketing system. Replacing it by purchasing a COTS product or service is an alternative to migrating it to the cloud. Choosing the right product, contract negotiation, data migration, user training are considerations, but Repurchase may still be a worthy option for long-term planning.
Rehost – An alternate term for Rehost is “lift & shift”. The latter term is the literal meaning to what is required to migrate an application to the cloud, i.e. move the server hosting the app to the cloud. With Rehost, there is no change to the application and poses minimum risk to the app. Then why isn’t this the default mode of migration? Simply because there is no modernization of the app, you are simply moving a server from an on-premises datacenter to the cloud. Although there are benefits to moving to a more modern infrastructure, if the goal is app modernization, Rehost does not have much to offer.
The 4 categories above have narrowed the scope of apps to migrate, considered replacing an app with another off-the-shelf product or service and considered modernizing the underlying infrastructure of the app. The next three R’s focus on leveraging the Cloud native Platform-as-a-service to reap the benefits of app modernization.
Reuse – Reuse is the simplest step towards App Modernization. It allows enterprises to reuse the existing application code and provides a short ramp to host the application in a cloud native service. Although the full benefit of using cloud native services are not realized, stable applications with non-fluctuating predictable usage benefit from migrating to a cloud native service such App Service. Consequently, the existing in-house developer skillset can also be reused. Applications that fall in this category are usually re-assigned to another category as the Enterprise gains maturity in cloud adoption, for ex: by moving it to either of the next two categories.
Rearchitect – Enterprises looking to standardize cloud architecture for applications migrating to the cloud can find benefit from this category. It leverages the benefits of modernization such as auto scaling and high performant cloud environment while accelerating code deployment across environments. With minimal change, the application code can be reused but packaged & deployed in a managed infrastructure service such as a Container and DevOps. Applications that use technologies which are not natively supported by the cloud provider can be also be Containerized.
Rewrite – In scenarios where the application simply cannot meet the business requirements a complete rewrite of the application using native cloud infrastructure & application services may be warranted. GTM requirements may be negatively impacted if the developers are not able to deliver new features quick enough either due to the current architecture of the app or the lack of developers with specific technical skills required for the app. If an app has high maintenance cost rewriting the application can reduce the TCO. Applications can innovate by using services provided by the cloud such as AI and IoT thereby benefiting the business.
Two additional factors, Risk and Impact, can also drive the Rationalization process. Risk can be defined as the combination of factors such as the importance of the app to the business, whether the application is used by internal or external users and whether the app is running on aging technology greater than 7 years old. The answer to these questions will determine if an app is High, Med or Low Risk to the business.
An online ordering app used by external customers running on aging technology poses a High risk to the business if the app were to go down for any reason compared to an administration app used by internal users running on aging technology that poses a Low risk.
Impact on the other hand defines the value realized by the business after modernizing the app. Rewriting an internal administration app will not have the same impact as rewriting the Ordering app if it allows for innovation & agility driving additional revenue.
Putting all this together the matrix below summarizes the Rationalization process and the appropriate Action to be taken.
App migration & modernization is an organic process. After evaluating the applications and deciding the path for it you begin the migration process. To reduce risk and to learn as you mature you begin acting on the low risk low impact applications. As the enterprise gains maturity, defines process, support models and standardizes application architecture you begin to move Med risk and Med Impact applications followed by High Risk & High Impact applications. Of course, this is subjective to the overall primary objectives of the enterprise and can change accordingly.
For real life customer scenarios to which the application rationalization process has been applied please refer to this article.
Ravi Pulugura 
Program Manager, Motifworks
