MACH in Practice with Harry Rosen

Want to know what a truly MACH based solution looks like in practice?

Our project with Harry Rosen provides the perfect real-world example, from vision to implementation and beyond.

For anyone not familiar with the term, MACH stands for microservices, API-first, cloud-native and headless. We’ve provided a brief outline throughout this post, but for a deeper dive check out our MACH page or visit The MACH Alliance. The MACH Alliance is a consortium of vendors whose aim is to guide and show the business advantages of an open tech ecosystem that follow MACH principles.

“MACH is the new paradigm for enterprise retailers & brands.”

- Kathrine Jones, Director of Platform Strategy at Myplanet

Harry Rosen’s Vision

Harry Rosen is a 66 year old Canadian luxury menswear retailer with retail stores across the country.

The brand has always taken pride in providing personalized customer service and a high touch experience. Now it wanted to bring this customer-first experience into all web and digital touchpoints.

 For Harry Rosen a customer-first experience means:

1. Lightning fast, especially the mobile experience 

2. Personalized and contextualized, putting one of thousands of the products it sells in front of the right customer at the right time 

3. Complements and enhances the in-store experience rather than competing with it 

Harry Rosen recognized that its customers were – and still are – in the driving seat. They can choose when to shop with an advisor or not, for example, or when to engage customer service.

 There are thousands of potentially unique customer journeys that combine these personalized in-store and online moments and interactions together.

 Bringing all those different elements together into one consistent, seamless experience was the (not so little) challenge Harry Rosen was trying to solve. 

From Myopic Monoliths to Modern Microservices

With this vision set it was time for Harry Rosen to take a deeper analytical approach. Where was its technology platform today? Could it support the types of customer-first experiences the brand was looking to deliver? And if not, what needed changing?

This process led the team at Harry Rosen to face an important decision early on in the process. They were on an older version of Hybris and had to either upgrade to a newer version or look at a different option entirely.

They knew development on Hybris required a lot of specialized knowledge and simply wasn’t agile enough to deliver on Harry Rosen’s customer-first vision.

“eCommerce in a box is a commodity.”

- Ian Rosen, VP Digital & Strategy at Harry Rosen

As the Harry Rosen team evaluated the market it became clear there was a standard eCommerce framework the majority of retailers and brands were working with: the monolithic commerce platform suite.

The team realised that APIs are the critical component when it comes to replicating and translating in-store experiences and processes to the digital world, and that they had to “own the glass” and connect the backend processes seamlessly.

A one-size-fits-all approach with a monolithic commerce suite wasn’t going to work. Instead Harry Rosen needed the flexibility to select the best possible components for each function that together would create an experience greater than the sum of its parts.

The Migration Challenge

Harry Rosen hired Myplanet to help with the solution architecture planning, vendor selection and implementation. To compliment these efforts and to ensure Harry Rosen maintained control over its vision, the team also employed two developers to handle ongoing maintenance and used internal business analysts to translate processes into project requirements and scopes.

Ecommerce sites don’t operate in a vacuum and require collaboration with other systems and teams. The brand adopted a divide-and-conquer approach where individual teams contributed to specific integration requirements.

Harry Rosen and Myplanet spent a lot of time in stores talking to customers and employees, mapping out the white glove customer-first experience they are renowned for.

There is no one way that Harry Rosen sells and it was challenging to distil all the processes and nuances down to a single way to serve customers. Some customers wanted a fast, low-touch, predictive service whilst others wanted to spend more time with the Harry Rosen team and understand the details of each product as part of their purchasing decision process.

The most important thing was therefore to deliver a degree of flexibility, building in the foundational pieces to allow Harry Rosen brand online and in-store to rapidly change, morph and adapt as required.

From a technology standpoint, the monolithic platform is broken down into its constituent components.

Next.js was selected as the frontend javascript framework, deployed and hosted on Vercel.

Amplience was selected for the CMS and DAM capabilities to power the experience layer, including the menu navigation, pages, slots, content types and digital media assets.

commercetools was selected to provide commerce functionality including the product catalog, carts, orders, pricing and promotions with a flexible data model under the hood, enabling Harry Rosen to handle a wide array of complex commerce use cases.

Lastly, Algolia was selected to provide an unparalleled search experience for both customers and staff, with advanced search capabilities, refinement, personalized results and voice search.

The Project Roadmap With Mounting Pressure

With a rapidly changing retail landscape, compounded by the effects of Covid-19, Harry Rosen and Myplanet split the implementation down into components to be tackled in short sprints.

As more traffic began to hit the monolithic Hybris platform and the pricing and promotion strategy shifted, Hybris began to come under strain and required the new technology stack to be set up in parallel.

Harry Rosen then had to begin closing stores due to lockdowns. All these factors meant that the new online experience became critically important to continue operations in this new world we all now find ourselves in.

“This accelerated the MVP launch down to a 16 week deployment schedule.”

- Kathrine Jones, Director of Platform Strategy at Myplanet

These solutions are stitched together on the frontend to create the overall customer experience and are synced on the backend to automatically and seamlessly handle data transformations which we’ll cover in more detail over the next few sections.

Experience and Content Modelling 

Traditional monolithic platforms have a page-centric model with one site template engine that pulls in various objects and elements from an underlying database.

When we start to decouple this with a MACH-based approach that has a frontend such as Next.js that is based on more of a component based approach, content modelling is required.

This is where Harry Rosen began to map the content managed components on the backend to the frontend components. This extends beyond pages to a more granular view that revolves around slots and delivery keys that is easier to map at the component level.

More complex content types can be created by nesting where required. Complexity should be kept as low as possible, however, to balance how simple it is to implement and maintain in code.

A great tool like Storybook will allow you to quickly design these components first and share them with stakeholders and content creators to ensure feedback on scope, agreed creator flexibility and signoff is attained before schema creation in Amplience and binding to the APIs takes place.

Headless Preview Capabilities 

Once a component’s design and schema are implemented this enables Harry Rosen to make use of the preview feature in Amplience based on a component’s unique delivery key, enabling content creators to see what the changes they are making look like before scheduling and/or publishing takes place.

Myplanet built this preview application by taking the virtual staging environment (VSE) and content IDs to hydrate and render an individual component.

The code in the preview environment should match the production code to ensure preview accuracy for the content creator. Once the preview environments are created the developer is no longer required and content creators no longer face bottlenecks in their content production pipeline beyond the content creation itself!

“Mature best-of-breed MACH solutions, such as Amplience, can rival and surpass both the developer and editorial experience requirements.”

- James Brooke, Amplience Founder

Commerce and Content

Amplience’s merchandising extension allows a content creator to pull in product content types from commercetools and use them in the content model and subsequent content types, components and assets on the frontend.

A product slider can be populated with product information held in commercetools, for example, with Amplience storing the commercetools product ID in the Amplience content model, which is used by the frontend to make the call for fresh data to be pulled down and rendered from commercetools.  

Frontend Integration 

As mentioned previously Harry Rosen uses Vercel to host both the frontend Next.js site, serverless functions and CDNs. Vercel can cache both the pages and the API requests to ensure a highly performant site, even when hydrating and rendering dynamic content from APIs.

A regular React application typically doesn’t play well with search engine optimization, rendering a blank HTML file and then making dynamic requests to load content in from APIs. To remedy this Harry Rosen took a server-side rendering approach delivered via cached pages/responses over Vercel’s CDN. Instead of the frontend talking directly to commercetools or Amplience, most requests are directed through the serverless functions caching layer.

In some circumstances this doesn’t make sense, of course, such as with Algolia search or with Amplience DAM static assets that are already hosts assets on its own CDN.

Caching Strategies for MACH Architecture

The Harry Rosen caching strategy makes for incredibly fast load times and a highly performant site experience. It’s worth reviewing Harry Rosen’s caching strategy in a little more depth.

A regular cache caches content that expires after a set period of time. Harry Rosen uses a “stale-while-revalidate” approach. The difference here is that the cache will refresh and rehydrate itself on expiry every 24 hours (TTL).

Site traffic automatically keeps the site cache up to date, including JSON API responses. The result was response times that are typically 2-4x faster. This also ensures that APIs are protected from traffic surges and leads to a more robust solution.

Lessons Learned

Harry Rosen and Myplanet have kindly broken down why they chose commercetools, Amplience and Algolia, the biggest wins and what they learned with each vendor which we have shared directly below.