How to Build a Roadmap to App Modernization – InApps Technology 2022

The pathway to cloud migration started about 15 years ago. And yet, most organizations are still stumbling in their rush to get there.

“Modernization is not a buzzword. It’s happening. It’s here,” noted Karthik Krishnaswamy, F5 NGINX’s director of product marketing “But also there’s lots of dissatisfaction or failures.”

Many companies are now moving from on-premise, monolithic, centralized systems to distributed systems, at least in part in the cloud. According to the 2021 Mainframe Modernization Business Barometer Report, 78% of organizations have at least one cloud modernization process that kicked off due to the pandemic.

But progress is visibly stalled at most companies that have tried moving to the cloud. The June 2021 Enterprise Management Associates survey showed that a mere 28% of respondents categorized their cloud investments as “very successful.” And this is all coming at an immense cost.

Most so-called strategies are actually just an effort to follow and copy early cloud native adopters. Cross-organizational measures fail because there’s a top-down rush to get to an endpoint without a cohesive vision or pathway — not only for technology, but for people and processes, too.

It contributes to an already pervasive culture of burnout, and organizations struggle to recruit and retain across both technical and non-technical roles.

Before you start moving everything to the cloud, you need to consider who, when, what and, especially, why. You need to build a roadmap to app modernization. Here’s how to get started.

Adopt a DevOps Mindset

When moving applications to the cloud, Krishnaswamy said, “we definitely talk about technology but it encompasses the culture shift of adopting a DevOps mindset.”

Cross-functional teams are imbued with decentralized decision-making, he said: “You don’t just build code and throw it over the wall to the operations teams. They are part of the process.”

This extends to DevSecOps, which shifts security concerns left in the software lifecycle, to influence the design phase.

Only after you are ready to modernize your ways of working can you address technology — some mix of multicloud or hybrid cloud migration, microservices architecture, containers, and Kubernetes. Training becomes an essential enabler of modernization, even for developing that DevOps mindset.

For Erin Davies, Agile lead at the digital products company Wongdoody, when she consults with enterprise clients on their app modernization, the key to success is usually an Agile transformation alongside cloud migration.

When she works with a client, she focuses on culture while a colleague addresses the technology. They work in tandem to help the customer’s teams organize themselves around the technology.

This process includes a lot of upfront training — from how to use Amazon Web Services (AWS) and how to build the continuous development pipeline architecture, to how Agile, Kanban and Scrum methodologies work.

“If you’re modernizing your app I assume you’re going to be modernizing what’s built into it as well. It’s not just lift and shift, it’s an opportunity to modernize your ways of working,” Davies told InApps Technology.

Usually, she said, companies don’t re-architect their entire stack. But to make any cross-organizational change, they need to re-architect their culture — and make sure their technology supports it. If your architecture is siloed, your teams will be, too.

“The way your technology is built,” she said, “has an impact on the way your team works.”

Starting the Project: Get C Suite Buy-in

Any app modernization project needs to be presented as a top-down initiative. In fact, it’s important for the vice president of engineering, chief technology officer or chief information officer to introduce the change to the team, before considering bringing in a consultant from the outside.

Here are some other tips from Davies and Krishnaswamy.

Find Your Advocates

You can’t implement such a big project without a few change agents or champions within the engineering team, Davies said: “You need people who are actually in the company who understand what you are trying to do and are enthusiastic about it.”

In a tech department of about 100, she finds you need three or four big personalities to champion the project. “As they get more enthusiastic about things, it’ll start to snowball.”

Prepare for Dissenters

It’s also important to understand why people may be reluctant to change. Davies warned that any transformation will have a few vocal dissenters at the start, but don’t assume that’s the majority. Still, validate their concerns. Systems modernization may seem obvious to leadership, “but lots of time people don’t really understand the technology and they may have a fear they will lose their jobs.”

Just be ready for some people to leave. But, if it’s more than seven to 10% of your staff leaving, Davies warns, you’ve handled the change poorly.

Practice Transparency

By the time you’re kicking off your modernization project, you may already have a preliminary roadmap to share — just make sure that any time you announce big changes, you also announce an opportunity to learn new skills.

Communicate carefully. Davies suggested framing the conversation as, “We’re moving to this but we’re going to teach you how to do it,” or “We’re moving to this but it shouldn’t have a major impact on what you’re doing,” she said. Or, if an entire stack change is called for, be honest about what that could mean for your team members’ jobs.

If you don’t know the answer to your teams’ questions, tell them you don’t know yet, but should know in X amount of time. In order to avoid whispers, Davies said, explain as much as you can so the team members understand how and why decisions were made.

“Have a plan before you announce it, but also have a plan to get people involved,” she said. Then, work with different affected teams to perform a skills-gap analysis and create a training plan.

Leverage Your Existing Cloud Experts

If you already have a lot of cloud experts on your team, Davies says, it makes sense to disperse them across your product teams. If you only have a few, however, they’d be better placed on the platform team, whose expertise everyone has access to.

And it’s not just about leveraging the teammates that embrace the new tech. In more traditional industries, you may also be dealing with a few people who truly understand the older tech, who know why it’s been built the way it’s been built. These people are incredibly valuable to your transformation — but also they might become a bottleneck because you must check with them at each stage of your project.

If you want to build or modernize a customer-facing app, Krishnaswamy added, ask if you have enough developers to achieve that first win.

4 Pillars for Your Modernization Roadmap

Your roadmap to app modernization begins with consideration of the high-level business objectives for your app portfolio and your digital customer experience.

Then, examine whether your applications meet different requirements. NGINX, for example, has published a white paper that offers four lenses through which to view your transformation:

• Security
• Scale
• Governance
• Observability

These four pillars are to ensure any steps are highly scalable, resilient, and secure. Let’s take them one by one.

Security

Security is the top pillar because it’s often the most important and the most lacking in processes. It’s time for developers to own part of the security responsibility.

“CISOs and SecOps have a lot of budget for purchasing and deploying security solutions. But for developers, it’s still not on top of mind when you’re building the app,” Krishnaswamy said. “Are you designing the right security controls in place?”

In fact, organizations reported a staggering 681% increase in API attacks in 2021, according to a report by Salt Security. This is all while only 3% of developers think they should be responsible for security, according to the Linux Foundation’s annual FOSS Contributor Survey.

This includes strategically considering where data leakage could happen at all phases of the software development lifecycle. This starts, according to Krishnaswamy, with building authentication and authorization into your cloud migration — access planning should happen as part of the design phase.

The security lens means everyone is thinking about DOS and DDOS attacks, and how you’re going to not only prevent attacks but manage when they inevitably occur.

From the start, Krishnaswamy said, applying a security lens to your app modernization means thinking about malicious users getting access to your systems, and thinking about your system getting bombarded so that your resources — computers, networking — get stressed. Security isn’t just about saving face, it’s a crucial part of reliability.

Keeping your apps secure will likely mean deploying web application firewalls (WAFs). “To deploy an app, test, sandbox, production, the WAF needs to be there to protect your apps instead of only deployed in production,” Krishnaswamy said.

In a decentralized, cloud native system, SecOps teams should provide self-service to enable developers to provide security at scale.

Scale

Of course, the top reason most organizations go the modernization route is to scale faster, more reliably.

After all, “the ability to scale in seconds is a requirement for supporting superior digital experience, and essential for reliability and uptime,” Krishnaswamy said. “This translates to microservices that allow each service to scale separately.”

Governance

Next, any enterprise growth has to come with authority and accountability. Krishnaswamy recommends PlatformOps — teams that build, manage and optimize application infrastructure — for better governance during this time of transition and after.

This new portmanteau and philosophy sets guardrails and helps scale DevOps teams without scaling down release velocity and innovation. It’s a suite of tools for compute, storage, application load balancing and API management that have all been collectively approved — including, importantly, by your SecOps team.

“We do want to standardize a set of tools a whole organization can use. Guiding, nudging, and once deciding to provide some self-service options,” Krishnaswamy said. This includes setting scope and targets for where policy should be applied within a cloud provider or the application.

“I think the new world of governance is not ‘thou shall do what I say,’ but rather provide a collaborative environment, getting buy-in,” he said. “Governance for developers, by developers,”

Observability

And finally comes observability, the ability to detect known and unknown issues before they occur. This, Krishnaswamy said, is a mindset that needs cultivation, getting the developer to think about how easy it is to diagnose and debug problems.

Then, he said, provide that visibility to all the stakeholders, including to the site reliability engineering (SRE) and operations teams: “In a distributed environment, you need to be able to trace logs, metrics, from all these services, instances, applications you’re using to provide this high-quality experience — to prevent outages ideally, but, if it happens, to address it very quickly.”

Collaboration Drives Architectural Changes

As with Wardley Mapping, a roadmap to app modernization isn’t about creating a waterfall, 500-step plan toward a single destination, but rather aligning everyone in one direction.

You learn as you go. This means starting with building or converting one modern app. Check if it meets external digital experience objectives and internal business ones. Don’t just focus on external customers, but on the in-house experience, too. What has that single app transformation done to the team’s culture? Has it caused any burnout or retention problems?

Only when you answer those questions, can you then scale it to two to four more applications.

Business Model Canvas

Visualizing the application modernization strategy is essential to get everyone moving in the same direction. The Business Model Canvas is an open source management template usually applied to business strategy. Everything is added to a single page, creating a singular view across nine building blocks of equal weight:

• Key partners. Includes cloud vendors, integrations or strategic partners.
• Key activities. This is a good place to list overcomplicated systems or processes ripe for innovation.
• Key resources. People, processes, tools.
• Value propositions. What value does a transformation offer to your teams as well as to external customers?
• Customer relationships. What are your customers’ perspectives right now? How could they change due to this transformation?
• Channels. Includes current channels and the ones you hope to open up.
• Customer segments. Your ideal customer profile.
• Cost structure. Don’t focus on the giant budget that it may be, but what it’ll cost for this first stage.
• Revenue streams. Includes current and any new revenue sources you hope to open,  such as data and API monetization goals.

The purpose is to bring all the stakeholders together to talk about the current state of business and to identify new opportunities to drive value for customers, including your own internal teams. This exercise can easily be transferred to sticky notes on a wall for a more interactive Agile exercise.

Cloud Strategy Canvas

Once you’ve laid out the direction of your business and safely introduced the topic of the application modernization, only then can you progress to the technical discussion. AWS offers a spin on the Business Model Canvas with its Cloud Strategy Canvas, which can kick off this discussion, again by boiling down your project to a single-page summary.

AWS’s Global Head of Strategy Philip Potloff said the Cloud Strategy Canvas can help you reflect on your legacy applications to decide whether to:

• Rehost. Actual “lift and shift” of a full application to a virtual machine or the cloud.
• Repurchase. “Drop and shop” to move to another version or product.
• Re-platform. “Lift, shift and tinker” without major refactoring.
• Re-architect. “This approach is driven by a strong business need to add features, scale, or performance that would otherwise be difficult to achieve in the application’s existing environment,” Potloff wrote in the AWS blog about this option, which usually gets the most attention in any modernization strategy.
• Net new. New cloud native projects being planned or already developed.

Edward Hieatt, senior vice president of services and support for VMware’s Tanzu, would add to that two more buckets:

• Retain. What is not going to be moved for a while.
• Retire. What isn’t necessary at all.

Potloff recommends then continuing your modernization journey by applying Robert Martin’s Strategic Choices Framework, followed by Objectives and Key Results (OKRs) to align the organization through goal-setting. Davies also offered the Team Topologies at Scale approach to app modernization.

A Final Word: Take Your Time

Just remember, don’t do it all at once. Your monolithic architecture may not be working for you, but it’s still a beast to take on. Kick-off your app modernization with likely wins, not rushing and wasting money on something that should take time and strategy.

“It’s a journey,” Krishnaswamy said “You’re not going to modernize overnight or even within a set timeframe. It takes collaboration. Bring folks along that are very uncomfortable with the new, disruptive world.”

Featured image by Jaromír Kavan via Unsplash.