Loading Form...
Thank you! The form was submitted successfully.
Ebook | 16 minute read
Why an Unplatform™ strategy works best for commerce technology deployments
According to IDC, digital transformation spending is forecasted to reach nearly $3.9 trillion in 2027, with a five-year compound annual growth rate (CAGR) of 16.1%. At the same time, between 70-80% of digital transformations fail, especially those that involve complex legacy systems, such as enterprise resource planning (ERP). Most teams either go full steam ahead on digital transformation projects, or legacy systems remain unchanged for a long time, despite being complex and difficult to maintain.
Why do companies embrace such an all or nothing approach when it comes to digital transformation—across all sectors? A recent RMW Commerce report showed that retailers would rather suffer under the weight of a dying legacy system than re-platform. Industries from financial services to airlines to governments still operate decades-old Cobol mainframe systems, even though the people who maintain them are rapidly retiring out of the workforce.
Rarely does throwing money at a problem solve it, so why are we so quick to either avoid digital transformation completely or bet the farm on it? Let’s dig into this phenomenon more, and explore a third way—the Unplatform strategy. Unplatforming focuses on a gradual approach to transformation enabled by API economy and modern, composable software architecture.
If a pipe bursts in your house, what do you do?
You’d probably choose neither of these options, since both are ridiculous. Yet, corporate America is filled with rafts and matches when it comes to digital transformation.
How did we get here? You could blame legacy systems, aggressive sales people, and/or legacy thinking. For many teams, it’s tempting to rip and replace legacy systems. However, this process can be extremely disruptive, expensive, and can result in system downtime that companies simply cannot afford.
In reality, there are many ways to modernize. Gartner cites seven good options, and if you’re a developer, chances are you’ve tried them:
Many developers who have been in the situation of modernizing legacy systems have faced the pain of rewriting systems from scratch. But, you don’t have to rewrite or replace a piece of software completely if you embrace a more progressive, incremental approach. This approach isn’t necessarily new. As Martin Fowler wrote 20 years ago, a strangler fig seeds itself in the upper branches of a tree, working its way down to the soil over time and ultimately strangling its host. A similar “strangler pattern” can be applied to replacing legacy system components with composable commerce alternatives, until ultimately the entire legacy system is rendered obsolete. We’ll cover more about how that works in the next section.
For most companies, inertia prevents them from acting on changing their legacy system at all.
Inertia is motivated by fear, whether that’s:
As a result, companies get stuck in the pattern of the way they’ve always done things, even if they do end up replacing their legacy system. The legacy system sets the requirements for the new system, and along with these requirements come the legacy constraints. That’s why even full-scale digital transformation yields safe, disappointing, and not-so-transformative results.
It all tends to make bizarre sense when you think about those peddling large scale digital transformation projects, such as management consultancies, or system integrators (SIs). These teams aren’t incentivized to think about solving problems incrementally. Their business model defaults toward a big bang approach. Sadly, this is a fundamentally broken way of thinking, with high potential for damage if it goes wrong.
In commerce, it's been said that most teams would rather gnaw their arm off than replatform. Or, according to the RMW Commerce report cited above, “No one ever got fired for not replatforming, but plenty of people have been fired for botched replatforms…Management teams have little patience for building towards tomorrow; most executives have their hands full fighting today’s fires.”
Often, digital transformation becomes a “technology problem” instead of a business process problem. Rather than thinking about the problems to be solved, new systems are informed by the limitations of current solutions. Teams have built processes to navigate the limitations, and these processes have become the standard operating procedure. “That’s how we do things here.” Even a new commerce platform tends to perpetuate the limitations of the “broken” system in place. The result is the dreaded “like for like” problem. While the old commerce site was broken, the new version functions just like the broken one.
Why? Too much of commerce is formulaic. The buy-in for a replatform is too high relative to the problem it solves. Even if teams are on a dying platform, or one that an acquiring company no longer invests in (e.g. Adobe or Salesforce commerce solutions), the capacity for change is frighteningly low. A tremendous amount of technical overhead is needed to make even the smallest change—everything requires multiple tickets and too much development time. In other words, current systems don't move at the pace of the business. At the same time, the thought of embarking on a project the size and scale of a digital transformation project breeds inertia. The result? People would rather settle for business stagnation (aka status quo) than attempt to solve their problems one by one.
The beauty of composable architectures lies in the flexibility of a modern, API-first approach. Instead of building from scratch, teams can use APIs to access an abundance of composable software applications. Each of these applications is built to solve a specific problem. API-first applications exist independently, yet separate functions can be integrated and orchestrated to create a complete system.
So what does that mean for replacing a legacy commerce system? You don’t have to replace all of the components at once. With an Unplatform strategy, you can focus on the most urgent business problem to be solved, and select a component that solves it. A progressive approach mitigates risk, and still allows you to hook new components into a legacy system via API bit by bit, until the legacy application is rendered obsolete.
Remember Martin Fowler’s strangler fig analogy? The strangler pattern starts with any component that’s most urgently needed, “strangling” what isn’t working for you step by step. For some retailers, that might be the catalog management capabilities, cart and checkout flow, subscriptions, or shoppable landing pages for your storefront. The answer of where to start is as personal as what matters most to your business’ bottom line. An experienced architect can help you determine how to replace capabilities of your monolith with composable applications, and in which order.
For example, one promotional products company found that the most pressing problems with their legacy systems were the cart and checkout functionality. The team replaced these two components, focusing on their core competency first. These replacements resulted in better conversions and higher revenue. Instead of rewriting their existing technology to support their complex buyer flow, the plan is to replace their catalog management, payments, and offer functionality next — implementing a gradual composable commerce, strangler approach.
Some teams may find the strangler pattern difficult to execute, especially those with legacy applications that do not support REST APIs. One approach is to integrate the new or replaced functionality directly into the existing monolith. Modern, composable systems are designed to be used as individual pieces and make this possible.
A second approach is to move the existing system into a supporting role. In this scenario, the existing monolith can remain the source of truth for most of the data and will not disrupt the business functions until the transition is closer to completion. It’s possible to sync the data between the existing monolith and the new composable commerce solution. The monolith maintains its integrations, but the new system serves customers, ensuring they see the new functionality — making it possible to improve the customer experience and increase conversions.
Like an interior remodeling project, the strangler pattern might seem familiar. You’re essentially redoing your house room by room while you live in it, until it feels like you have a new construction. If you’ve lived through a renovation, you know this process can be painful.
But, if you do choose the strangler pattern, start with an area that creates competitive differentiation for your company, like the commerce catalog. Focus on a problem to be solved, asking: “Where are existing processes too challenging or custom?”
When it comes to the commerce catalog, merchandising requirements have become more complex. In many cases, legacy catalog infrastructure prevents merchandisers from moving as fast and creatively as they’d like to. That includes implementing campaigns, changing pricing structures, swapping out catalogs, taking advantage of new channels, and more. A composable commerce catalog solves that problem by empowering merchandisers with more flexibility and control.
Once you solve one problem, move onto the next solution that accelerates your time to value or improves your customer experience in a meaningful way. After your most pressing problems are solved, you can swap out commodity features that aren’t as urgent to change. The strangler pattern is great because it aligns with a best of breed approach: You can learn about new technology step by step, and Unplatform over time.
The downsides of this approach are that you’re living through the remodel. As a result, you may find that your old platform imposes restrictions you don’t want to deal with. Some critics of this approach also claim you’re just adding new features on top of an old platform, but if you start with the most pressing problems to be solved, you may not find that this is the case.
Another approach is to use a smaller brand within your portfolio to learn and iterate as a PoC. Starting small requires that you think within the context of your brand, not your platform. Many companies have a “multi” problem – whether that’s multiple brands, geos, customer touchpoints, or channels. For some, using a smaller brand or geo as a testing ground for digital transformation could make more sense than decomposing and rearchitecting the house while you’re living in it.
On the plus side, experimenting with a single brand helps you better understand your true requirements, both business and technical. It enables you to truly get a feel for a composable architecture, and then build it to scale.
On the other hand, if you don’t have a smaller brand on which to test, you have to get creative. For example, Pella Windows and Doors started their Unplatform as the first in their industry to create a direct-to-consumer channel. Purchasing windows and doors is complex. As a result, Pella needed the capability for each customer to design their own configuration with its own unique SKU – a process that would be difficult without the flexibility of a composable commerce catalog. After the success of this initial D2C launch, the company is exploring expansion into additional online sales channels.
Other “start small” ideas include experimentation with pop-up stores, seasonal mobile applications, or temporary digital properties to see if composable works for your company.
Elastic Path empowered us to explore new revenue opportunities with their simple, yet flexible commerce platform. We were able to design and launch a self-service experience of complex professional services with little overhead.Kody Myers Director of Product
Elastic Path empowered us to explore new revenue opportunities with their simple, yet flexible commerce platform. We were able to design and launch a self-service experience of complex professional services with little overhead.
Paro, an AI-powered marketplace for finance and accounting solutions, is a fast-growing tech startup that didn't have time to waste with its commerce implementation. As a hands-on, sales-driven organization, Paro wanted to test a self-service line of business that empowered finance/accounting professionals and freelancers to work directly together through simple online engagements.
To introduce these new offerings effectively, Paro wanted its business leaders to be able to manage the product catalog without having to rely on engineering. That way, the stakeholder who owns ecommerce could add products or services, change pricing, and manage the catalog over time.
A composable, API-first approach fits with Paro’s engineering team’s methodology. The team prioritized headless systems that allowed them to think about the best frontend interactions for the customer. Plus, using composable commerce gave engineering the flexibility to experiment and use the best-of-breed technologies they wanted.
Paro successfully launched the portal in five months. Since non-technical users can change the product catalog and make updates, Paro can launch new services or digital products quickly. This level of experimentation allows the company to gather more information from their clients on what works and what doesn’t work – without the opportunity cost and real cost of change that comes with a monolithic commerce platform.
Another common mistake with digital transformation is treating it as an IT project. In reality, successful transformation requires a full team effort, and considering it an IT project accelerates you along the road to failure. How does it start? Many teams face a lack of alignment between IT and business decision-makers. As a result, there are misconceptions between what the technology can actually do and the leadership team’s goals. Here’s a better question: Is the chosen platform or new system flexible enough to handle actual requirements?
A more effective transformation requires IT and business alignment on the problems that need to be solved. For your team, it may make sense to rank these problems in order of urgency, and address the most urgent business problems first. The strangler pattern described above works well in these scenarios, where teams have the digital maturity to effectively understand their requirements and map a series of composable commerce applications to these needs.
Finally, select a system that is capable of growing with your team. Look for a vendor who can partner with you, rather than one that is incentivized to sell more consulting hours and endless custom work. It’s all too easy to fall into the dreaded “like for like” trap, and end up with a composable commerce system that’s just as complex and constraining as the legacy system it’s replacing. However, composable commerce doesn’t have to be complicated. Solutions like Elastic Path Composer make it simple to orchestrate and manage a variety of easy-to-use, API-connected composable commerce applications across different vendors.
When it comes to any large-scale transformation, the secret to success may lie in thinking smaller. Even professional endurance runners who face grueling distances use “chunking,” or breaking up long runs into smaller components, as a mental technique to run faster and train more effectively. In business, isolating the problems to be solved and ranking by urgency can make digital transformation projects far less daunting. Not to mention, this approach reduces the risk of large scale failure or system downtime.
So next time you’re frustrated with your commerce legacy system, don’t think rip and replace or replatform. Think Unplatform. Consider a stepwise approach to replacing the most cumbersome components or smaller commerce sites within your portfolio. Perhaps most importantly, the Unplatform way can help you avoid stagnation and test new ideas without extensive development timelines. The Elastic Path family of products is all about making the barrier to entry for composable commerce much lower, empowering merchandisers, marketers, and other business users to experiment on their terms. And as we know, experimentation is the mother of innovation.
Learn more by reading Strangler Pattern: From Monolith to Modern Composable Commerce.