MACH in practice with Harry Rosen

Harry Rosen Store Experience
  • Mach
  • Ecommerce
Turning a strategic vision into reality with a MACH-based solution.
10 mins reading time
Thom Armstrong | August 12, 2020

In this post, we’ll be providing an in depth overview into what a MACH-based solution looks like in practice with a real world example, covering Harry Rosen’s vision and recent implementation.

This post is a summary of two sessions Amplience hosted with Harry Rosen, MyPlanet, and Commercetools at our Summer Summit last month. If you'd like to view the recordings of this sessions they can be found here.

For those not familiar with the term MACH, MACH stands for Microservices, API-first, Cloud-native, and Headless. We’ve provided a brief outline throughout this post, but if you’d like a deeper dive into what this is, check out our MACH page that provides a great overview or visit The MACH Alliance for more great content. The MACH Alliance is a consortium of vendors whose aim is to guide and show the business advantages of an open-tech ecosystem that follows MACH principles.

MACH-based solutions aim to future-proof enterprise technology and propel current and future digital experiences with best of breed solutions.

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

- Kathrine Jones, Director of Platform Strategy at Myplanet

Harry Rosen’s Vision

Harry Rosen’s is a 66-year-old Canadian luxury menswear retailer with stores across the country. They follow modern, best practices in business providing personalized customer service and a high touch experience. Their goal was 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. A shopping experience that is personalized and contextualized, to put one of thousands of the products they sell in front of the right customer at the right time.

  3. Lastly, the team at Harry Rosen decided early on that their digital experiences can’t be a competitor to their in store experience. Instead, it must complement and enhance.

Tying this together with a real-world scenario, advisors who bring customers to the site or post something to their social media that lead to sales are appropriately credited. This ensures a consistent customer experience and internal alignment to deliver a superior customer-first experience. Harry Rosen recognized that their customers were in the driving seat, they choose when to shop with an advisor, when not to, and 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.

From Myopic Monoliths to Modern Microservices

With this vision set, it was time for Harry Rosen to begin to take a deeper analytical approach as to where they were today when it came to their technology platform and if it could support the types of customer-first experiences they were looking to deliver. A forcing function began to drive this to a head. Harry Rosen faced a decision in early 2019, they were on an older version of a traditional, legacy commerce platform and had to face upgrading to a newer version or look back to the market for another route. With the experience of running a monolith behind them, they knew that development required a lot of specialized knowledge but simply wasn’t agile enough to deliver on Harry Rosen’s customer-first vision. Harry Rosen understood that they could use the technology as a competitive edge.

“eCommerce in a box is a commodity.”

- Ian Rosen, VP Digital & Strategy at Harry Rosen

As Harry Rosen’s team evaluated the market, it was pretty evident that there was a standard eCommerce framework the majority of retailers and brands were working with: the monolithic commerce platform suite. Once key stakeholders began to consider how to replicate and translate in-store experiences and processes to the digital world, it quickly became apparent that APIs are the critical component and that Harry Rosen had to “own the glass” and connect the backend processes seamlessly. To deliver their vision, they quickly realized that a one size fits all approach and selecting a monolithic commerce suite wasn’t the right approach. Instead, Harry Rosen required the flexibility in selecting best-in-class components for each function that together would create an unparalleled experience, greater than the sum of its parts.

The Migration Challenge

Harry Rosen employed the services of Myplanet to assist them with the solution architecture planning, vendor selection and implementation itself. To compliment these efforts and to ensure Harry Rosen maintained control over their vision, they also employed two developers to handle ongoing maintenance and leveraged 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. A divide and conquer approach was adopted where individual teams contributed to specific integration requirements and specifics, such as merchandising and content teams requiring input from the PIM, ERP and CRM versus the fulfillment side of the organization when it comes to inventory and the OMS.

Harry Rosen and Myplanet spent a lot of time in store and talking to customers and store 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 distill all the processes and nuances down to a single way to serve customers. Some customers wanted a fast, low touch, predictive service while 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, therefore, was 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 front-end 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/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 & 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.

Breaking this down further, you can begin to understand a content graph based approach. One example is highlighted below where we see a composite view of a content block consisting of a title, image and CTA. This content block can be embedded into a page or listing and is made editable on the backend. Content types are matched with a frontend component that can render it.

More complex content types can be created by nesting where required. Complexity should however be kept as low as possible 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 components 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, Founder & CEO at Amplience

Commerce & Content

Amplience’s merchandising extension allows a content creator to pull in product content types from commercetools and leverage them in the content model and subsequent content types, components and assets on the frontend. For example, a product slider can be populated with product information held in commercetools with Amplience storing the commercetools product ID in the Amplience content model to then be leveraged by the frontend to make the call for fresh data to be pulled down and rendered from commercetools.

This bypasses the need to sync vast amounts of data between providers, ensuring content displayed on the frontend to customers is always up to date and enables internal merchandisers at Harry Rosen to work independently from the content and marketing specialists.

Frontend Integration

As mentioned previously, Harry Rosen leverages 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, such as with Algolia search or with Amplience DAM static assets that are already host assets on it’s 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 utilizes 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:

We sincerely hope you found this post highly informative and useful in your own businesses decision making process and solution architecture strategy. If you’re considering a MACH solution for your next project and would like to speak to one of our solution experts we’d be happy to help, advise and provide recommendations, just get in touch!