This article was written with the help of Henri van den Bulk, Sina Sojoodi, Michael Coté, Steve White, and David Zendzian.
As companies recognize that software is a strategic corporate asset that is critical to their success, modernization—or as it’s sometimes called, digital transformation—is no longer solely the concern of app dev organizations. Modernization also spans multiple internal and external functions, including HR, sales, and core IT, to name just a few.
A benchmark of almost 300 organizations globally found that top-performing CIOs make legacy modernization a business, not just an IT initiative, and they apply continuous focus to it.
—“Leading CIOs Follow 4 Principles for Legacy Modernization,” Gartner, July 2020
Meanwhile, the demographics of both your customers and your employees are changing; they expect intuitive, and immediate, digital experiences. Indeed, organizations of all kinds—from governments to non-profits to commercial enterprises—are having to quickly build new kinds of apps while modernizing the back-end systems running at the heart of their operations.
In this post, we set out to dispel some of the more common misconceptions that are keeping organizations from modernizing their business. We’ve based these myths on countless conversations with customers and analysts, industry research, and the anecdotal experiences of ourselves and our colleagues. Our hope is that you walk away feeling a bit more confident as you embark on or continue your modernization efforts.
Myth: An application has to be cloud native to land on a PaaS
The 12-Factor App methodology, which is responsible for helping developers rethink their application architecture, continues to be a useful model, but it’s not the only way to realize value from your cloud native platforms. When we recognize that application modernization is a continuum, we realize that not all apps need to adhere to the 12-factor methodology. We can get existing apps running on cloud native platforms.
Many organizations may not be ready or willing to refactor all their existing applications—and frankly, most business applications are not ready for refactoring. But that doesn’t mean your organization can’t enjoy the advantages of running on a cloud native app platform.
When the appetite for change is zero, start by asking if your app can be predictably restarted. We call this being one-factor compliant. Derrick Harris and James Watters explain the concept nicely in this video. If you can get your one-factor app running on a Kubernetes-based platform, you can then move on to refactoring other aspects, because the value you get from your cloud native platforms is directly correlated to how many cloud native characteristics your applications embodies.
Myth: We can’t afford to modernize our operating model
Enterprise organizations have a large portfolio of applications that require a significant amount of capital to acquire or build. It’s very much like owning and remodeling a house.
As enterprises try to change their business models or align with customers' needs they realize they need to make changes to their application portfolio. This change requires them to modernize those applications to accommodate the ability to be more agile. However, due to a build-up of technical debt and operating expenses associated with maintaining them, organizations are struggling to finance that modernization.
By 2025, technical debt will continue to compound on top of existing technical debt consuming more than 40% of the current IT budget.
—“Application Modernization Should Be Business-Centric, Continuous and Multiplatform,” by Thomas Klinect and Stefan Van Der Zijden, Gartner, August 2019
In the same way you might upgrade or change your home to accommodate your evolving needs while still paying your mortgage, your app modernization efforts must be funded as part of the portfolio lifecycle. As Gartner says: “Budget and plan modernization work for the entire product life cycle and not as an occasional exception, by performing continuous modernization which will proactively reduce technical debt.”
From a financial perspective, increasing your financial debt to pay down your technical debt will eat into your future earnings. Instead, think about it from an operating expense perspective. You're already paying for expenses such as labor and licensing. What if you take the resources used for maintaining those applications and focus them on incrementally rehosting/migrating? Or replatform those applications using evolutionary modernization practices? By reallocating those resources, you are continuously driving efficiency. Put in home-owning terms, you are both incrementally improving your home while continuing to pay down the principal.
Myth: Modernization doesn’t help business continuity, so it’s not urgent
In the era of COVID-19, businesses are expected to not only become more resilient to unlikely catastrophic business challenges, but to complete existing digital initiatives on which technology leaders have been dragging their feet. In a May 2020 report titled "The Coronavirus Crisis Increases the Demands on Software and Developers," Forrester research puts it this way: “The coronavirus crisis has blown big holes in the software strategies of most enterprises. They suddenly and urgently need new applications to track people, tests, and assets; administer new programs; coordinate the work of employees stuck at home; and fix broken business processes. AD&D will never be the same.”
Continuing the status quo in 2020, in other words, is simply inexcusable.
Application modernization addresses both challenges. The pandemic has proven that modern infrastructure and application platforms are resilient to the challenges of uncertainty. There are tons of examples; supply chain management is perhaps the most vivid one here. At the same time, modernization efforts facilitate digital initiatives that seem trivial to consumers but are held back due to technical debt or legacy system rationalization. These digital initiatives are no longer simply another opportunity to differentiate, but rather a critical hinge on which the business's survival depends. Organizations that continue moving forward with their modernization efforts will stay ahead of their competition and recover more quickly from the pandemic-related financial downturn.
Myth: A modern app is a secure app
Microservices, containerization, and multi-cloud have become synonymous with modern applications. These design models can improve software quality and accelerate both app development and flexibility. Nonetheless, due to their distributed and decoupled nature, they create new security concerns. While a so-called “modern application” has the potential to be more secure, this will only be the case if you properly integrate the changes needed to mitigate the additional risks it introduces.
For example, microservices create the need for fine-grained identity and access controls across thousands of services. Putting in place such controls is a complex process and could introduce risks, such as not properly restricting access to application or customer data. This isn’t an issue with monolith applications, which inherit the user ID and access levels from the main program itself. One option to mitigate this risk is to use a service mesh—a network-centric approach to securing microservices that allows for mutually authenticated TLS (mTLS) and fine-grained access control between them. In addition to mitigating the access control risks, a service mesh can provide other security benefits for organizations, including setting the foundation for a zero-trust architecture and gaining greater visibility into “normal” and “abnormal” service-to-service traffic to identify malicious activity.
Traditional security tools such as vulnerability scanners, network forensics, host-based firewalls, EDR, and security analytics are too heavyweight for monitoring containers and container orchestration platforms like Kubernetes. Security, development, and infrastructure and operations (I&O) professionals told Forrester that to effectively scan, deploy, and monitor container images and instances they need dedicated, lightweight tools whose agents are built for container clusters and distributed, containerized apps. Reporting and dashboarding must be specific to containers, which are often widely distributed and transient.
—“Best Practices for Container Security,” Forrester, June 2020
Containerization is a great way to start application modernization initiatives. But it adds risks related to how the container images are constructed, what layers are included, and how those layers are configured and updated. To properly manage those risks, tooling and security processes need to be adjusted and enhanced, respectively. That can include introducing new tools like Tanzu Build Service for automating the construction of container images, or introducing additional testing for vulnerabilities in the container images or their dependencies. On the operational side, changes to incident response and forensics tools and processes are required due to the ephemeral and immutable nature of container runtimes.
Myth: Call it agile
When you’re looking to improve how you’re developing software, you’ll more than likely find yourself switching to agile development. You might also be thinking about DevOps or Site Reliability Engineering. However, while all of these are proven techniques, surveys show that not many organizations fully embrace these practices. But following the principles and practices of agile software development is worth it.
All of that being said, it’s good to be cautious when using the word “agile.” Sometimes labeling what’s being done as agile can cause more harm than good. I’ve noticed two problems:
- The new way justifies the old way – Middle management will be very enthusiastic about transforming to agile at first. But soon they’ll start saying they’ve always been doing agile. “We’ve just never called it that!” they’ll say. Managers will begin justifying the ways in which they currently operate by saying it’s already agile and will resist changing. This is a classic example of Larman’s Laws of Organization Behavior.
- One size is believed to fit all – Certain people will object that you’re not being agile enough, that how you’re doing agile doesn't match the full list of practices. In fact you’ll need to adapt your agile thinking and tools to what’s possible in your organization and what creates the best value for your business. Every agile school of thought emphasizes that you need to adapt the principles and practices to your organization, but people often forget that point.
To get around these problems, it can be helpful to avoid labeling the methodology you’re moving to as “agile.” Instead, what I’ve seen many organizations do is create their own name for it. Coming up with your own branding also allows you to raise internal awareness and better delineate the old way of developing software from the new way.
Obviously, you can’t avoid using the word agile entirely, but try not to use it as a key part of your program’s name.
Myth: We cannot modernize and meet compliance criteria
When it comes to getting software out the door, one of the most common bottlenecks is compliance. Having auditors look through and approve your code and new business processes can take weeks—even months! Moreover, making sure you’re following regulations from trade groups or governments can feel like a waste of time. It could be because your organization’s understanding of how to comply with those regulations is out of date.
To that end, it’s worth spending the time to sit down with auditors and review your compliance process. After all, each year new technologies and practices emerge that directly address organizations’ regulatory needs in a more efficient and automated way. For example, once the U.S. Air Force started using Tanzu Application Service to host and run its applications, its auditors no longer needed to verify every bit of code all the way down to the operating systems because those bits no longer changed with each release. This cut the compliance time from 18 months to as little as 10 days.
That said, compliance is not always bad. As individuals, we want and benefit from privacy compliance when it comes to our health information or age restrictions around content. We like it when our banks follow governance that ensures we don’t lose our money. We also like it when our taxes are spent responsibly instead of being wasted on projects that go nowhere or are pure graft. It’s the same with software development: By incorporating compliance into the development cycle through automation, we can adhere to regulatory policies while maintaining the speed and continuity necessary to bring software to market.
Busting the myths
Organizations may be holding back their modernization efforts for valid reasons, from the ever-present fear of the unknown to specific challenges like funding, culture, technical debt, or a shortage of skills. And all the “best practices” articles and consulting sessions in the world can’t help when leaders and practitioners are trying to make decisions against a backdrop of fear, misinformation, and uncertainty.
Leaders who remain positive and continue moving forward with new technologies and processes will learn from this crisis and allow their companies to stay ahead of the curve. While leaders who hunker down to avoid risk by sticking with older tools, technologies, and processes will find their businesses further behind than when the crisis started.
—“The Coronavirus Crisis Increases the Demands on Software and Developers,” Forrester, May 2020
We don’t want to minimize organizations' concerns about starting new initiatives that are not focused on maintenance, especially those related to cost-cutting. It’s also perfectly understandable that they don’t want to double down on immature modernization initiatives that have yet to prove their value. However, forward-thinking organizations know that when it comes to making changes that will have a positive impact over the long term, there’s no better time than the present.
