Step 1: Assess Your Portfolio

First, you need to get a handle on what’s in front of you. Scour your landscape to get a sense of which .NET project types you have. Go back to Chapter 2 and list your software for each category.

Consider a few vectors when plotting your portfolio. For example, you might want to create a chart that grades technical debt on the y-axis, and business value on the x-axis (see Figure 10-1). The circles that you plot represent the .NET apps, and the circle size corresponds to how well that app represents what’s in your overall portfolio. That last factor matters because you want to tackle modernization of apps that generate patterns you can use elsewhere.

Figure 10-1. Plotting your application portfolio

In Figure 10-1, circle A is a poor candidate for modernization. It has low business value and a high degree of technical debt, and upgrading it doesn’t help us elsewhere in the portfolio. Contrast that with circle B, which still has some serious technical debt to overcome, but it has strong business value and would have modernization patterns you can apply elsewhere.

After creating your inventory of .NET apps and doing some light scoring, it’s time to choose a handful for initial modernization. You want to choose among the options that are useful to your business, and can generate repeatable modernization patterns.

Step 2: Decide on a Modernization Approach

There’s no one-size-fits-all approach to modernization. Some .NET software doesn’t need to be fully cloud native. Some light refactoring might be all you need. Other applications require a more comprehensive rewrite to introduce the necessary cloud-native attributes you crave. And some software will simply be retired because it’s no longer adding any value.

Figures 10-2 and 10-3 show some useful visual models for thinking about what to do with your existing .NET software. Figure 10-2 considers what to do based on application priority—that is, whether you plan to invest, maintain, or divest the .NET app.

Figure 10-2. A modernization model based on app priority (created by William Martin at Pivotal)

You can see there that for apps you’re investing in or maintaining, there are a handful of strategies and target runtimes. Figure 10-3 puts the focus on the type of .NET software and how that influences what you do with it. You can see that for web apps and .NET console apps, there’s a clear path. The only ones you’re currently “stuck” with are desktop apps.

As you plan your modernization, you have questions to ask yourself. Are you creating a microservices architecture? How exactly are you going to decompose existing applications? What new components are you going to introduce? What’s the ideal place for this modernized .NET software to run? Hopefully this book has helped you think through those answers!

Figure 10-3. A modernization model based on software type (created by Shawn Neal and Shanfan Huang at Pivotal)

Step 3: Modernize Your Initial Set of Apps

It’s critical that you start this process small. Don’t set up a plan to modernize 300 apps this year. There’s going to be a learning process.

Based on a value-stream assessment or some other technique, choose a mix of apps (see step 1) that add business value and offer the most learning opportunities. Don’t forget to mix in one or two apps that offer some “quick win” success to motivate your team!

Once you choose your initial set of target apps, assemble a team that will stick together to modernize them. First, try to collect some upfront metrics that measure your current state. Think of things like how long it takes to update the app today, its uptime numbers, and load limits. This will come in handy later. Next, focus on defining useful standards for developer tooling and project setup, and immediately get those applications into CI/CD pipelines. As each week goes by, do a retrospective on what you’ve learned and any surprises you’ve encountered.

Step 4: Record Your Patterns and Spread the News

If you’re part of this modernization effort, it’s critical to document your journey. Your goal is to make this a repeatable process, and one that many can perform. Write down the core patterns that you use, and stash them on a wiki or some other sharable place. At Pivotal, when we do application transformation projects with customers, we create and leave behind a “cookbook” of all the recipes we created together. This means that future teams can follow those recipes, and easily add new ones.

A Final Note

I hope you found this book helpful. Like a home improvement project, your .NET modernization is a journey. It requires upfront assessment of the task at hand and careful consideration for what work you want to take on. At the same time, both home improvement and .NET modernization projects offer unique opportunities to make meaningful changes. Don’t miss the chance to add new capabilities while making your software more sustainable and performant.

You have an important job to do, and I know that you’ll tackle it with gusto. Best of luck!