If you have been following the series, we have covered a fair amount up till now. From determining the desired future state of the application(s) and reviewing challenges surrounding legacy code to making a case for funding the future state and creating an effective team to work on a modernization project in an enterprise environment.
The next logical question would be: “When will the project start, and how soon will it get done?”
Before we can proceed, we need to map out the full scope of the modernization project.
Mapping out the current state
As we established previously, the current state is where the applications are presently at in terms of code, configuration and runtime. The goal is to move this state into a new one that, hopefully, provides the value you are trying to achieve.
You are most likely dealing with a portfolio, so there will most likely be multiple characteristics in the current state that you’ll need to understand.
Current state knowledge includes:
-
the functionality provided by the application
-
the level of test coverage
-
general quality of the code
-
service level agreements for production
-
how it’s deployed and configured
-
audit, compliance, and security standards it must adhere to
-
how it is currently supported and monitored
Subject matter experts for these aspects of the existing state need to be identified. This might also include individuals familiar with the third-party systems the application integrates with.
Plotting a course to the future state
Plotting a course refers to the changes that you believe should be made to obtain the desired outcome. These might be changes to the code, a total rewrite of the application, or updates to the build/deploy process or runtime.
The details around this future state might be very new to the enterprise in general. As a result, some external resources might be required. This option will heavily depend on the budget of the project. However, it's best to get organized before bringing in extensive external resources. Let’s discuss some strategies for getting an idea about how this work should be addressed.
Reviewing the landscape
A good place to start is to review the portfolio of applications targeted for modernization to start figuring out how to best tackle the work.
Focus on patterns over applications
Silos form in enterprises around technology. These silos can often greatly affect how technology is adopted. There is a concept called Conway’s Law which states that “organizations design systems that mirror their own communication structure.”
For example, when dealing with a difficult or slow silo that owns a required technology, teams might implement a less-than-ideal solution out of desperation when they are unable to get what they need (e.g., teams are unable to get databases without excessive time and frustration, so in-memory caches are used for data persistence instead).
Based on this understanding, there will be some patterns found in applications across the enterprise that are unique to that enterprise as they were potentially created to deal with challenging teams or processes unique to the culture. These patterns might be driving a modernization effort, but teams must be careful to understand how these patterns came to be or risk repeating them.
Building on the previous example, a modernization effort might be to stop using in-memory caches for data persistence across a portfolio of applications. However, after spending time and resources, a team might miss the goal due to the limitations or process the enterprise has put on database usage resulting in the modernization team leaving the in-memory caches in place.
The goal is to pick patterns that can be modernized and that are shared across the portfolio in order to realize more value for your effort.
Getting a lay of the land: Determining priorities
The Wise Sage and Project Lead need to get together and assess the applications that might be candidates for modernization. If they have issues getting access to what they need, The Sponsor can be called on for help.
You will want to look for patterns and what types of applications they occur in to determine where the best bang for your buck will be.
For example, consider a custom security library made by teams within the enterprise that requires a heavyweight application server to perform its logic. In this situation, the modernization value could be to move away from this application server to save on licensing costs. Focusing on lower priority applications that contain this custom library (e.g., applications that can sustain downtime or disruption), to build out the future state solution might be a better place to start than a higher profile application which could result in the team running into escalations when something breaks.
Here is a sample data collection form with some data points that can be obtained for each application in the portfolio. The goal is to obtain a matrix of data to help the team to determine what/where to start the modernization work. Given the Wise Sage and Project Lead might not know everything about these applications, they might need to interview team members involved in the application portfolio. These could be some useful data points to collect.
Category |
Description |
Sample data points (answers a team might give) |
Type of application |
What type of application is it? Define some tags to be associated with the application type. |
|
Presence of enterprise-specific libraries |
Custom authentication libraries, transaction logic, authorization libraries. Define some tags to be associated with the application. These will be very enterprise specific (e.g., transaction logic, authentication library) |
|
Services |
What services (names of products) does the application integrate with? |
|
Internal or external facing |
Is the application used inside or outside of the enterprise? |
|
Touches PI data |
Does this application use personal data (PI)? |
|
Business criticality |
How important is this application to the enterprise in terms of revenue, or alignment to corporate goals? |
|
Published SLA |
How much downtime is the application allowed to have per month? Usually measured in 9(s). |
|
Technology stack |
What languages make up the code base of the application? |
|
Source Code Access |
Does the team have access to the code? |
|
Pipelines for deployment |
Are there pipelines for deployment? Is the code base setup for CI/CD? Please provide the tools. |
|
Application Monitoring |
Is there monitoring available for the application? Please provide the tool. |
|
Infrastructure Monitoring |
Is there monitoring available for the infrastructure the application will be running on? Please name all tools. |
|
Lower Level Environments |
Are there lower-level environments that mimic production? List all lower-level (non-prod) environments the application can run in. |
|
This list isn’t exhaustive, but it is a good starting point. This data can be obtained by talking to teams and using various code scanning tools. Red Hat provides some open source tools (such as Tackle) that can help with this type of data collection effort.
Analyzing the data to come up with a plan
The next stage is to review all of this data. This review should be driven by the Project Lead with help from the Wise Sage. These two members need to come up with a plan of attack that provides optimum value, including determining:
-
The patterns applicable to the most high-value applications that should be migrated
-
The applications with these target patterns are safest to start with because they:
-
are not business critical.
-
have access to the code.
-
have the best observability.
-
-
A learning curve associated with this target platform (e.g., starting to put together training related to all the labels associated with the applications)
-
Any external assistance that might be required (e.g., potential knowledge gaps across the enterprise on an application stack or runtime platform associated with the future state)
All of this combined should help get that sign-off for funding the project. In a future post, we will share some technical strategies that might be helpful.
Modernization series
À propos de l'auteur
Luke Shannon has 20+ years of experience of getting software running in enterprise environments. He started his IT career creating virtual agents for companies such as Ford Motor Company and Coca-Cola. He has also worked in a variety of software environments - particularly financial enterprises - and has experience that ranges from creating ETL jobs for custom reports with Jaspersoft to advancing PCF and Spring Framework adoption in Pivotal. In 2018, Shannon co-founded Phlyt, a cloud-native software consulting company with the goal of helping enterprises better use cloud platforms. In 2021, Shannon and team Phlyt joined Red Hat.
Parcourir par canal
Automatisation
Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements
Intelligence artificielle
Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement
Cloud hybride ouvert
Découvrez comment créer un avenir flexible grâce au cloud hybride
Sécurité
Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies
Edge computing
Actualité sur les plateformes qui simplifient les opérations en périphérie
Infrastructure
Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde
Applications
À l’intérieur de nos solutions aux défis d’application les plus difficiles
Programmes originaux
Histoires passionnantes de créateurs et de leaders de technologies d'entreprise
Produits
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Services cloud
- Voir tous les produits
Outils
- Formation et certification
- Mon compte
- Assistance client
- Ressources développeurs
- Rechercher un partenaire
- Red Hat Ecosystem Catalog
- Calculateur de valeur Red Hat
- Documentation
Essayer, acheter et vendre
Communication
- Contacter le service commercial
- Contactez notre service clientèle
- Contacter le service de formation
- Réseaux sociaux
À propos de Red Hat
Premier éditeur mondial de solutions Open Source pour les entreprises, nous fournissons des technologies Linux, cloud, de conteneurs et Kubernetes. Nous proposons des solutions stables qui aident les entreprises à jongler avec les divers environnements et plateformes, du cœur du datacenter à la périphérie du réseau.
Sélectionner une langue
Red Hat legal and privacy links
- À propos de Red Hat
- Carrières
- Événements
- Bureaux
- Contacter Red Hat
- Lire le blog Red Hat
- Diversité, équité et inclusion
- Cool Stuff Store
- Red Hat Summit