Another take at writing up why app modernization is important for business, and the usual links to stuff and my recent podcasts, etc.
I’m working on a project I call the #legacytrap. Trying to explain to executives (CIOs and non-IT executives) how important it is to modernize your old stacks of IT, mostly stuff used to support all that in-house software that runs the business. I have a slide I use that summarizes the problem in surveys:
(Sources: “Improving Customer Experience And Revenue Starts With The App Portfolio,” Forrester Consulting, commissioned by VMware, March, 2020. Survey conducted July to Oct. 2019 with 614 respondents and six CIO/SVP interviews.)
Like most long-term problems, everyone has a sense that there’s a problem, and something should be done, but they don’t do it. So, as ever, I’m trying to figure out an angle that will get people to care and do something about it. As I look at it more, I think being held back by legacy is one of the top problems, often #1 or #2, that organizations face when they’re trying to get better, not only at software, but at business. I mean look at those figures. If you can’t ship new features in your software, your business will be dead in the water.
Anyhow, after discussing with a co-worker what I think “digital transformation” means, esp. in the context of VMware Tanzu stuff, I started writing up something that turned into another approach to thinking about the #legacytrap. Here’s the draft.
For the past few years, the 100’s of executives I talk with each year have been focused on something called “digital transformation.” In our conversations, by that, they mean is modernizing how their organization builds, runs, and uses their in-house software. Aside from a handful of lucky ones, all of them struggle to get their organization to change, to modernize. Most people see change as risky, unnecessary even. When’s the last time you changed a core way you live your life?
If you’re struggling with your transformation it might be because you’re focusing on the wrong things, namely, the need to put in place new software stacks, move to cloud, update the “culture” of your IT organization, and rewrite old software. These are things that need to happen, but what you should focus on primarily is adding helping add new business capabilities. I realize I’m being a bit precious - nuanced and tricky - in this distinction, but play along with me. I think you’ll find that if you reverse the order of these two ways of thinking from the start, there’s a huge difference in success at the end.
Think of modernization as building new business capabilities, not updating existing ones.
For all the worrying about “disruption” from tech companies, I think the urgency to transform that most organizations face today are the investor and board priorities to increase revenue (sell more), remove costs (more profits), and enter new markets (selling to new people or creating a new type of business). In business, “growth” is always a priority - the priority? - and I suspect that it’s driving much of the urgency for companies to modernize their software capabilities.
TK( could have some cross industry survey showing next year’s priorities. )
That’s because software is at the core of how businesses run. By no means is software always the product, but it’s often the primary way people interact with the business, internally or as customers. Software is often a major component of products as well. Think of all the software in cars and how your phone becomes part of your car to, for example, unlock and start the car. Often, it seems like your car is merely an accessory for your phone!
A company that wants to enter a new market or start a new business will do so with software. For example, Liberty Mutual needed to build a new set of software to start-up a new business in the Australian motorcycle insurance market. Companies that want to increase sales in their existing business also use software as the primary tool. For example, in one of its sales apps, Daimler’s discovered that regular consumers were interested in buying Sprinter vans and the company rapidly changed that app to change the business accordingly. Finally, companies that want to optimize how their existing business is run use software. For example, Walgreens sped up the prescription refill process with software improvements, and BT is doing similar work to make working with the company easier.
These new business models and capabilities require new software features and capabilities. As magical as software is, it doesn’t evolve on its own. Your apps don’t attend the all hands meeting, hear your new priorities and strategy, and then update themselves accordingly. Obviously, the software has to be changed by people, by your programmers but also the people who decide what the software does and how it does it (product managers and designers). Finally, how and where your software is run doesn’t change after that inspiring meeting either: operations people have to update, migrate, and build new environments for your apps to run in.
The problem, then, is that you have new requirements for your software stack. Your software was built to service one set of business capabilities and now it needs to service a new set. In order to meet those new business needs, you need new software and a new way of building and running that software. That’s what “modernization” means in organizations that are successful: putting in place the changes and new technology needed by those new business capabilities. This means that the modernization, “digital transformation” programs they put in place are guided by the business, not by technology. Again, this distinction can seem like splitting hairs, but getting the order of cause and effect correctly is critical.
Here’s the missing piece that’s put many organizations in the “legacy trap,” as I like to think of this while conundrum. They were all missing a critical business capability: agility. Most businesses focused on delivering the business needs right in front of them, the new way to deliver groceries, the new way to transfer money, the new source of data for train maintenance. Businesses also need to prioritize their ability to change and adapt. This is hard, to say the least. I’m asking businesses to get good at expecting the unexpected. Obviously, I don’t mean predicting the future. What I mean is putting in place the tools and ways of thinking that allow the business to discover and adapt quickly. This is first done by principals, enforced by culture, and, critically for us, enabled by how you do software.
Every business I’ve encountered has said they value agility - flexibility, adaptability, innovation…whatever words they want to use. Few of them seem to know what that means operationally, especially when it comes to software. In general, I think this is fine, really. In years past, software capabilities were designed to be slower, more deliberate. That was a compromise made in favor of predictability in feature set, budget, and schedule. Often businesses back then didn’t need speed, there was no urgency to change how the software worked because, often, there was no urgency to change how the business worked as there his now. Well, perhaps there was urgency, but you had years to respond rather than months, or, at best, just one year. The technology and software practices used often were not up to the task of rapid delivery. This is all to say that the software capabilities you have now are likely the ones you needed and could get at the time. And, indeed, it all worked well enough for your company to still be alive today, to even have the need to evolve.
What “agility” means has changed, perhaps more than anyone could anticipate. Ironically, software is part of how it changed so much: without anything holding you back, you can write your software to do most anything very quickly. Companies that are good at software can create new business models and features faster than incumbents can adapt. Many of them will follow classic Disruption theory: providing lower quality products and services for lower prices than incumbents. For example, a branchless bank with no ATMs or checks, 24 hour insurance instead of annual insurance, a therapist you can’t see in person, and so forth. However, some incumbent companies that are good at software are doing better than they’re given credit for. For example, The Home Depot has modernized its approach to software development to be more product-centric. By studying and experimenting with how people buy large appliances, the company rapidly changed its software to improve the buying process, TK( driving some kind of good result, even if just “kept more people engaged through the buying process than churning to competitors.” )
Agility now means a shorter time window for discovering and learning how to best serve customers. I don’t mean getting it right the first, second, or even twentieth time. I mean learning and acting faster, and, thus, getting closer to improving the business faster. Agility now means the ability to learn quickly and also act based on that learning, over and over as frequently as possible. I like to focus on a week as the time frame. The changes that drive what you learn may be small. For example, in software, it could be as small as simply moving a button a tad to the right, or having a “Next” button on the top and the bottom of a sign-up form. It’s the constant learning and constant informed next experiment that’s key.
So, here’s the new business capability you need that you’ve probably been neglecting: the ability to change the business every week, even if it’s just a tiny change. To see where you are, ask yourself some these questions:
Not all of these can, or should be done in a week. But each of them will be done better with more agility.
As the ultimate way of diagnosing your business agility, ask yourself how long it would take to release the exact same version of your software to production again. No new features, no code changes, nothing: just the same version of your software. In all likelihood, it’ll take a long time.
Ignoring, or simply just not knowing the need for this business capability for agility is one of the main reasons that companies find themselves in the legacy trap: held back by software stacks that cannot change and be released quickly. Software, which was once the most agile, fastest moving part of the business has become the bottleneck.
Once you understand that agility is a vital business requirement, you start thinking about maintaining and updating your “legacy” stuff differently. For those who don’t grasp and manage by that notion (most people?), you’ll probably still need the trick of bundling that work into providing new features. Sooner or later, it’ll be urgent enough.
I’m not really a font-head, but isn’t this one fun?