What does it mean to be a “modern software company?” Does it mean you’re a cloud-native startup building the slickest UIs on the web? Does it mean you’ve got a cool logo and a hot-shot dev team working in the most bleeding-edge frameworks?
Being a modern software company is a bit more complicated than all of that. After all, no one company uses all the coolest toys, and degrees of technology adoption vary widely, from PoC tests to full production implementations. So maybe—just maybe—being a modern software company is really a multifaceted amalgam incorporating many factors of how organizations create, ship, and maintain software.
Technology + culture = modern?
It’s not just about technology, either. What if the modern software company represents a particular combination of technology and culture? Sure, technology is a huge piece of what makes a software operation modern. Modern companies are often living in the cloud, running containers, using orchestration, and employing all sorts of interesting architectural patterns, from microservices to queue-based load leveling to serverless.
But the cultural aspect is just as critical. True modern software companies employ the kind of best practices described in Gene Kim’s DevOps Handbook, and Google’s Site Reliability Engineering book, from development teams owning the code they create to continuous integration/continuous deployment of software updates. So how about we define the modern software company as a leader in using new technology and culture to deliver customer value more quickly?
Why “modern” matters
Becoming a modern software company isn’t just a semantic issue. Modern software companies demonstrate a greater ability to quickly develop and evolve to keep up with customer expectations and needs. That’s true both in the moment and over time.
Efficiently handling e-commerce traffic during peak times, for example, requires dynamically scalable frontend and backend resources. Similarly, devoting the maximum amount of limited resources to game-changing innovation instead of toilsome work means investing in tooling and automation to eliminate repetitive jobs that computers are more well suited to do and to keep things running as efficiently and predictably as possible.
So, why doesn’t everybody just do this? Why don’t all companies employ the latest tools and processes in an effort to become a modern software company? Well, it turns out change is really hard.
Becoming modern isn’t easy
Back in the 1990s, for example, Waterfall development was the normal way of executing on projects: a lot of people spent months defining 100-page functional requirements documents and creating designs.
Unfortunately, engineers didn’t talk to the people creating all the upfront requirements any more than they did actual customers. Not surprisingly, at the end of the Waterfall, teams often found failure—projects were over budget, late, or, even worse, engineers found that they had built products and services customers didn’t even want, like, or use. It was pretty terrible.
In response, in 2001 a group of engineers got together to write the Agile Manifesto. (Fun fact: New Relic’s own Ward Cunningham was in the room.) They were trying to solve some of the worst problems we faced in building software during those times. Despite the tough changes required, by 2010 most software companies were Agile software companies—the definition of a modern software company at the time—and many of those that hadn’t become Agile weren’t around anymore.
Today, as the concept of a modern software company continues to evolve, we need new ways to measure where companies fall on the road to modern software development.
“Modernity” is a spectrum
Unfortunately, there’s no single indicator with which to measure how “modern” a software company is. It’s not a matter of size or age, for example. In fact, today’s modern software companies range from brand new startups to established enterprises. They employ a wide variety of cutting-edge technologies and adopt a broad range of cultural best practices. Just as important, many of these traits are often not binary, but fall along a spectrum from legacy on one side to modern on the other.
For example, one question might be where most of a company’s infrastructure resides: in the cloud or a private data center? If the answer leans towards the cloud, we consider them more modern. If the answer is fully in a private data center, that tends to move them closer to legacy status.
So what are the key axes that determine where a particular organization lands on the “modern software company” spectrum? The chart below offers some examples:
Legacy | Modern |
---|---|
LegacyPrivate data center | ModernPublic/Private, cloud-native |
LegacyManual, infrequent deployments | ModernCI/CD (at least daily) |
LegacyFull production deploys | ModernCanary/blue-green deploys |
LegacyMonolithic applications | ModernMicroservices architecture |
LegacyPhysical servers | ModernVirtual machines |
LegacyVirtual machines | ModernContainers |
LegacyContainers | ModernServerless functions |
LegacyManual container deploys | ModernContainer orchestration |
LegacyOps-only monitoring | ModernObservability teams |
LegacyDev and Ops in silos | ModernDevOps and embedded SRE |
LegacyManually spinning down servers | ModernDynamic autoscaling |
LegacyPerformance monitoring via Twitter complaints | ModernInternal SLAs |
LegacyTrack only internal metrics | ModernFocus on digital customer experience |
LegacyAd hoc monitoring | ModernUbiquitous instrumentation |
LegacyOut of the box monitoring | ModernCustom instrumentation |
LegacyFirefighting | ModernInvestments in toil reduction |
LegacyReactive incident recovery | ModernRunning game days |
LegacyNo monitoring solution | ModernAPM, infrastructure, mobile, browser, and synthetics monitoring |
Note that some practices—using VMs and containers, for example—fall on both ends of various axes, depending on what they’re being compared with. That actually makes sense, as an organization that embraces containers would be considered more modern than one relying on VMs, but less modern than a company moving into serverless.
Obviously, there’s no such thing as an overall “modern software score.” Nevertheless, the more an organization embraces key technologies and cultural best practices, the more modern it becomes. Just as important, the concept of a modern software organization is dynamic, changing over time as once-cutting-edge practices go mainstream and brand new technologies appear.
Still, we hope the factors listed here can help you place your organization on the modern software spectrum, and suggest paths to becoming even more modern. If you want the confidence to move fast and stay ahead of the ever-accelerating pace of technological change—not to mention your competition—becoming a modern software company is no longer optional.
Tori Wieldt, Lee Atchison, and Clay Smith contributed to the ideas in this post.
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.