What Does History Tell Us About The Upgrade Potential Of The Pending SAP Commerce Cloud v2005 Release? — Part 1

(!) (!) May 19, 2020 Update: This article was extended in “Part 2” in which the findings above were refreshed in context of the recent SAP Commerce Cloud (Hybris) v2005 release.

Myles Bunbury, P.Eng., SAP Customer Experience (including Hybris) Competency Center Head, EPAM

It has been nearly a year since the last “major” SAP Commerce Cloud (Hybris) release of v1905. While nothing is official until it is official, this month I am expecting SAP to release SAP Commerce Cloud v2005. This release is likely to incorporate many of the cloud extension packs released (only) for “public cloud”/CCv2 hosted solutions, add support for B2B flavours of Spartacus, improve Context-Driven Services, improve integrations with various other SAP products (CX suite, S/4HANA, or otherwise), make enhancements to SAP’s “CCv2” cloud offering, as well as various other bells and whistles.

In this context, every SAP Commerce Cloud solution owner needs to ask themselves, “Is it time to upgrade?”

While each individual solution owner needs to answer this question for themselves based on the exact release notes of v2005 (yet to be published), to at least start framing the answer to this question, I thought it would be interesting to take a look back through history and see how previous versions of “hybris”, “SAP Hybris”, “SAP Hybris Commerce”, “SAP Commerce”, and “SAP Commerce Cloud” (henceforth simply collectively referred to as “Hybris”) had to say about the likelihood of adoption and the longevity of adoption thereafter.

The Data

In order to understand the historical uptake of new Hybris versions, I commissioned an effort to peer back through the archives and memories of EPAM to understand what clients, prospects, etc. were using what version of Hybris in any given year. Before we get to the main attraction, it’s important to understand the nature of the data set in order to interpret it fairly:

• This data set reflects EPAM’s exposure to the broader Hybris market over time. Therefore, it may have inherent biases in it simply due to the nature of the solutions (e.g. scope, scale, B2C vs. B2B, geographies covered, headless, microservices, etc.) and the types of clients (e.g. industry, size) EPAM typically engages with for e-commerce work.
• EPAM’s history with Hybris started around 2012. Ergo, data before that is not available.
• More recent data was found to be more available and reliable than older data.
• The data set encompasses growth and change in EPAM’s Hybris client base. Over time, the size, makeup, and types of engagements (greenfield, takeover, audit, tuning, sustaining, etc.) potentially changed. New client logos were added or removed to the data set as e-commerce work was won and completed respectively.
• Upgrades are not always a black and white thing. Some companies always want to be “bleeding edge” and therefore upgrade multiple times per year. In such situations, all versions that went live are credited with being active in that given year.
• This data set and accompanying analysis do not factor in on-premise vs. CCv1 (SAP private cloud) vs. CCv2 (public/Azure cloud) hosting.

 

Any Guesses?

Now that I have given you insights into how the data was collected and processed, do you have any expectations as to what the data might reveal? Most of us who have been in the Hybris ecosystem for a while have a “feel” for how version-to-version upgrades of Hybris go, the cadence that various companies go through with respect to deciding if/when to upgrade, etc.

Before continuing, take a moment to write down what you think the data “should” reveal, and then see how it matches up with your expectations once you’ve read on.

 

The Main Attraction

Enough of the suspense. Let’s take a look at the graph that we’ll be talking through for the remainder of the article:

In the graph above, you will find Hybris versions from v4.7 through to v1905 plotted over time (calendar years). Each colour band represents the percentage (share) of the solutions in the data set that were using that particular version of Hybris in a given year. Through this “stacked” graph, you can also easily sum up various bands to answer questions like, “What percentage of solutions were using version X or greater/newer?

 

Word of Caution

I warned earlier about the need to understand the underlying data before jumping to conclusions. In part to emphasis this point and in part simply to demonstrate the analysis approach to more interesting insights yet to come, take a look at 2012 below:

What is the data telling us here? Are we to truly believe that 100% of Hybris users were on v4.7 in 2012? Seems fishy, doesn’t it?

It should seem fishy to you. If you defer back to my points around the underlying data set, 2012 was a looooooooonnnnnggggg time ago. Tracking down accurate information about this time period (people directly on the projects, old documentation, etc.) proved challenging & time consuming, so mostly what’s reflected here is merely an absence of data.

More interestingly though, for those “ancient” enough like myself to have been around in the Hybris v4.x timeframe, you will recall that v4.7 was one of the few (only?) “recalled” versions of Hybris that was put out. Hybris (pre-SAP acquisition) put out a statement at the time that v4.7 should be avoided and companies/system integrators should either stick with the v4.6 predecessor or immediately upgrade to the newer (at the time) fast-follow v4.8 release. And, in fact, we see just that – after a brief appearance in 2012, v4.7 is gone in 2013 and never to be seen again. (Some data showed an upgrade from v4.7 that bled into 2013 before going live, which is why it shows in the graph as a non-0% number, per the early explanation about the underlying data set.)

 

Toboggan Hills & Rollercoasters

When I first graphed the data set, the immediate thing that popped out to me was the “toboggan hill” pattern that emerged from the data set, as generically illustrated by the red arrows below:

Applying the exact same data to a different style of graph showcases this trend even better, though here it appears more as a “rollercoaster”, with steep climbs to the top and a steep descents thereafter:

For most versions, the adoption, sustaining, and retirement of a given version follows a distinct, 3-part curve:

1. Adoption typically occurs over a period of one to two years
2. There is a brief peak, usually lasting only a year
3. Typically, a sharp fall off in the succeeding year

What drives this pattern?

Plotting those dates onto our version graph reveals the following:

From this we can see that, generally speaking, there is immediate adoption of a given version the year it is released. This makes sense, as greenfield implementations typically start on the newest version of Hybris. For companies looking to migrate to this version however, there is often a lag time in terms of getting budgets approved, getting the upgrade effort sequenced in the broader scope of Hybris solution enhancement work, and then starting the actual implementation itself. That is why for a little less than half of the versions graphed above, the year after a given version is released you see the maximum extent of its adoption. (ie. Thickest part of the band.)

It should also be noted that the exact timing within the year have a notable impact this graphic as well. Versions released in Q1 of a given year are more likely to see adoption within that same year than versions released in Q4.

 

Does the SAP support lifecycle drive upgrades?

One of the most often cited reasons for companies to upgrade to a newer version of Hybris is to remain within the (typically 2 year) support cycle that SAP offers for released versions of Hybris. This makes sense – solutions should be constantly patched against known security vulnerabilities and platform bugs that could impact the customer experience should be addressed to avoid lost sales. New features, especially productivity enhancements to the backoffice, should be realized. The question is, just because companies “should” upgrade, do they?

At the time of this writing, only v6.7 and greater are supported by SAP, and even there, SAP’s support for v6.7 is scheduled to end on August 8^th, 2020 and SAP’s support for v1808 is schedule to end on December 12^th, 2020. (See full lifecycle dates per version from SAP listed in Appendix A.) What does the data say about migration off of versions v6.6 and earlier?

Similar to what I did for the adoption curve, I’ve enhanced the graphic below to show end of life dates overlaid over the data set. The white dotted line showcases what versions are out of support in any given year. The grey dotted line further showcases versions that are not yet out of support but will be by the end of this year (2020).

Here we can see that end of life / SAP support termination does indeed influence version upgrades. For the versions highlighted, there is a general trend from “lots” to “some” or from “some” to “none”. Companies therefore see value and appreciate the knowledge of knowing that their software vendor (SAP) has their backs regarding anything critical that might need to be brought to their attention.

It should be noted that the story of 2020 is not yet completely written. Version upgrades may well be in progress across a number of companies and are not yet represented in the data set. Presumably by the end of 2020 the trend bands would strength further as those currently in progress would have completed their upgrades.

Never Say Die

For those with eagle eyes, you picked up on the “long tail”, highlighted in the graphic below:

This “tail” represents companies that, for whatever reason, have opted to continue operating outside of the official SAP support cycle. This block of companies represents about 35% of the data set, and increases to about 45% of the data set if we also include v6.7 and v1808 which will be out of support by the end of the year. There’s also a notable inflection point after 2018, prior to which the “out of support” line runs plus or minus 20% and after which the line starts climbing notably. What’s going on here?

 

35% is a sizable number. Assuming this accurately represents the Hybris ecosystem at large (plausible), one can better appreciate SAP’s push to the cloud. One of the underlying messages from SAP is that by migrating from on-premise to the cloud, “large, expensive” upgrade programs can be avoided since SAP (in principle) will take care of that for you as they continue to invest in their cloud-based offering and move to a full SaaS based model. Ultimately, keeping everyone current is in SAP’s interests as much as the Hybris solution owners. With a customer base lagging behind the official SAP technology curve, the risk of bad press from security breaches, the risk of customizations yielding high total cost of ownership complaints from stakeholders not taking advantage of recent out-of-the-box innovations, etc. is a risk to both SAP and Hybris solution owners alike.

At the same time, one might argue that SAP’s push to migrate their Hybris customer base to the cloud is one source of the (recent) upgrade tardiness. After all, a “lift and shift” (upgrade + migration) to the cloud is by definition heavier and more disruptive than simply a “lift” (upgrade only). Ergo, this extra weight may be slowing some companies down, since they need to secure bigger funding and longer schedules within their overall IT strategy in order to achieve maximum benefit and avoid going “half way”.

On the flip side, SAP readily acknowledges that their R&D investments and innovations are being directed towards the cloud, and more or less have been since the 2018 inflection point in the “out of support” line. Well, if you are a customer that isn’t interested in migrating to cloud – maybe you don’t like the new revenue-based licence model; maybe you’re already in the cloud on your own with AWS, GCP, etc. and world class DevOps – then what’s in it for you? For sure the “sexy” features in the feature roadmap in recent years have been lighter than in the years prior, but there are still strong enhancements to things like SmartEdit to be taken advantage of. And other new features that are not cloud exclusive, like an enhanced portfolio of APIs and Spartacus as a headless storefront, still provide good reasons to upgrade. Ergo, this doesn’t seem to me like a strong reason not to upgrade – especially at the sacrifice of security patches and bug fixes. A proper upgrade strategy would be advised.

Curse of the Major Version Release?

Personally, I am not a fan of the new “yymm” version nomenclature that SAP adopted in 2018 with their v1808 release. I prefer the older “major.minor” version numbering scheme. But what about companies?

One of the things I heard from clients in my travels is that they “don’t want to be the guinea pig” and they’d rather “let someone else go first” when it comes to new versions released. There is a natural resistance amongst some (not all) to avoid the latest release.

With the exception of the aforementioned v4.7 “recalled” version, SAP has a strong track record of delivering solid releases with a high quality bar. Patch releases are typically released monthly (or sooner, if critical), so even if something slips through the cracks, it will likely be addressed before a typical upgrade effort is completed.

Those “in the biz” know that the old “major.minor” version scheme was not really so. V4.8 è v5.0 and v5.7 è v6.0 was not really any different than any other point-to-point releases. But in talking to clients over the years, that +1 to the major version number caused a great deal of concerns, and further raised the resistance to upgrading to that specific version.

Does the data support my experiences conversing with clients?

I won’t claim it’s definitive, but it seems as though there is supporting evidence to the theory at least. You will note from the graphic the thin sliver that makes up the v6.0 band. Comparatively, you find a fairly thick v5.7 band bordering the v6.0 band on one side, and a thick v6.1 and thicker v6.2 band bordering the v6.0 band on the other side. What you don’t see in the graph is that the underlying data points related to v6.0 all upgraded to v6.1 the same year – nobody went live or otherwise lingered on v6.0. The inference here is that companies with v5.x Hybris versions explicitly chose to upgrade-to-but-not-beyond v5.7 for a period of time. A few crossed to the (perceived) “safer” v6.1 but it’s v6.2 which really saw healthy adoption. Ergo, after v6.7 was released and the hypothetical (at the time) “v7.0” was looming, it seems that SAP made the right decision to switch the version numbering convention to the “mmyy” format, thereby removing the artificial barrier of resistance that the major version number caused. You’ll note that no other version band is absent or as thin post v6.0.

It’s worth calling out that the v5.0 band does show up on this graph. v5.0 behaves a little differently in part because it had the better part of a full year to establish itself. Instead of going directly to v5.1, (then) Hybris released v5.0.1 through v5.0.4 at roughly ~3 month intervals. The underlying data set does not distinguish these “more than just a patch” v5.0 sub-versions, but it’s reasonable to assume these helped to convince companies at that time that v5.0 was ready for prime time. Even then, v5.1 sees much stronger adoption in and around 2014, supporting the theory.

Reengagement

What are these strange bumps at the bottom of the graph?

 

Many companies take “pride of ownership” over their e-commerce solution. It’s a key revenue driver, so they should know how it works, right? Whether they built it themselves, had Hybris/SAP professional services build it, or a system integrator like EPAM build it, they ultimately decided that once the “foundation” was laid that they would maintain that solution in house.

What these “bumps” represent are companies that have tried to “go it alone” and realized that that was not optimal. Whether it’s due to lack of proper in-house talent, insufficient bandwidth, or weak prioritization, their e-commerce solutions have suffered and they reached out to EPAM to reinvigorate their e-commerce program.

When these situations arise, EPAM typically finds that they are far behind on the Hybris version they are running on, often out of or nearly out of support from SAP. Having realized that they are not deriving as much value from the Hybris platform as they could, they engage EPAM to get them back on track. One of the first steps is often to upgrade them to the latest version of Hybris. This leads to the “bump” effect, where we quickly get their e-commerce program back on track with the latest innovations from SAP from the latest Hybris version, and then move to addressing their underlying business concerns and wishlist that prompted their original outreach.

Hybris Loves Me; Hybris Loves Me Not

Flipping to the more “fun” analysis, what is the most loved version of Hybris? Which was the least popular?

Let’s start with versions that stand out, marked by a star in the graphic below:

In my subjective opinion, the all-time “most loved” version of Hybris appears to be… v5.7! v5.7 was the only version to maintain undisputed dominance over a 2 year period, and it also had some longevity to it in it’s “long tail”. It likely benefited from the “major version curse” of v6.x described earlier. However, let’s go through some other worthy candidates:

• 1
  • From the “ancient era”, v5.1 stands out as having a high adoption rate as well as a long tenure.
• 3
  • 3 beats out the also solidly performing v6.2 at the version of choice in 2017. It also has strong staying power, and continues to be in use today. It likely benefits from the “upgrade barrier” posed by v6.4, when the newer Product Cockpit in the backoffice was introduced.
• 7
  • 7 was one of the last versions of Hybris with notable bells and whistles to enhance the merchandizing, searchandizing, etc., backoffice experiences, with features like mass data editing, compare view, adaptive search enhancements, a newer version of Solr, SmartEdit enhacements, and promotion enginge enhancements. The value from upgrading was applicable to a large swath of stakeholders, likely making buy-in for an upgrade easier to obtain. It’s also the oldest version supported by CCv2, which makes it a potential stopping point for companies that do not want to go “all the way” in their efforts to migrate to cloud.
• v1811
  • While technically tied with v1808 in 2019 for adoption, I gave the nod to v1811 due to it’s apparent staying power. Whereas v1808 had a rapid ascent, it also had a rapid decent. v1811 in contrast went up quick and seems to be holding on.

 

What about the most unloved/unpopular version of Hybris? Here are my (subjective) picks:

V5.6 wears the least-loved crown in my books. Hard to argue with ZERO presence on the graph. V6.0 also gets a “dishonourable” mention as the version that made the graph yet came both in and out with a whimper. Like v6.0, v6.1 did not have any staying power, with both versions losing out to the more popular v6.2 and v6.3.

Have your own opinion? Feel free to leave a comment below on the greatest or worst Hybris version of all time.

 

Final Remarks

I trust this analysis has been valuable to you. While we each chart our own journey through the Hybris ecosystem, it’s always interesting to take a step back and see what greater forces are at play and what “the collective” might be doing.

Pertaining to the pending v2005 release by SAP of SAP Commerce Cloud, I hope to return with another article with commentary on the actual features of v2005 once v2005 is publicly released. In the meantime, regardless of your current situation with your own Hybris program, I would encourage you to discuss with your key stakeholders – program owners, IT owners, business owners, partners, SAP – what your upgrade strategy is. Whether you want to seize first mover advantage and go live with v2005 first, or whether you’re more of a wait and see approach, or somewhere in between, my experience from working with clients just like you shows that the best run e-commerce programs have a defined strategy and plan behind how to tackle upgrades (among other things). So if you don’t have one, it’s high time you made one.

As SAP Customer Experience Competency Center Head, I’m here to help and counsel – if you need it.

A special thanks to Viktoriia Rulova and Ksenia Kolkova who helped prepare the underlying data set that made this article possible.

Appendix A – Release Version General Availability & End Of Life

Per https://help.sap.com/viewer/dc198ac31ba24dce96149c8480be955f/1905/en-US/1c6c687ad0ed4964bb43d409818d23a2.html?q=supported%20versions.

(!) (!) May 19, 2020 Update: This article was extended in “Part 2” in which the findings above were refreshed in context of the recent SAP Commerce Cloud (Hybris) v2005 release.