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
Sull'autore
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.
Ricerca per canale
Automazione
Novità sull'automazione IT di tecnologie, team e ambienti
Intelligenza artificiale
Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque
Hybrid cloud open source
Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido
Sicurezza
Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti
Edge computing
Aggiornamenti sulle piattaforme che semplificano l'operatività edge
Infrastruttura
Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale
Applicazioni
Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili
Serie originali
Raccontiamo le interessanti storie di leader e creatori di tecnologie pensate per le aziende
Prodotti
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Servizi cloud
- Scopri tutti i prodotti
Strumenti
- Formazione e certificazioni
- Il mio account
- Supporto clienti
- Risorse per sviluppatori
- Trova un partner
- Red Hat Ecosystem Catalog
- Calcola il valore delle soluzioni Red Hat
- Documentazione
Prova, acquista, vendi
Comunica
- Contatta l'ufficio vendite
- Contatta l'assistenza clienti
- Contatta un esperto della formazione
- Social media
Informazioni su Red Hat
Red Hat è leader mondiale nella fornitura di soluzioni open source per le aziende, tra cui Linux, Kubernetes, container e soluzioni cloud. Le nostre soluzioni open source, rese sicure per un uso aziendale, consentono di operare su più piattaforme e ambienti, dal datacenter centrale all'edge della rete.
Seleziona la tua lingua
Red Hat legal and privacy links
- Informazioni su Red Hat
- Opportunità di lavoro
- Eventi
- Sedi
- Contattaci
- Blog di Red Hat
- Diversità, equità e inclusione
- Cool Stuff Store
- Red Hat Summit