Modernization: Why is it hard?

Modernizing a portfolio of legacy applications presents some unique challenges in enterprise environments. In my first blog in this series, Modernization: Why is it important?, I recommended considering these two points when deciding whether to embark on a modernization project:

• What are the benefits of moving the application to a future state versus the effort it takes to modernize it?

• Can the enterprise operate this future state over time?

These are not the only things to consider before undertaking a modernization project. An enterprise is more than a sum of its processes and systems. It’s a large social assembly with human structures and operations. It has complex rules and politics shaped by decades-long service in enormous markets with multiple products, especially in regulated industries.

Alignment is necessary but hard

To successfully modernize software, the team must align around enterprise goals, compliance, and policies. It must also agree to balance innovation with the limitations of the current environment. 

However, it can be difficult and time-consuming.for large enterprises to achieve the alignment necessary for a successful outcome. The main issue is that the software's development history and the details around running it in production might be spread across the enterprise. The challenge is that sometimes teams are less open to sharing information. Individual team members, especially those new to an organization, may struggle to obtain the necessary context to be successful with their modernization project.

If your team looks like the following, your odds of successfully modernizing an existing application are greater.

The alignment between enterprise knowledge and innovation is critical.

Following are some of the reasons for misalignment that result in slow progress or poor outcomes that don't produce the intended benefits.

Gatekeeping silos

Before the internet, large enterprises were the original IT innovators. These companies were first to get on mainframe (“big iron”) in the 1960s. Many critical processes were moved onto mainframe computing. This tech was expensive and required specialized people on revered enterprise teams. These teams and the products they stood up still have a large influence on today's enterprise culture.

When many humans come together around something they value (such as a datacenter), exclusive groups can form. These groups may take it upon themselves to define the rules and practices of how others can utilize the resource. The combination of these exclusive groups, and the rules and practices they create is commonly referred to as a silo.

These silos tend to form around tools or platforms and might alienate the intended consumers of the technology.

Examples include:

• Allowing only certain people onto the silo’s platform and being hostile to everyone else

• Using chargeback models that don’t make sense to those who want to use the technology

• Maintaining closely guarded steps to successfully using a tool or technology

An enterprise might bring in a new technology to improve existing applications (for example, a new application performance monitoring tool or a container runtime). However, having a silo around this technology could leave teams spending a long time waiting for access to the technology to complete a project. The result is it takes longer and is more frustrating for the team to get the outcomes they need to deliver on the project.

Busywork and excess middle management

When enterprises have many layers of middle management, identifying the person responsible for an outcome can get confusing. Alignment becomes difficult when it's not clear who is making decisions or that people at the table are vested in finding the right outcome.

Heavy layers of middle managers—some of whom have never worked on a software project in a meaningful way—may derail critical technical decisions when there are endless checkpoints, too many stand-ups, and excessive reports and presentations. This culture of “busywork” can constrain employees who could be spending their time doing more impactful work.

“Rockstars" don’t always save the day

A typical solution to unsatisfactory outcomes is to bring in a “rockstar” to save the day. A rockstar is someone who management believes is super smart and will just “fix things.” 

But rockstars may have rockstar egos that can affect their willingness to compromise. Sometimes they will ignore enterprise context or balk at existing policies and security standards. The result is that the person you brought in to “fix everything” ends up entangled in conflict, and everyone is unhappy. 

To be clear, I’m not saying to avoid engaging smart people. Instead, be discerning about who you bring in and the work you assign them to do. I will discuss how to create better product teams in a future blog.

Attrition leading to lost knowledge

If too many technical resources leave the organization, you'll lose valuable enterprise-specific knowledge necessary to obtain alignment and achieve quality outcomes. 

For example, when a large consulting firm and an enterprise terminate their relationship, people will be removed from projects. While this might make sense from a cost-efficiency perspective, people with valuable knowledge about the technology have just walked out the door.

Also, when a good technical expert leaves, it can be a blow to team morale because it seems like the best and brightest are jumping ship.

If there isn’t adequate onboarding training specific to how to work in your enterprise environment, a newly patched-together team might not have sufficient insight into how the enterprise works. It may struggle to reach the necessary alignment to make good decisions. This can result in delays on the team getting started or missing a critical aspect required to get the application into production. I will discuss what this training should entail in a future blog about preparing the team for a modernization project. This training can also be valuable when dealing with attrition or replacing a consulting firm on the project.

Cost-cutting culture

Good people can be hard to find, but a culture of cutting costs can make this even harder. This policy is usually driven by procurement departments that don't understand the specialized knowledge needed for people to be truly effective in software development and operations in their enterprise.

When choosing between lots of inexpensive, underskilled people versus a smaller number of more expensive, better-skilled people, many enterprises often lean toward more for less.

Often, procurement or finance teams are incentivized to beat up vendors, solution providers, and tech talent agencies for discounts. Once procured, they might provide or receive feedback about how those resources perform after they are engaged.

Having people who can’t do the job is a big challenge. But, having too many people can be an even bigger problem. Cost-saving decisions around resources can result in both problems occurring simultaneously.

The more people on a team, the less likely quality outcomes can be achieved, regardless of innovation knowledge or enterprise knowledge.

Unclear standards and policies

It’s critical that people brought into the team with “enterprise knowledge” know the specific policies and procedures that govern production workloads in that particular enterprise. Knowledge of how it’s done elsewhere will not suffice. 

This is because whenever there is a major issue that causes a problem (such as a public security event or loss of funds), after the damage is minimized or repaired, someone is tasked with preventing it from happening again. This work becomes solidified in the organization as unique institutional security standards and operational policies. These unique standards are often more applicable when changing an existing application than when building something new from scratch.

I will discuss standards and policies more later in this blog series.

Crowded marketplace

In today's enterprise environment, cloud providers, cloud consultancies, and tool providers flood every crack, trying to convince enterprise management they can fix the enterprise's software development and operations practices.

On the surface, buying into the hottest new tech from a provider makes strategic sense. After all, if your enterprise’s goal is to be the next Google in your industry, who better to help you then Google, right? But adding something new (like a public cloud) into the existing processes and culture of a legacy enterprise is far from simple.

When a vendor or product fails, that failure leaves a door open for another vendor to come in and “fix everything.” This can feed into a systemic enterprise fix-and-fail cycle of people who understand nothing about the environment coming and going from the alignment process. The resulting confusion can lead to costlier implementations or potentially a failure to achieve the future state due to teams not taking the environment's constraints into account when engineering.

We will come back to the discussion around building the ideal team to do modernization work while taking all the challenges discussed into account. 

The topic we need to shift to now is funding. Without this, there can be no team. Our next topic will be convincing senior management the modernization project is worth the money.