SAP Spartacus 3

// SAP SPARTACUS GUIDE PART 3. WHY A MIGRATION TO SAP SPARTACUS IS NOT AN UPGRADE OF ACCELERATORS?

Published on 6/23/2021


Mirek Bartnik

Mirosław Bartnik, CHIEF TECHNOLOGY OFFICER


Spartacus - SAP’s new, modern shop storefront. You probably already know it if you are using SAP Commerce Cloud platform. Your commerce platform needs to keep up with modern reactive and progressive web applications spreading across the world. What's the best way to go about those modern frontend paradigms?

In our series of articles we provide strategical, technical and practical information about SAP Spartacus based on 12 years of experience with SAP Commerce Cloud, completed Spartacus implementation projects and work done on alternative storefronts. The 5 parts of the series consist of discussions over general issues, strategical details, technology and delivery aspects and our overall assessment to help you craft your architectural strategy.

Read below about
How do you switch from accelerators to Spartacus?
What is the effort of switch to Spartacus?
What competences are required to work on Spartacus??
How to kick off a typical Spartacus introduction project?
What sources of information on Spartacus are available for the team?
How versioning and upgrading impacts Spartacus project?
How straightforward is it to upgrade your Spartacus to a new version?

How do you switch from accelerators to Spartacus?

There is no easy path from your legacy Accelerator storefront to the new shiny Spartacus PWA. Setting up Spartacus for your project is not a migration and there are no tools to support the process. On the contrary, you have to think of it as a new development where you start with a solid but fairly standard template which, from day one, is a working frontend. Your journey of building and adding custom features, extensions etc. starts from there.

The level of reuse of your legacy frontend application is extremely limited - not even CSS stylesheets or some custom JS code can easily be transferred to the new project. We recommend not attempt it in the first place. It won’t bring relevant effort reduction while it will impact the clarity and organization of the final code.

Still, the new storefront will be based on your solid and battle-tested backend processes. They need to be exposed through APIs and, if the processes are custom, you will need to create suitable endpoints. This isn’t actually any different whether you go with Spartacus or another frontend solution. A decomposed frontend will always rely on a set of well defined backend APIs.

Interested in maximizing your output? Find out more about our SAP Commerce Delivery

What is the effort of switch to Spartacus?

As already mentioned implementing Spartacus must be considered a new scratch-project. The standard scope of functionality is working fully right away but you will need much more than this to cover your particular business needs. The total effort of Spartacus introduction will strongly depend on those customizations and, thus, it is difficult to predict the amount of it needed. However, our practical experience shows that a real customer project takes about 3 to 12 months.

We recommend that you plan in stages and apply radical MVP approach in order to keep the first iteration as small as possible. This approach provides the team with time to learn and improve their ability to make use of the product’s standard features and architecture. The more the team understands about Spartacus the higher the chance of leveraging product’s capabilities perfectly, the lower the amount of customizations and total effort.

What competences are required to work on Spartacus?

Developing with Spartacus is quite different from other SAP Commerce related work. While in backends and in Accelerators Java and Spring were the predominant technologies, this is not the case for Spartacus. It is essential here that the team has deep practical knowledge of modern JS frameworks like Angular 10 / 11, languages like JavaScript and TypeScript as well as some associated technologies such as node.js or yarn.

While it is possible to train Java Developers in TypeScript and Angular - as both of the technologies are easy to grasp if you come from Java background - it poses a significant project risk to rely solely on your old team that learns new technologies on the go. This Spartacus storefront is supposed to stay around for years and impress through customer experience and architectural quality. You don’t want to start with technical debt on day one.

Familiarity with PWA applications and their unique characteristics such as offline mode, handling data store, service workers etc. is also of great value. As is experience in both API consumption and design as there is always a need to provide some additional custom services.

How to kick off a typical Spartacus introduction project?

It’s a good idea to plan an upgrade of your SAP Commerce platform before even looking into Spartacus. Its features usually require a relatively new version of the backend as they introduce APIs the frontend relies upon. Therefore it is very likely that an upgrade will be necessary and, as this activity might need some time to complete, it’s worth to kick it off right away.

In parallel, one should perform a detailed assessment of the functionality available out of the box and compare it with the expected scope by looking at their current Accelerator status quo. Of course, you shouldn’t stop here merely trying to rebuild the Accelerators with a new framework. Spartacus has much more to offer and it makes sense to get used to its unique features. The ones that let you push customer experience forward particularly deserve to be included in the MVP scope.

This activity results in a detailed gap analysis which can be then turned into a list of functions to be developed. It usually entails a lot of work on the visual side and we recommend to stay close to the standard and have UI/UX people work hand-in-hand with developers. Besides, whole new pages and components often have to be built as well as backend APIs as the standard OCC is rarely sufficient. Fortunately, backend and frontend work may be split and handled by separate sub-teams thanks to clear isolation provided by the API layer.

What sources of information on Spartacus are available for the team?

Main Spartacus documentation can be found in the Gitlab project: Spartacus Documentation. It’s decent and up to date. Some links lead to areas requiring “open SAP” login but you will find abundance of information in Gitlab that will help you get started.

Source code is available in Gitlab under SAP/spartacus. You can look into various branches, monitor pull requests and reported issues. The community seems quite active.

The documentation states that StackOverflow should be used for technical questions. You can find those here: Newest 'spartacus-storefront' Questions. The community asks 2-3 questions daily and usually receives helpful answers.

Non-technical questions are discussed in the Slack channel but the future of this way of communicating is not clear. Since January 2021 the Spartacus team does not answer technical questions via Slack any more and there are rumours that it might be turned off one day.

Besides those communication ways, typical to open source, we need to remember that Spartacus is in the end a SAP project and the company has to provide support to customers with respective SAP Commerce licenses. This is indeed available via their “SAP One Support” portal but we cannot say much about this service.

How versioning and upgrading impacts Spartacus project?

Spartacus follows the proven major.minor.patch versioning scheme. At the time of writing this the current version is 3.4.0 released on the 16th of June 2021. According to the Spartacus team new major versions are expected to be released roughly every 6 months, minor versions every 6 weeks and patches as needed, possibly even weekly.

Spartacus claims to be fully upgradeable and that’s one of the main differentiators to Accelerators. Upgrading may, however, turn from an option to a necessity since there is no explicit guarantee that older version will contain important bug fixes. Officially the Spartacus team only supports the most recent release so if you want to apply an important patch, you might end up having to upgrade to a newer major or minor version.

Furthermore, Spartacus upgrade may require a particular (most often the current) version of SAP Commerce backend. That’s, at least, if you want to use some of the newer features of the frontend. It still remains to be seen whether those dependencies will one day result in the whole chain of upgrades of multiple system components just to implement a relevant bug fix or a security patch.

However, we expect the Spartacus team to introduce some long-time support for particular versions once the adoption of the product increases. Time will tell.

How straightforward is it to upgrade your Spartacus to a new version?

One of the potential key advantages of Spartacus over Accelerators is its ability to upgrade to newer versions. Since it’s delivered as a “library” and not as a “template“, it is claimed to be easy to upgrade. However, our experience shows that while it glitters, it’s not all gold.

Let's consider a few important points here.

  • Upgrading libraries does not make your views magically use the new versions right away. And, as Spartacus does not guarantee backwards compatibility, your customizations might rely on functionality that changed in the newer version of Spartacus core which forces you to adapt your code on your own. While there is a mechanism of feature levels and feature flags which should facilitate the use of older minor versions within the same major version, so far we can’t confirm that this mechanism is consequently applied for all features though.

  • Upgrade is, thus, another project of some (but possibly limited) complexity. If you want to avoid risks in this area, follow our recommendation of reducing the scope of customizations as much as possible.

  • Upgrade to a new Spartacus version may force you to use a new version of the backend so you might end up in a much larger exercise than initially expected. Maintaining the ability to upgrade forces you to stay current on the SAP Commerce version.

  • Spartacus is still growing and new features might mime your customizations. Thus, you will face the question whether to stay with your custom or migrate to the standard solution in this particular area. We advocate the use of as much standard as possible as this makes the platform future-proof. It’s fair to expect that the more upgrade-related effort the earlier you jump on the Spartacus train.

On the final positive note - our experience shows that putting up a patch version on a project has proven to be unproblematic in all cases.

CHECK OUT OUR WHITE PAPERS

Be prepared for your transition
to composable commerce.

Carefree and smooth

GO TO OUR BLOG

OUR CLIENTS

Ivoclar Vivadent
TUI Logo
Nikon logo
TX Group logo
Play Logo
Vision Express Logo
GrandVison Logo
Trendy Opticians Logo

How can we help?

Talk to Mirosław Bartnik, our CHIEF TECHNOLOGY OFFICER

If you’re in doubt whether Spartacus is your best or only option, we can help. Our team has 12+ years of experience in working with SAP Hybris. We have a unique knowledge of decomposing frontends and backends for SAP Commerce customers.
This includes successful takeover of launched projects that other agencies failed.

We demonstrated the quality of our work in numerous successful projects for customers with revenues of 500M to over 1B EUR where commerce is the key to generating sales.
We can help. Drop me a line.

Thank you for the message. I will contact you within one business day.
This site uses cookies and other tracking technologies to improve user experience. For details please see our PRIVACY POLICY