SAP Spartacus with a Proof of Concept

Care to share?

What’s common for SAP CX and SAP Spartacus eCommerce projects? Business-wise, they’re typically doing well. This means scale, and the fact is this is where the platform shines the most. 

Replatforming at scale can be a tough decision. A few weeks ago, we talked about the proven enterprise-grade platform strategies for Spartacus. This time, I’d like to discuss another idea for making the beginning of the project easier, and that’s proof of concept.

The goals

The best PoC is something you and your team can build within two to four weeks and use to get buy-in from the business stakeholders. They very often need to see it before they approve the budget in order to see what they’re buying. It works great for this purpose.

Integrate with legacy

There’s another category of upgrades and migrations that, even when keeping the legacy system, you want to use some parts of the new platform inside of it. 

One of the cases we’ve been working on quite recently was a Spartacus implementation where we needed to use the new Smart Edit content management system (CMS) in the old accelerator-based Hybris instance. The mega-menu component was planned to be managed in the new CMS while still rendered at the legacy website.

For this case, the micro front-end’s design pattern sounds like a fit. You could render a DOM-separated JS component from the new platform and just embed it in the legacy one. I can imagine the whole shopping cart, product detail page, or any other site element integrated this way.

The performance can be a question, especially in the case of having too many granular web components. It’s easy to get into an over-fetching situation that can be managed with frameworks like single-spa or redux-micro-front end.

UI sells

If you’re doing the PoC to convince the business stakeholders to budget for a bigger change, setting the project scope to start with the user interface (UI) elements is very often a good idea. Why’s that? Because the UI is where the conversion rates are optimized. The new look, better user experience (UX), or improved WebVitals can result in moving on to the next step for the replatforming. Of course, the risk is that management. must understand that this UI they were presented with after the proof phase is not production ready despite it looking like it was. It still requires a significant amount of time for the actual implementation and QA.

Integrations are risky

Another typical idea for PoC is to pick one or two integrations like, for example, with headless-CMS, enterprise search, etc., that are vital for the business and show how they’re better off with Spartacus. I’ve seen a few projects start with integrations proving the whole architecture. The front end became the unified front-end layer and the glue for the best-of-breed services to integrate with. Proving the most risky part of the project takes away a significant amount of stress at the later stages.

Check the open-source tooling

To get your PoC up and running, you can set up the trials for the other tools required, like the search or CMS. However, you might want to start with some open-source components as well. You can find a few good options, like Strapi CMS and Rocket chat, on our blog in part 1 and part 2 of our article about it.

A/B testing

Another idea for the PoC with Spartacus is to implement just a particular page, with a unique URL, or as described above. Include the particular UI component rendered from Spartacus into legacy pages. Because the components are integrated on the JS level, you can easily leverage tools like Website Optimizer or even create a short JS snippet to implement A/B testing.

With an A/B testing strategy, you might want to put some actual traffic on the site. That’s contradictory to the common wisdom of not putting PoC on production. While it’s generally true, there are some exceptions. One exception is to have a very well defined, very granular piece of the site you’d like to test and enough time to do all the QA.

Go with a lean process

A hackathon works great for PoCs because it creates a tremendous amount of energy. If two days aren’t enough, then you should definitely think about a lean process. 

I’ve talked extensively just about this with Gordon Lucas, the Chief Digital Officer of Costa Coffee. An episode of the CTO-CTO podcast featuring Gordon will be released in July.

To rephrase what Gordon said, they’re using hackathons at the heart of theirR&D process. By doing this, they gave a chance to the Open Loyalty platform for building the loyalty and 360-degree customer-view platform. The team just picked it up from Github over an internal hackathon. By the way, they also feel like the hackathons are energizing their team a lot.

Any kind of structuralization, siloes, multi-phase design, and acceptance project is going to derail the PoC. It should be smart, quick, and have an ultra-short decision-making process. 

Think of it as a startup. It should have an owner who’s a bridge between business and technology and who understands the specifics of those two spaces.  

Scoping Session

Before getting the greenlight for the PoC, establish the proper goals and scope. If it’s possible, have the endgame in mind by trying to set up the budget and scope for the final project. This is in case the PoC went so well you just need to quickly push for the approval of the end-to-end project. A Scoping Session workshop can help a lot. 

Contact us and schedule a free Scoping Session workshop >

Published May 20, 2021