Views and Facts
When and how do you cut ties with a long-term platform partner despite having spent millions on them over a number of years? When does it make sense to stick with an incumbent commerce platform when there are “cheaper” or “slicker” platforms out there?
Furthermore, does the rise of the Micros-service, API-driven, Cloud, Headless (MACH) ecosystem mean that it now makes sense to ditch what you have and go 100% MACH?
A well-established fashion brand based in the UK has recently decided to move away from their incumbent “monolithic” ecommerce platform of many years standing. This came just after they had spent millions on an upgrade. Just over a year beforehand the same brand ended a relationship with a marketing and sales platform after only 18 months, despite investing the best part of £2m in it and it being cloud-based and relatively open. This company is going 100% MACH.
A mile down the road a retailer is maintaining a core commerce platform that is nearly 15 years old, despite a relatively high maintenance cost. But they are investing in MACH technologies that wrap around this platform.
I know both of these companies well, having worked with or for them over the last 20 years. All of these decisions are not clear-cut and are broader than a Sunk Cost vs Lower Long Term Cost of Ownership or Build versus Buy. They are driven by a desire to manage risk with the prospect of greater capability. But they were also informed by the new wave of software providers who offer more open, modular and accessible platforms.
So, when does it make sense to ditch the lot and go 100% MACH and when does it make sense to stick with what you have?
Introducing the “quick and easy, “no discovery needed” tech ecosystem quiz:
- Does your current ecosystem make things difficult to change?
- Are you currently operating a big monthly or longer release cycle?
- Does it feel like you are upgrading your systems all the time?
- Do you seem to be using 50% of a platform but paying for 100% of it?
- Does swapping out a part of your ecosystem fill you with dread?
- Are Devops, CI/CD and Product-led roadmaps blocked by your current setup?
- Would the increased revenue from a MACH ecosystem outweigh the costs and risks associated with a full replatform?
If you answered “yes” to all of those questions it would probably make sense to think about a MACH ecosystem to replace pretty much everything in your tech ecosystem short of maybe ERP.
This is where our fashion brand found themselves:
- They couldn’t add new functionality quickly, everything took months and cost a fortune via their incumbent SI and estate.
- They were struggling with a 1 month release cycle, but if there was a bug (especially a P1) then they had to undo everything. It was all a bit “waterfall”.
- They spent 18 months upgrading an ecommerce platform. At the end of this 18 months they then had to spend another 12 months upgrading again.
- They purchased 100% of a CRM platform but never managed to use more than 30% of it and spent millions trying to get it to do what their old system did.
- They could not easily swap or add capability to their estate. Everything was siloed (including the teams) and not designed to work with other systems.
- Automated Testing, “proper” agile delivery, CI/CD and cross-functional product teams could never work because the tech did not support it.
Ultimately they were losing out to competitors because they could not keep up with customer expectations or launch into new territories or brands fast enough.
The solution was to adopt a MACH strategy, putting in place platforms that were API-driven and therefore “spoke” to each other nicely. It also created a no-upgrade cycle environment and allowed for a proper dev-ops approach. IT could get on with developing capability and a Headless front-end with decent business tooling meant the business and commercial teams stopped hating the IT team for saying “no” or “sucking teeth” when asked to do stuff. A lot of functionality is “out of the box” but there is a lot of room to extend and build bespoke capability due to the API and Microservice nature of the solution and open architectures which are easy to develop.
The initial cost of making this move was relatively high, but the savings over the next 3 years made it worthwhile. The real benefit is that the business is now very agile and can now proactively engage their customers as opposed to reactively try and catch-up. Customer experience is considerably improved and there has been a 30% increase in conversion and similarly high increases in customer satisfaction and loyalty.
If you recognize parts of the above list or all of it, you might want to consider changing your setup completely or partly. If you have a good and stable ecosystem that does what you need you probably don’t want to rock the boat too much. Maybe you don’t need to release new capability every week. But look at the parts of the list you do recognize. Perhaps your customer facing front end is reliant too much on a release cycle or the backend. This would suggest (like with the retailer mentioned) that creating a Headless front-end would free your commercial and marketing teams to get on and do what they do. This would also de-risk any future changes to your “back-end”.
Perhaps your Order Management System is getting a bit creaky and is finding it hard to keep up with modern customer expectation. Maybe an API-driven, cloud-based, replacement would scratch that itch.
Wait… you have now got a hybrid MACH ecosystem but have kept your trusty old platforms. Best of both worlds right?
Ultimately the rise of MACH as a technology ecosystem increases the options and reduces the risks for businesses to keep innovating and stay agile. It is no longer a case of “big-bang” or “as you were”, for the first time there is an ability to “mix it up”.
MACH: Business Technology for 2020 and Beyond
”66% of developers find that maintaining and “paying for” technical debt (aka the money, flexibility, and opportunity lost to a bad technical investment) associated with outdated technology is bad for their productivity at work." State of the Developer report 2109, Devada