Your Legacy Software Vendors are Lying to You

Every day I hear of some vendor claiming to be "modernizing" their old product in support of some new technology trend (cloud, headless, microservices, etc). Here's an example from an article I recently read about HCL's plans for WebSphere Commerce:

He also noted that going forward, HCL will be “really focused” on moving toward a microservices approach to its e-commerce platform.

Having spent my career working for software vendors, I'd like to explain why these modernization efforts don't and can't work. 

All established software vendors are facing tectonic shifts. The industry has completely changed over the past roughly 10 years due to the introduction and popularization of cloud. Cloud has given rise to microservices, API-first, headless, DevOps, Serverless, full stack feature teams, and an entirely new commercial relationship that customers have with their software vendors. Someone who retired from software development in 2009 would find 2019’s software and practices completely unrecognizable. 

Here's a chart showing AWS's revenue over the past 10 years, which is a good proxy for the overall market adoption of cloud:

Cloud's introduction to IT is like steel being introduced to the building construction industry in the late 1800's - it completely changed architecture, building practices, and dramatically expanded what was possible. While cloud is this past decade’s major disrupter, the rise of desktop computers, the internet itself, x86 architecture and more have proven to be just as disruptive in decades past. 

Almost without exception, regardless of the decade, all software products follow the same pattern:

Identification of Market Need

An entrepreneur (either inside an established company or someone on their own) identifies market need and forms company to build a software product to meet that need. At this point, the entrepreneur has no more than an idea. 

Building the Product

With an entrepreneur, an idea and some bootstrap funding, the entrepreneur is able to hire a team to build the product. At this point, the team is completely unencumbered. They have complete freedom to:

• Decide the major features their product will have
• Architect the product
• Develop the product
• Deploy the product

Since nobody is using the product yet, there are absolutely zero constraints on what the team can do. 

Early Adopters

At this point, the team is able to launch the product and sell it to early adopters. Early adopters are by their nature open to change - after all, they changed what they were doing to buy the new product. They can tolerate major feature gaps, outages and other headaches that the majority of the market won't tolerate. They expect the product to not work very well. Early adopters buy the product because it's different from the status quo, new and cool - not necessarily out of pragmatism. In the consumer space, these were the people who bought Teslas in 2012 not because they needed reliable affordable transportation from point A to point B, but because Teslas were so different from the status quo. Teslas in 2012 were not good for the vast majority of people. They were expensive to buy and repair, buggy, and inconvenient to charge, yet people believed in Elon Musk’s vision. 

This is the last opportunity that the entrepreneur and team have to make any substantial changes to the product. Early adopters are very forgiving of change and in fact expect it. 

Mainstream Market Adoption

If they’ve done everything right to this point, the entrepreneur now has larger more established companies buying the product. These companies aren't buying the product because it's new and cool - they're buying it because it solves a real problem they have. Mainstream buyers want the product to work off the shelf. They aren't tolerant of major feature gaps, downtime, bugs, or change. Pragmatism is their driving force. 

Calcification

At this point, the product is used by hundreds or even thousands of customers over many years. The product may have been purchased by a big legacy vendor like IBM, Oracle or SAP. With the early adopters already having moved on to the next shiny product, the product’s install base is now composed of majority, late majority and laggard customers. 

With new sales likely declining and technology shifting (in this decade, the rise of cloud), the vendor faces immense pressure to modernize the software to support current trends. Through the power of marketing, on premises apps are suddenly “cloud.” Monolithic applications are suddenly microservices. Applications with fully integrated UI suites are suddenly headless. There may even be engineering efforts behind the marketing. The fundamental problem is that it is far too late to change the product in any meaningful way. There are hundreds or thousands of maintenance-paying customers who do not want the product to change in any meaningful way. They’re fine with bug fixes, small new features and maybe a re-design of the UI but significant change is disruptive and expensive to adopt. They bought the product based on a set of features, they’ve had it running for years, they’ve trained their staff on how to administer and use the software and they don’t want it to change. 

Death

As more mainstream customers abandon the product, the vendor is left with a dwindling install base of laggards who are fine if the vendor would never release another update to the product ever again. The vendor keeps a few developers to fix critical bugs and a few support people to answer support requests, but it’s essentially a declining asset for its owner at this point. The original entrepreneur who built the product is long gone, having moved on to another innovative endeavor. 

And so the cycle repeats itself. 

Commerce Platform Implications

Legacy commerce platform vendors have found themselves on the wrong sides of a number of trends, almost all driven by technology. In just the past decade, the commerce platform space has seen a massive shift from:

• On premises to cloud
• Single tenant to multi-tenant
• Monolithic application architecture to microservices application architecture
• Suite to best of breed
• Commerce platform as hub to commerce platform as just another capability
• Browsers on desktops to applications on all imaginable devices
• Built-in CMS to headless/APIs
• Consume entire platform to consuming pieces a la carte

There was a crop of commerce platforms that were introduced in the late 1990’s and early 2000’s. At 20+ years old, those platforms are clearly in the "calcification" and "death" stage where real change is not possible.

Microservices first became "a thing" the year commercetools went to market. Roy Fielding's famous dissertation defining REST was first published in 2000 with commercial implementations occurring years after that. Apache Kafka, which arguably kicked off the whole event-based architecture revolution, was released in 2011 when commercetools was first being architected. The modern underpinnings of today's technology are all brand new.

Should one of these vendors fundamentally re-architect their product, as they claim, every one of their customers will have to re-implement the entire platform from scratch. At that point, many customers will look at just buying a modern product from a faster, more nimble vendor rather than waiting for years for a legacy vendor to hopefully deliver on their promise. Innovation is especially hard in those big old organizations that tend to own legacy software. 

Vendors make these modernization claims because it gets their mainstream customers to stay with them a few years longer than they otherwise would. With profit margin on maintenance revenue being nearly 100%, there are enormous financial incentives to keeping those legacy customers as long as possible.

In 20 years, commercetools will suffer the same fate and there will be a more nimble platform that displaces us. Such is the lifecycle of technology. But please don't believe that your 20+ year old commerce platform is suddenly "microservices" because you saw it on a press release.

About commercetools

commercetools is a next generation software technology company that offers a true cloud commerce platform, providing the building blocks for the new digital commerce age. Our leading-edge API approach helps retailers create brand value by empowering commerce teams to design unique and engaging digital commerce experiences everywhere – today and in the future. Our agile, componentized architecture improves profitability by significantly reducing development time and resources required to migrate to modern commerce technology and meet new customer demands. 

The innovative platform design enables commerce possibilities for the future by offering the option to either use the platform's entire set of features or deploy individual services, á la carte over time. This state-of-the-art architecture is the perfect starting point for customized microservices, enabling retailers to significantly reduce time-to-market for innovative commerce functionalities.

With offices in Germany and the United States, B2C and B2B companies from across the globe including well-known brands in fashion, E-Food, and DIY retail trust commercetools to power their digital commerce business.

Visit www.commercetools.com for more information.