Thanks for printing! Don't forget to come back to Intellinet for fresh articles!
The Four Pillars of App Modernization
Posted on Oct 27, 2020 10:08 AM by:
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.