SAP Spartacus 2


Published on 6/2/2021

Mirek Bartnik


If you are running a SAP Commerce Cloud platform you must have already come across Spartacus - SAP’s new, modern shop storefront. Modern reactive and progressive web applications are spreading across the world and your commerce platform needs to keep up with the pace.

What is the best way to proceed with the transition to those modern frontend paradigms?

In this article series we provide strategical, technical and practical information about SAP Spartacus derived from 12 years of our 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
Does Spartacus fit into your technological strategy?
Is Spartacus a worthy part of your SAP Product Portfolio?
How does the open source concept of Spartacus impact customers?
Is this a good first step in the process of modernization of your SAP Commerce Platform?
Is it inevitable to move to Spartacus? What is the time frame?
How does Spartacus match with SAP Commerce Cloud (CCV2)?

Does Spartacus fit into your technological strategy?

Spartacus is a good fit for organizations that build their technological stack around SAP product portfolio.

If you are running SAP Commerce with one of the Accelerators it is only a question of time before you have to replace the legacy frontend with a modern solution. Spartacus should be part of your plan A when you arrive at this point.

However, there is one important aspect that you may want to consider.

Committing fully to SAP product portfolio increases your vendor lock-in. This effect is no different for SAP Spartacus despite its unique characteristics compared with other SAP offerings. Therefore, if your long-term strategy is to stick to SAP as the only vendor for significant modules, there are no reasons to worry.

Many organizations are currently transitioning to a more open concept though - an architecture which integrates various cloud-hosted SaaS backends. It builds a unique and tailored platform perfectly matching organization's needs - an approach which is referred to as Composable Commerce.

The nature of commerce systems is very different from other business areas where standard software, like SAP, may be the perfect fit for years and vendor lock-in is considered just a minor issue. Firstly, commerce processes and functionality are built individually to address your organizations specifics and new business models which distinguishes them from other areas like ERP, CRM, etc. Secondly, it moves forward in such an astounding pace that here is no guarantee that any standard software of today will fulfil your expectations of tomorrow. Thus, strategically we consider the problem of vendor lock-in in commerce very significant.

In the first part of the series we have discussed why Spartacus is not facilitating the transition to composable commerce. On the contrary - it increases your bindings to only one, although highly trustworthy, vendor.

Is Spartacus a worthy part of your SAP Product Portfolio?

If you already run a SAP Commerce system in one of the recent versions there is no doubt that SAP Spartacus will be easy to integrate. Overall effort depends on the amount of customisations but a mature SAP Commerce backend with established processes will make for a perfect base of Spartacus introduction.

Moreover, Spartacus not only guarantees to run well with any current SAP Commerce backend but also allows you to rely on SAP making it work smoothly with its future products based on Kyma and Extension Factory.

It’s possible that in the future SAP might go for building more integrations of its other modules into Spartacus and, thus, creating a whole environment of well integrated products with Spartacus acting as a commerce facade for customers masking the complexity of the underlying processes. Such compound platform would effectively reproduce the capabilities of composable commerce; however, only in the realm of one vendor and without its core idea of openness for other SaaS products.

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

How does the open source concept of Spartacus impact customers?

Spartacus is different from other SAP modules as it is an open source project. We see this as a positive change since, thanks to this model, Spartacus is able to

  • engage broader community

  • achieve faster release cycles

  • involve customers in its development

  • and, thus, establish a more natural market fit

SAP module being hosted on Github as an open source project must be perceived as a novelty for many organizations though. Therefore it requires some additional considerations on how this aspect affects your tech strategy. They are not really Spartacus' weakness but aspects you might want to account for in your planning.

It’s fair to expect that:

  • product support provided by SAP for Spartacus will be dlievered in a whole new manner

  • keeping up to speed with Spartacus development will require some development resources as we expect frequent releases of new features

  • a vivid community may create additional value, for instance, as third party plugins that you can use to speed up your platform’s development

  • knowledge resources will be similar to other open-source projects and developers will love them

  • you might even get a platform to exchange your experiences directly with other users

We don’t know the exact strategy of SAP with regard to open source but we certainly welcome this first important step. Kudos and looking forward to seeing more and more modules released in this model following Spartacus successfully paving the way for them.

Is this a good first step in the process of modernization of your SAP Commerce Platform?

Spartacus is all about decoupling frontend from backend and replacing a bunch of old technologies in your storefront with modern customer-friendly alternatives. Angular comes in place of legacy SpringMVC and JSPs while REST API, placed between frontend and backend services, breaks up the massive monolithic structure for the first time.

These important changes constitute a significant modernization of the platform opening up a possibility to truly enter the new customer experience era by implementing progressive web application to fully satisfy all sorts of clients' expectations. That’s on the frontend side at least.

So far, however, Spartacus uses Omni Commerce Connect (OCC) REST API to connect with the monolithic backend so the majority of your code will still stay in the old commerce suite. We expect SAP to follow suit with support for Extension Factory as well as release backend microservices which will take over some of the monolith's responsibilities.

Such move would allow for further architectural modernization of your platform. However, it is not clear when this will occur and, considering the history of YaaS, we have to be very cautions whether this will bring the expected success. We recommend to keep your fingers crossed and wait with investments in this area.

To sum up, Spartacus truly is an important first step in the modernization of any mature SAP Commerce platform.

Is it inevitable to move to Spartacus? What is the time frame?

SAP usually shows a very customer-friendly approach when it comes to using old versions of the software. We don’t expect this to change regarding accelerators and you won’t be forced to move away from them any time in the foreseeable future. Especially that accelerator code is owned by you and there is no real SAP support involved.

However, there is one aspect that may play a role here.

SAP is strongly pushing to migrate their customers to the cloud offering called SAP Commerce Cloud (CCV2). And, although there is no direct technical dependency, SAP is usually trying to sell CCV2 in one package with Spartacus. We do not expect this push to loose its strength so get ready to be approached by SAP with Commerce Cloud and Spartacus very soon. If you haven’t been contacted already, that is.

From the customer experience perspective we consider a move to a decoupled Javascript-based frontend inevitable. The value this change can create simply cannot be disregarded.

But SAP Commerce platforms, deployed for various customers, differ hugely in terms of their target user groups, significance for organization and other relevant factors so, for many of them, putting a new frontend won’t be a at the top of their priorities list. Accelerators are, thus, at least in some customer’s installations, likely to stay around for another 5-8 years.

It is now estimated that Spartacus needs about two years to achieve functional parity with Accelerators so one can expect that, round about that time, Accelerators will lose significance and slowly (and possibly silently) disappear from the offering.

How does Spartacus match with SAP Commerce Cloud (CCV2)?

CCV2 stands for Cloud Commerce Version 2. It is SAP’s new way of marketing and operating the Commerce platform in their own azure cloud. SAP has already rebranded itself to a “cloud company” some time ago and now works consequently on transferring all on-premise customers to CCV2.

In case of CCV2 hosting one would expect that Spartacus is deployed into SAP’s cloud as an independent application. As we discussed in the first part, one of the biggest advantages of a decoupled frontend is the fact that the PWA may be developed independently of a backend. Thus, it may also be released more often utilizing a different pipeline. It makes a lot of sense since the frontend changes are much more frequent and less at risk to break the system than the updates of the backend.

Therefore, it is highly disappointing that at the time of writing this article (May 2021) such independent frontend deployment is still not possible with Spartacus and CCV2. You cannot benefit from independent pipelines.

In order to deploy a new version of your Spartacus-based frontend you will also have to deploy the whole backend. The operation, which shouldn’t need more than a few minutes to complete, may require an hour.

But even more problematic is the fact that, due to the use of common repository, it is difficult to make sure that only frontend is frequently deployed while backends undergo more thorough testing and follow more conservative release cycle.

Of course, this shortcoming is related more to SAP Cloud limitations and not to the Spartacus framework itself. However, as both products are often offered together we wouldn’t expect such issues. We will be happy to update you when this problem is removed.

Mirek Bartnik (frame)
Mirek Bartnik (frame)
Let's talk

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.


Be prepared for your transition
to composable commerce.

Carefree and smooth



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