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:

LegacyModern
Private data center Public/Private, cloud-native
Manual, infrequent deploymentsCI/CD (at least daily)
Full production deploysCanary/blue-green deploys
Monolithic applicationsMicroservices architecture
Physical serversVirtual machines
Virtual machinesContainers
ContainersServerless functions
Manual container deploysContainer orchestration
Ops-only monitoringObservability teams
Dev and Ops in silosDevOps and embedded SRE
Manually spinning down serversDynamic autoscaling
Performance monitoring via Twitter complaintsInternal SLAs
Track only internal metricsFocus on digital customer experience
Ad hoc monitoringUbiquitous instrumentation
Out of the box monitoringCustom instrumentation
FirefightingInvestments in toil reduction
Reactive incident recoveryRunning game days
No monitoring solutionAPM, 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.

Victor spent the first 14 years of his career writing software for various organizations before moving into project management and leadership roles where he could work more closely with end-users and customers. His experience in enterprise software development, implementation consulting, and post-sales support help him to understand the challenges of running complex systems. At New Relic, Victor is the product manager responsible for Distributed Tracing, a feature that helps customers understand and troubleshoot distributed systems. Victor lives and works in Portland, Oregon, where he enjoys cycling, hiking, soccer, basketball, and adventuring with his family in the Pacific Northwest. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!