Key Roles to Hire for an App Modernization Dream Team

Bob Quillin

October 13, 2022

For many companies today, modernizing their legacy apps is a top priority. They recognize that although those apps are critical to their business operations, they’re also major hindrances to the organization’s ability to keep pace in its marketplace. 

That’s because legacy apps, which are typically structured as monolithic architectures, are very difficult to update to meet the rapidly changing market and technological demands that characterize today’s commercial landscape.

In response to that challenge, companies are mounting projects to modernize their legacy software. But modernizing a suite of legacy apps is not a quick and easy process, and finding workers with the requisite skills and expertise to staff such projects can be difficult. 

In fact, two recent surveys found that a shortfall of skills and expertise was one of the top reasons why application modernization had failed at their organization. What are the skills required for building an effective app modernization team? To answer that question, let’s start by looking at the application modernization process.

What Application Modernization is Really All About

The goal of application modernization is to restructure a monolithic legacy app from an isolated, stand-alone codebase that doesn’t interact easily, if at all, with the modern cloud-centric ecosystem, into a microservices architecture that is cloud-native in its capabilities. How is that restructuring accomplished? A report from Capgemini describes the process this way:

Modernizing means transforming existing software, taking an agile approach to development across people, processes, and technology, and embracing cloud-native development, including microservices and containerization, hybrid cloud- integration, and agile and DevOps methodologies.

The key phrase in this description is “taking an agile approach to development across people, processes, and technology.” A legacy app modernization team should be organized according to the Agile/DevOps methodology that characterizes the modern approach to software development.

Deciding Your App Modernization Objective

Application modernization involves refactoring or rearchitecting the monolith into a set of small, autonomous microservices.

Companies have sometimes attempted to gain the benefits of modernization by simply migrating their legacy apps, with minimal changes, to the cloud. That approach is simply migration not modernization and has proven to be ineffective: as a report from Google explains,

“Although CIOs have successfully migrated some applications to the cloud, according to a McKinsey study, around 80 percent of them report that they have not achieved the agility or business outcomes they sought from application modernization.”

Migrating an app to the cloud can, by itself, provide some benefits, such as DevOps improvements in deployability and security along with shutting down data center resources. The problem is that the migrated monolithic application remains monolithic and continues to suffer from all the deficiencies of that architecture. Migration alone achieves little in terms of achieving cloud benefits such as increased scalability, development velocity, and reduced technical debt.

That’s why full modernization is accomplished by refactoring the app into microservices. The app is thereby transformed into a cloud-native architecture that’s easy to update and that can integrate with and take full advantage of the technologically advanced resources available in the cloud.

Related: Cloud Modernization Approaches: Rehost, Replatform, or Refactor?

App Modernization Team Requirements

The fact that microservices are designed to operate independently of one another has a major impact on how application modernization teams are structured. That’s because of Conway’s Law, which was first articulated by software expert Melvin Conway in 1967:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

The implication of Conway’s Law for app modernization is that an organization that aims at producing small, autonomous, independent microservices ought to be structured as small, autonomous, independent teams. 

If the organization adopts a different structure (like, for example, the large integrated teams normally used with monolithic apps), the product they produce will reflect the way the team is organized, whatever the intent for that product may have been. As software engineer Alex Kondov emphatically warns,

“You can’t fight Conway’s Law… Time and time again, when a company decides that it doesn’t apply to them they learn a hard lesson… If the company’s structure doesn’t change the software will slowly evolve into something that mirrors it.”

Domain-Driven Design (DDD) in App Modernization

Application modernization teams formed in compliance with Conway’s Law will each take full ownership of one or more microservices. But what should be the scope of each of those microservices, and therefore of the team that supports it? Tomas Fernandez of Semaphore provides a useful answer to that question:

“Domain-Driven Development allows us to plan a microservice architecture by decomposing the larger system into self-contained units, understanding the responsibilities of each, and identifying their relationships.”

DDD helps you to identify the functional domains and subdomains in a monolithic codebase and draw boundaries around each function that will be implemented as a microservice. It also allows you to employ key modernization best practices such as the Strangler Fig Pattern to carefully shut off old functions and domains in the monolith as new microservices replace them.

Related: Organizing and Managing Remote Dev Teams for Application Modernization

Key Roles in Modernization

Jason Smith, Chief User Experience Officer at dotCMS observes that,

“Agile Development, which some refer to as ‘DevOps’, means having a number of small teams working on individual, smaller projects so that those projects are able to get a team’s undivided attention. This enables the individual projects to be completed quicker. Microservice architecture fits into this development model perfectly, as each small team can own and focus on one service.”

Because the process of restructuring a monolithic codebase into microservices fits “perfectly” into the Agile model, we’ll look to that model to identify the roles you’ll need to fill for your app modernization dream team.

  1. Corporate leadership – May include an Executive Sponsor who will provide both the budget and overall guidance for the project, as well as other leaders such as the CIO.
  2. Product Owner – Sets requirements for the project from the viewpoint of the customer. This role, which typically is filled in-house, assigns team roles and tasks and takes full responsibility for the success of the project.
  3. Project Manager – Responsible for the day-to-day operation of teams. Provides leadership for team members, defines goals, oversees progress, and ensures that budget and schedule milestones are met.
  4. Modernization Architect – Translates business requirements into technical deliverables. Responsible for defining the microservice architecture the team will implement and for ensuring effective integration of the modernized app into the cloud environment.
  5. Legacy App Expert – Has the skills needed to analyze the app to understand its functionality and the internal and external dependencies that must be accounted for when it is restructured into microservices.
  6. Senior Developers – Individuals who have the normal range of software development skills that allow them to function as, for example, front-end or back-end developers or UI/UX designers.
  7. QA Engineer – Responsible for defining comprehensive test coverage to ensure that each microservice and the restructured app as a whole function as intended.

Each microservice team won’t necessarily have all of these roles—some, such as corporate leaders or developers who analyze legacy apps, may work with several or all of the teams. Also, on small microservice teams, several roles may be filled by one person.

How Do You Find the Talent You Need?

The first question is, to what degree can you tap into your existing staff to fill the roles required for your modernization project? To answer that question, you’ll need to assess what skillsets are available in-house and whether any that are lacking can be supplied through training.

If you do have to go outside to find the skills or expertise you need, be prepared to face some challenges. The U.S. is currently experiencing a shortage of more than a million software developers, and even if you can find them, they’re hard to keep. One recruiter, DaedTech founder Erik Dietrich, declares that,

“The only way to find software developers is to go prying them loose from other firms.”

And there’s an additional challenge when you’re staffing an app modernization project: many developers just don’t want to work on legacy code. According to one survey, 78% of developers say that “Spending too much time on legacy systems” has a “negative impact” on their personal morale.

Automation Can Minimize Your Need to Hire

Legacy monoliths may contain tens of millions of lines of code and thousands of classes. Having developers manually conduct the comprehensive static and dynamic analyses necessary to uncover all of the app’s functions and dependencies can be extremely time-consuming, error-prone, costly, and from the developer’s point of view, boring. And the process of decomposing the codebase into services and reimplementing them as microservices is similarly fraught.

But an AI-enabled, automated modernization platform can perform those chores accurately and comprehensively in a fraction of the time a human would require. With that kind of assistance, not only will you need fewer new hires for your modernization efforts, but you’ll also boost the morale of your existing workers by releasing them to spend more of their time on exciting innovations rather than on decidedly unexciting legacy code.

The vFunction platform employs sophisticated AI capabilities to quickly and comprehensively analyze complex monolithic applications to uncover hidden functionalities and dependencies. Plus, it can automate about 90% of the process of restructuring a monolithic codebase into microservices.

To see first-hand how vFunction can help you build an effective modernization team while minimizing the need to hire new development talent, request a demo.

Bob Quillin

Bob Quillin is the Chief Ecosystem Officer for vFunction, responsible for developer advocacy, marketing, and cloud ecosystem engagement. Bob was previously Vice President of Developer Relations for Oracle Cloud Infrastructure (OCI). Bob joined Oracle as part of the StackEngine acquisition by Oracle in December 2015, where he was co-founder and CEO. StackEngine was an early cloud native pioneer with a platform for developers and devops teams to build, orchestrate, and scale enterprise-grade container apps. Bob is a serial entrepreneur and was previously CEO of Austin-based cloud monitoring SaaS startup CopperEgg (acquired by IDERA in 2013) and held executive and startup leadership roles at Hyper9, nLayers, EMC, and VMware.

Get started with vFunction

See how vFunction can accelerate engineering velocity and increase application resiliency and scalability at your organization.