LEGO moves to headless e-commerce to improve customer experience

LEGO is a brand that needs little introduction. Its colourful building blocks are loved the world over by children and adults alike. However, the company's e-commerce platform began facing some difficulties back in 2017 when it was unable to keep up with demand from customers, specifically around special product releases, resulting in a poor customer experience. 

For example, when LEGO introduced its Collector's Edition Star Wars Millennium Falcon Set in September 2017, the site went down during the UK and US launch, managing just 7 orders per second. At the time the organization was running e-commerce on a traditional, on-premise, monolithic platform, which was struggling to scale and support the traffic. 

Since then, LEGO has undergone a huge change programme, moving to a MACH (microservices, API-led, cloud-based, headless) platform with vendor commercetools. Not only this, but LEGO has shifted to product-focused teams to support the various elements of its e-commerce system and is undergoing more rapid product releases to deliver any business change requirements. 

The move has been a huge success, which is evident from the site's performance since the migration completed in mid-2019. For instance, LEGO introduced 100 new products on January 1, 2020, and it was able to log 35 orders per second, or 2,000 orders per minute. 

We got the chance to speak to Simon Young, Senior Engineering Director of Unified Commerce at LEGO Group, about the project and why moving to a MACH platform is more sustainable for the company's e-commerce future. Providing some context to the shift, Young says: 

If we rewind to 2017, we had what I guess was common for a lot of companies at the time, a monolithic setup for e-commerce. We had an on-premise platform from one of the big enterprise vendors and effectively the sort of speed to create change was the kind of thing that slowed us down. 

Whilst we'd started to move to a more modern front end, and had already started to invest in a React front-end, we still had this sort of big monolithic back end, which took a lot of time to kind of make changes. We'd go through a kind of enterprise release process and on top of that, because it was hosted on-premise, not in the cloud, we had a challenge where it wasn't easy to scale it at a time when the LEGO Group was experiencing record sales growth year after year. 

We had this inevitable challenge of you can't react very quickly and when you do react, you can't react fast enough. You can't scale it. So it was an ongoing problem that we couldn't move at the speed we wanted to, technically or commercially. 

MACH made in heaven

As already noted, the customer experience LEGO is often praised for, was not translating for customers online. As such, the company knew it needed a different platform and a different approach. 

Young says that LEGO was only interested in building solutions where it would be a differentiator for the company, such as the front-end experience. But it is less interested in building something that is effectively available as-a-service, where building it in-house wouldn't add a lot of value. For example, the primary functions of an e-commerce platform - carts, catalogues, search - LEGO felt would be better handled by companies specializing in those product areas.

But the front-end experience is key. Young says: 

What we wanted was the ability to be able to build something where we could move much more quickly. Where we could benefit from a modern approach to software development. We wanted something that was completely headless, that was API first, so that we could build the experiences as we wanted them, rather than needing to be largely guided by the way that the company building the commerce platform thought it should be implemented. If you've got the API's, you can decide what the user experiences look like.

We also recognized that people focused on building something API first and headless, not just in commerce, but in content as well, were innovating more quickly because they themselves had faster development times, shorter development cycles, and faster feedback loops. We recognized as we talked to a few of the vendors, where we ended up with commercetools, that the likelihood of us being able to stay up to speed with what we wanted to, what our stakeholders wanted, and most importantly what our shoppers wanted, was more likely with this headless approach - compared to a platform that maybe only has one or two releases a year.

Building blocks for success

LEGO began its conversations with commercetools back in early 2018. It then started the project in May/June 2018 and officially launched in July 2019. Young says that the underlying priority was to maintain the experience for shoppers all the way through the project, carrying out the migration in the least risky way possible. He explains: 

We didn't want to get to a point where we had this big bang switch over and hope everything worked well. So what we did was we followed a pretty standard pattern of strangling the old platform piece by piece. So using commercetools' APIs, we built an approach whereby, as we were receiving product information into our existing system, we also started receiving it into commercetools at the same time.

And then we also modified our front-end so that the adapters on the front-end would talk to both our existing monolith and then the commercetools platform. And then we slowly started to switch routes over - so, for example, we switched product pages over, then we switched search over. 

And then, you know, at some point you have a bit of a Big Bang, because you have to move your shopping cart over - we moved that over in one hit because of the way we worked with some of our enterprise back end systems, behind the e-commerce platforms. But yeah, over the course of about five months from the start of 2019, we slowly switched over different parts of the site, tested them and retired the old parts of the platform. 

Product teams for speed

However, what has been critical to the success of the MACH platform is how LEGO has changed the structure of its product development teams. The migration has also coincided with LEGO itself growing rapidly over the same period of time and its engineering capabilities increasing - with it now having approximately 100 engineers, up from about 10 at the start of the project. 

At the beginning of the change, LEGO had two teams - one focused on the front-end functionality and one focused on the back-end functionality. However, as it has grown, it now has a product-first approach to what it is building. Young explains: 

Today we see LEGO.com as a sort of meta product, if you like, and it's made up of a set of different product teams. We have a product team focused on checkout, we have a product team focused on payments, we have a product team focused on search, we have a product team focused on the product detail page, on the main content, and things like that. 

And each one of those teams is what we would term a full-stack team, so each team has everything they need to be able to deliver their slice of LEGO.com. There's necessarily a lot of interaction between those teams, but most of them are building independent microservices. But then there's a lot more sharing of how we built the experience and we've broken that down into components that we can that we can reuse. 

And this is helping LEGO improve its speed to market. Young adds: 

There's a lot of independence for each team to go after what they need to do. That certainly gives us a lot of ability to be more flexible. It means as a business priority changes, it's only going to maybe impact one product team, possibly a couple of product teams at most, but the other product teams carry on with their mission. 

And we've seen quite a few times over the last couple of years where commercetools has introduced new functionality, or new API's, and we can simply take advantage of them straight away. So again, the speed to market is the biggest improvement.