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
執筆者紹介
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.
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する IT 自動化の最新情報
AI (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
オリジナル番組
エンタープライズ向けテクノロジーのメーカーやリーダーによるストーリー
製品
ツール
試用、購入、販売
コミュニケーション
Red Hat について
エンタープライズ・オープンソース・ソリューションのプロバイダーとして世界をリードする Red Hat は、Linux、クラウド、コンテナ、Kubernetes などのテクノロジーを提供しています。Red Hat は強化されたソリューションを提供し、コアデータセンターからネットワークエッジまで、企業が複数のプラットフォームおよび環境間で容易に運用できるようにしています。
言語を選択してください
Red Hat legal and privacy links
- Red Hat について
- 採用情報
- イベント
- 各国のオフィス
- Red Hat へのお問い合わせ
- Red Hat ブログ
- ダイバーシティ、エクイティ、およびインクルージョン
- Cool Stuff Store
- Red Hat Summit