Lately, I've been running into the phrase "App Modernization" a lot. At first glance, it just seemed to me like a new twist on an old concept. I mean, who doesn't want their applications modernized? The future is bright after all, and who wants a bunch of geriatric applications wandering around looking for reruns of Gilligan's Island on the community television? Isn't app modernization really just an ongoing improvement project we've been doing since the mouse became a thing?
Maybe not.
The more I think about it, the more I'm convinced that we have reached a critical inflection point in the way we interact with the machines that keep our bits and bytes sorted and accounted for. With the advent of the cloud, the explosion in platform as a service offerings (PAAS), and the functional decomposition of applications brought on by the advent of the smart phone, it's not a leap to think that we may have reached a pivotal milestone in the evolution of software.
So, what is "modernization" then? If it's not just keeping your stuff looking cool, then what does the term really mean in the context of this sea change in how applications are designed, hosted, and delivered? What is a "modern" application? As an organization, what is the roadmap to being "modern" in regard to software ecosystems and application offerings?
Working with companies at varying degrees of "modernization," I see four clear distinctions / behaviors / concepts - let's call them pillars - that set apart those who are sprinting into the future and those that are trapped in the past; an organizational awareness on where to spend based on ROI and strategy, an aggressive move to distributed architectures, an emphasis on DevOps, and a commitment to user-centric application design.
Pillar 1: Organizational Awareness
The concept of "App Modernization" is actually a bit of a misnomer. For most organizations, the concept of modernization of software assets is an organizational endeavor. It would be more apt to use the phrase "Organizational Modernization," as investments in overhauling software are now, more than ever, based on business ROI. In recent years, many organizations have become much better at quantifying the triggers and decision points that lead to an eventual investment in a particular piece of software, but those decisions are typically made within the umbrella context of organizational need.
With that said, the core concepts of modernization can be applied at both the application and organizational levels without much lost in translation. The same principles typically apply.
As you look to modernize, the first order of business should be an organizational assessment to determine not HOW to modernize, but WHAT to modernize. Determining where to sink the investments necessary to bring your organization into the 21st century can be a difficult task, and development teams are often faced with impossible roadmaps with unrealistic expectations evolving from broad-sweeping organizational mandates that usually end with large investments in minimal and ineffective changes.
There is a better way.
By having a better understanding of the principles of app modernization, organizations can begin to unravel the complex puzzle of paying back technical debt by starting with the "who" and not the "what." Focus on the "why" and not the "how." For instance, is it really important that we move "Ye Olde Ticket Logger" to the cloud? Can't we just declare technical debt bankruptcy and move on? Questions like these are the fundamental principle of pillar 1, organizational awareness.
Using approaches like Gartner's Pace-Layered Application Strategy are an absolute must for any organization who is facing a long-term systems and software overhaul. In the Pace-Layered approach, an application inventory and classification system is combined with organizational ROI metrics to determine which systems warrant investment, which systems should be simply maintained, and which systems should be retired.
Garner defines the approach as "… a methodology for categorizing, selecting, managing and governing applications to support business change, differentiation and innovation." But it is much more than that. It can be a foundational system of determining where to allocate the often-scarce resources available to IT organizations for eliminating technical debt through application modernization. More importantly, evaluation frameworks like Pace provide organizational clarity on what is important and what is not, using a subjective litmus test based upon your own ideas of what provides the best return on investment. In other words, as the immortal Stephen Covey says, you can "begin with the end in mind."
Pillar 2: Distributed, Cloud-Native Architecture
There was a time, when stuffing as many things as possible into a single system, was considered the state of the art in innovative software design. As it turns out, the bloated, monolithic applications which resulted are not the panacea that we imagined.
Huh, weird.
Seems that trying to cram everything but the kitchen sink into a single, giant database or functional application framework only made for ineffective and bloated application platforms that were difficult to change and a nightmare to support. IT organizations were left holding the bag and budgets were quickly consumed with care and feeding obligations instead of innovation and ROI.
To make matters worse, when the concept of open APIs became the rage, we compounded our mistake, by collectively deciding that slapping a huge and complex services framework (complete with a canonical schema!) onto the front of our big fat platforms was just the thing we needed to move the organization into the 21st century and beyond!
Not so much.
(And believe me, I was right there thumping my freshly printed copy of the WS* specifications manual.)
Nowadays, everything is about being lean. From an architecture perspective, modernizing applications is more about decomposition than composition. More about defining functional boundaries than functional requirements. Building ecosystems, not applications.
Making modern application ecosystems that are "cloud native" requires organizations to rethink how they distribute work. Building smaller, more functionally focused components allows a much more efficient use of cloud resources which helps maximize hosting spend and minimizing money leakage. Being able to surgically scale where necessary, without having to pay for unnecessary compute or storage, is critical for organizations who want to spend as much of their budget as possible on ROI and innovation rather than infrastructure cost and maintenance fees. Of course, decomposing applications into functional platforms also comes with a host of additional benefits such as native decoupling, software re-use, built-in fault tolerance, delivery efficiency, organization flexibility, and so on. The micro services revolution is exactly the result of an organizational shift in philosophy to a more distributed approach to building the critical and complex application platforms that are the lifeblood of their existence.
But as many have discovered, the path to nirvana is littered with casualties.
Decomposing organizational software assets into distributed systems that employ complex choreographies and distributed data is difficult. It is complicated and expensive and often done poorly with the best of intentions. The transition to a modern, cloud-native, distributed software platform can be an extremely painful and disruptive endeavor and must be approached pragmatically. Knowing which rules can be broken and which cannot is something only learned by experience.
Spending piles of money on awesome micro services wizardry just to find out you basically rebuilt the very thing you were trying to replace is less than ideal.
Pillar 3: DevOps
Knowing how to build stuff is great but knowing how to build it AND deploy it consistently, securely, and efficiently is even better.
As the cloud has gained momentum, and organizations have shifted assets to cloud-based infrastructure (including PAAS), the role that DevOps plays in IT strategy has become critical. In fact, DevOps has become such an intrinsic part of the modern organizational IT landscape that it is now an indispensable part of the design and engineering process, as opposed to the mundane bit juggling that it used to be. Understanding how to accelerate software release cycles through pipeline automation, secure cloud-native application endpoints, safely scale resources while all the while maintaining ecosystem integrity are just a few examples of the complex responsibilities that can make or break the relationship you have with your customers, whether commercial or captive. When you combine that with managing code repositories, setting up redundant assets for fault tolerance, monitoring system health, containerization orchestration, and a ton of other key functions, its no wonder that DevOps is one of the fastest growing areas in modern computer science.
If your competitor is pumping out new releases every two weeks while you're lucky to get something to your customers (both internal and external) twice a year, you're going to be in trouble in a hurry. All of your new shiny micro services and super user experience magic does no one any good if it's sitting in QA for 6 months. Having a strong DevOps strategy, and executing it consistently is crucial to a modern IT shop.
Pillar 4: Human-Centric Design
Once upon a time, we used to design applications based on what machines wanted to do with our data. Software design often began with discussions about tables and class diagrams. At some point, when we felt we had enough detail around how we would store and organize the data, we'd slap a user interface on top of everything and invest heavily in "training" and "user adoption."
If that sounds like how things work in your organization today, then you are already behind.
The expectations of software users today are ridiculously high. Even internal-only, purely functional applications are being held to the standards imposed by the 99 cent apps users can download from the app store. In fact, the App revolution has fundamentally changed the way users expect to interact with machines. We no longer talk about user interfaces, we talk about user experiences. I know, it sounds all emo and new age, but it's true. In modern applications, the most important thing in the data chain is the user, not the database.
This is a difficult transition to make. As software people, we have gotten really good at using jedi mind tricks to help users understand that the way they want to work is wrong. Somewhere as we speak, someone is sitting down with a prospective end-user and having this very conversation in their best monotone drone and blank stare, "You don't want to see all the car colors, you want to see five colors… Yes, I want to see five colors…"
It's hard designing software by starting with what users want because they tend to think of things in ways that we software people don't.
But that's the point.
It actually helps to have the end-user dictate how software should behave because they do not have the same pre-imposed restrictions as people who write the software. Some of the most successful software companies on the planet learned this a long time ago. Let the users design the apps for you - they're happy to do it, they don't ask for much in return, and they are happier users in the end. You'll just have to figure out how to apply software design principals to deliver on what they're asking.
Human-centric design means starting with the humans instead of the machines, which means, while organizational modernization begins with some honest strategic introspection about what's important from a portfolio perspective, ultimately application modernization begins right here.