Application Modernization Point of View

Modernize, modernize, modernize. This is the watchword of those seeking to improve development velocity and to allow delivery of more business value faster.

IBM’s point of view on application modernization provides broad guidance for clients to consume and leverage. Modernization regularly becomes the key element of a cloud journey. This short paper will define application modernization and the supporting use cases which motivate a modernization effort. Then our approach for creating a modernization journey is outlined. Finally, because application modernization does not occur in isolation, linkages to other overlapping and relevant topics are spelled out.

Our evolved point of view sets a broader scope for application modernization than some of our prior definitions. In fact, we are including what many might consider to be application migration or even infrastructure migration. While it was useful to create this separation for the purposes of refining the story and getting to a more detailed view, it is now time to merge the vision back into a single holistic story.

At the simplest level, look at it this way:

Why do we include all of this in a single conversation? This is because the best application modernization decisions are going to occur in the presence of the most information possible. It is further a good approach because there are actually elements of a given application that might be appropriate for aggressive modernization techniques such as containerizing or refactoring while there are other elements of a solution which might most appropriately be landed on the target environment as a virtual machine or something that looks a lot more like migrate than actually modernize. Note that in addition to the fact that the application modernization journey includes the migration discussion, we have also placed mainframe modernization under the umbrella also. This is increasingly more important as the applications being evaluated for migration are more frequently covering mission critical systems of record. A lot of those are living on IBM mainframe environments.

With this umbrella view in place, the next topic is how to decide the approach or approaches that should be applied for a given application. We recommend that there are two sets of inputs that go into the decision-making process.

1. Leverage our rich inventory of tools — These tools gather concrete information about the make-up of the application under consideration. This inventory includes methods and tools like IBM Garage Method for Cloud and IBM Transformation Advisor. Methods and tools are a much more effective approach than just talking about applications and inventorying them through conversation.
2. Consider business requirements and current application fragility — Application owners should speak to an application’s current development velocity and the perceived pain points involved in adding new features and servicing the current application. Business stakeholders should provide a view on the application’s strategic relevance and expected role in the business. This includes future insights as to new features that might be required and any other changes to this part of the business that would influence the overall modernization approach.

The final elements of our point of view deal with creating a specific journey for an application. This can leverage a number of techniques, some of which might be classically considered migration and others might be those classified under modernization. An evolved version of the previously diagram fills in blanks with information about paths that might make up a journey:

Here there are migrate paths and modernize paths. The migrate paths do not change business logic and are more aligned with history lift and shift approaches. The modernize paths are strongly targeting containers. Our view is that modernize paths that involve containerizing, which includes containerize, repackage and refactor are very compelling and probably should precede externalize and enrich, which are more focused on exposing function and adding function than they are about the application packaging and runtime configuration.

Our point of view and experiences suggest that a given application might leverage paths from both migrate and modernize for individual components. For example, you might do a “virtual to virtual” journey for the database and a “containerize” journey for the web application. You might also leverage multiple paths for a single element of an application. Containerize followed by repackaging, followed by enrich might be the best path for an existing JEE web application looking to add some function to a specific part of an existing monolithic application. Containerize creates developer provisioning speed and a self-service model. Repackaging isolates specific parts of the application from others and enrich allows adding new value to this new isolated component.

Our point of view then is summarized into the following:

1. Consider the broader set of techniques which might traditionally be called migration and mode
2. Leverage tools to be informed about the current application elements
3. Most significant modernization starts with cont
4. Create a specific journey for each application

Finally, all of this talk of migration, containerizing and repackaging is a for purpose. The purpose is to enrich the application and be able to deliver new capabilities with more velocity. Don’t get caught up in the first part of the journey without clearly remembering the payoff.