The Journey to Composable Commerce
An Interview with Advisory Board Member Giles Smith
Modern commerce requires a new set of enterprise tools. We recently sat down to discuss the disruption in retail technology with Giles Smith, Digital Director at a well known luxury retailer and independent member of the MACH Alliance Advisory Board.
Over the last two years, Giles has helped his company transition from a monolithic, legacy commerce platform to a modern, composable architecture. He took the time to share his experience with us about this journey as well as his advice for brands and retailers who are making the move to modern commerce.
Why Commerce is going MACH
For so many retailers the desire for new commerce technologies stems from the way our shopping habits have evolved over the last decade. “Today shoppers demand a joined-up multi channel experience in any location at any time, whether on an inspiration journey, impulse shopping or returning to aftersales” explains Giles, ”Customer needs, and their expectation around fulfilling those needs, have shifted and continue to shift faster than ever”
This rapid change in customer expectations is outpacing the capabilities of traditional enterprise software. “Our legacy platform was amazing for 2011 when all it had to handle was desktop commerce but as customer expectations grew we had to build new capabilities to stay competitive.” Giles says the problem isn’t always that these custom capabilities aren’t good, but that they were built on top (and on top and on top) of so many other changes that it created a huge mess. Making it cumbersome to update, change, or even diagnose an issue in the platform. “However, the main reasons for adopting MACH are centered around the customer, not the technology. A MACH approach enables faster feature development and innovations, more joined up personalized and localized experiences, and more performant and reliable customer experiences”.
“Agility is now mandatory for survival, not a differentiator.” says Giles, and software designed in the era of static shopping simply hasn’t been able to keep up with the explosive growth of digital commerce channels. “Maintaining coupled monolithic applications, or multiple front-end channels and websites with separate, fragmented code bases is a big duplication of effort”.
Enterprises need architectures better equipped for change, and many are turning to technologies built with MACH principles (Microservices, API-first, Cloud-native, Headless) to become more flexible. These four factors have been a rising trend in software development and, as the market has matured, a perfect storm has brewed for enterprise adoption.
“There are so many forces working together.” explains Giles, “The advancements and mainstreaming of SaaS, Cloud and API-first principles, as well as techniques like Automation. Then you throw on top a culture of agile delivery, and modern engineering practices. All combined, it means that everything is just immensely faster and more flexible than it used to be”
The Benefits of Composable Commerce
“A benefit of the more monolithic platforms, from a business user perspective, is that everything is in one place.” says Giles, “But the compromise is that while you might have a nine out of ten search feature in the platform, it may come with a five out of ten content management tool, or DAM. In my view, composable architecture lets you pick the right choices for your customer and teams which brings together specialist technology over generalist”
For example, many luxury retailers or experiential brands don’t need a commerce engine built to handle complex promotions, enormous volumes, or range, as those features would go to waste. Instead, they can go for a lean commerce platform that has the API-based flexibility that enables the brand to focus more on content and brand moments that personalize and localize the customer experience.
Choosing a composable architecture over a monolithic approach does mean dealing with more platforms, but leveraging the benefits of MACH design alleviates many of the headaches of traditional software.
Firstly, truly cloud-native solutions offer rolling, backwards compatible updates which removes the burden of version control. In Giles’ experience, “With a legacy platform, every time there is an upgrade you have to endure the disruption of doing it regardless of the customer benefit it brings. Maybe they mandate it too close to Christmas, or it needs two days of downtime, or six weeks of regression testing that you don’t have time for. None of these considerations are a big concern for me with MACH technology platforms.”
Secondly, because MACH tools are built with the same API-first and microservice design they form a cohesive solution ecosystem.
“Our search, our DAM, and our content platform are all built by the same lean team of engineers, who built them using consistent engineering languages and frameworks. This means that we can maintain and serve those capabilities with tight and efficient teams” says Giles, “There is a significantly tighter, more empowered, flexible and autonomous team profile when we compare legacy technology teams against those working with MACH platform integrations.”
For example, Giles says he has witnessed teams finding that creating a new payment method using true MACH technology like commercetools can be more than twice the speed compared to using their legacy commerce platform.
With less cost, effort, and headcount required to maintain the core platforms, those resources can be invested in more innovative areas. “This in turn frees up funds to experiment in emerging channels and capabilities like virtual selling perhaps, or gaming,” says Giles, ”Even though they aren’t MACH related, they can join the agenda because so much less time and money is spent on big teams supporting focused on such a narrow set of digital capabilities.”
“Overall, when I look at it from the teams I have at work,” says Giles,” our outcomes are faster, our teams are smaller, our people are happier, and from a technical perspective the releases, outages, upgrades are all quieter. It doesn’t oddly get easier, the expectations rise again and we keep going, but then a true digital product organization’s work is never done!”
Accessing MACH Benefits Requires Digital Maturity
While Giles is a proponent of a composable, MACH architecture he stresses that it’s not for everyone. Adopting a model of multiple SaaS platforms, where you don’t own the features or data storage, requires a confident shift in perspective from an engineering, business, finance, and leadership point of view.
“Before you go with a MACH roadmap you do need to have a really honest word with yourself about the maturity of your organization.” says Giles, “If there is a huge cultural void between I.T. and the business, or if there isn’t a good foundation of modern engineering practices, like automation, DevOps, and Agile then you may struggle.”
If software is being released in months and not weeks, if you have to pull down the website to release new features, if there are big outages in getting your system back online from offline - these can all be signs that an organization isn’t yet mature enough for the benefits of MACH to outweigh the complexities.
“If you don’t have the headspace to figure out how it will all glue together for your teams, and how they’ll operate across all the systems, then I think the monolith all-in-one capability platform serves a purpose of removing those headaches despite the limitations and likelihood you will end up doing a major re-platforming again in a few years when the cycle repeats itself” explains Giles.
A Big Picture Mindset
A main reason moving to MACH requires organizational maturity is because a successful transition requires companies to create a long term vision for their technology, instead of solving the noisiest pain points one at a time.
For Giles’ team, creating that long term strategy first required a full assessment of current technology. Looking at all their digital capabilities from a customer perspective, they mapped out which ones were red, amber, and green and made a holistic plan on the best ways to turn, and keep, everything green.
“In some ways at the beginning it was a bit slow and steady, with that vision, strategy and evaluation period being measured in pace and iterative in nature.” says Giles, “But had we not done those steps I genuinely think we would probably just have started building point solutions without really knowing what we were aiming for long term.”
For many companies going composable, that long term strategy includes weaning off legacy platforms one microservice at a time. This means, for a while, there will be parallel development on both the old and new platforms. Investments may be made in the old platform to give customer access to new capabilities now, with the trade off that it moves the goal post slightly for a full transition to the new technologies.
“Our leadership is very supportive, they understand that balance and don’t have the old school mentality around success or failure being attached solely to go-live dates.” says Giles, “No one is going to bring down the morale of a team who have dedicated the last six months to a project just because they need three extra days to add one last thing that is going to give us better stability.”
“The whole attitude towards dates has shifted,” Giles continues, “We never set out to do this at record speed. We set out to do it to fast track customer benefits, to minimize disruption to our existing business, by removing the legacy technology in appropriately sized chunks.”
Advice for Going MACH
For companies ready to go MACH, Giles has some advice that he learned along the way.
Find your own fit
“It would be impossible for me to go to another brand and tell them the five microservice platforms they should go with. Although i would certainly browse the MACH community for a very authentic shortlist”. While it’s tempting to see companies that are pioneering composable architecture and simply copy their set up, Giles explains that doing this negates a major benefit of MACH tools - being able to granularly select the right tools for your specific business needs. As his friend once aptly described, “It’s like wearing your friend’s suit to a wedding. Technically you are wearing a suit, but it will also feel and look very uncomfortable compared to something tailored for you”
A new approach to RFPs
Previously having been a consultant himself, Giles knew that the traditional style of time consuming RFPs was neither going to bring out the best in the software vendors nor help him make a decision. Instead, there was a very lightweight RFP process to narrow the selection down to two candidates and then a hackathon to make the final decision.
Giving your developers access to the technology dispels any of the myths around the sales presentations, and by seeing how different vendors tackle the same objective you can see which is a good match for your organization.
Front-load the customer benefits
When replacing one monolithic platform with a network of microservices, it can be difficult to know where to start. For Giles’ team, building a new search platform integration was the first priority because it was a less complex project that returned a high value in customer experience.
“It was a no brainer, really.” says Giles, “If we get momentum by delivering customer value then people are going to trust us to continue the journey. It helps secure further investment, that there’s going to be confidence in our execution, and we get to front-load the benefits to show that this isn’t the old way of doing this where technology improvements meant waiting for two years before our customer and teams enjoy these new tools”
If he was to do it all again, Giles does say there are some changes he would make. “If doing a front-end and back-end re-platforming at the same time, this can get complex and perhaps a more simple approach would be to tackle one first then the other. But that said it really depends on the risk vs reward, and urgency on each agenda for the specific organization”
Perhaps by organizing the front / back end programmes in sequence would have made it easier to allocate people, technology, and budget and help decouple the delicate art of aligning outcomes and timelines. Running complex plans in parallel increases the risk of misaligned timelines, which can lead to short term frustration for teams having to carry out their work in both the old and new platforms, or dual-running on operating and licence costs.
“It is less than ideal if you users have this new Ferrari for some of their work activities yet still have to also drive this terrible car from ten years ago.” explains Giles, “Working in hybrid between the old and new platforms would be fine for a short defined period as a teaser, but if it goes on for a prolonged timeline it’s quite disruptive to people's’ role as well as quite frustrating when you’ve now seen what great looks like.”
Want to Learn More About Composable Commerce?
If you're curious to learn more about a MACH architecture for modern commerce, check out the recent MACH Tech Webinar - Composable Architecture and Repeatable Patterns.