フィードを購読する

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. 

  • API

  • Stateless

  • User Interface

  • Event-driven

  • Batch

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)

  • Custom cache expiration logic

Services

What services (names of products) does the application integrate with? 

  • Oracle DB

  • Coherence Cache

  • RabbitMQ

  • Kafka

Internal or external facing

Is the application used inside or outside of the enterprise?

  • Internal use (VPN)

  • External (client facing)

Touches PI data

Does this application use personal data (PI)?

  • No

Business criticality

How important is this application to the enterprise in terms of revenue, or alignment to corporate goals?

  • Critical

  • Supporting critical

  • Low priority

  • Nice to have

Published SLA

How much downtime is the application allowed to have per month? Usually measured in 9(s).

  • Not applicable (can be down for 2 hr blocks if notification given to teams)

Technology stack

What languages make up the code base of the application? 

  • Java

  • React

  • .NET

  • Python

  • Node.js

Source Code Access

Does the team have access to the code? 

  • Yes

Pipelines for deployment

Are there pipelines for deployment? Is the code base setup for CI/CD? Please provide the tools.

  • CI (Jenkins)

  • CD (Spinnaker)

Application Monitoring

Is there monitoring available for the application? Please provide the tool.

  • True (App Dynamic)

Infrastructure Monitoring 

Is there monitoring available for the infrastructure the application will be running on? Please name all tools.

  • True (Grafana)

Lower Level Environments

Are there lower-level environments that mimic production? List all lower-level (non-prod) environments the application can run in.

  • Dev

 

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:

  1. The patterns applicable to the most high-value applications that should be migrated

  2. The applications with these target patterns are safest to start with because they:

    1. are not business critical.

    2. have access to the code.

    3. have the best observability.

  3. A learning curve associated with this target platform (e.g., starting to put together training related to all the labels associated with the applications)

  4. 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. 

 


執筆者紹介

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.

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

チャンネル別に見る

automation icon

自動化

テクノロジー、チームおよび環境に関する IT 自動化の最新情報

AI icon

AI (人工知能)

お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート

open hybrid cloud icon

オープン・ハイブリッドクラウド

ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。

security icon

セキュリティ

環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報

edge icon

エッジコンピューティング

エッジでの運用を単純化するプラットフォームのアップデート

Infrastructure icon

インフラストラクチャ

世界有数のエンタープライズ向け Linux プラットフォームの最新情報

application development icon

アプリケーション

アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細

Original series icon

オリジナル番組

エンタープライズ向けテクノロジーのメーカーやリーダーによるストーリー