Being at Crossroads, Take a Perspective View

I often interview strong Java developers who were offered a move to SAP Commerce. What I see regularly is uncertainty and sometimes reluctance to learn SAP Commerce.

Some say they believe they won’t be able to use the knowledge and experience anywhere else in their careers.

Some of them see this move as ‘boxing’ themselves in. 

It is generally believed that focusing on the niche product may cause taking a lot of time in the future to get re-trained for a different product or technology if the current market conditions change and SAP Commerce will fade in relevance and popularity. Proprietary platforms come and go, and developers feel afraid to find themselves with useless knowledge and meaningless experience. 

Even though I generally share the view and arguments above, I also believe that SAP Commerce is a special case. What I want to leave you, then, is with the explanation of why I think so. 

One commonly held misconception is that SAP Commerce is a niche solution which for devs means proprietary hell. Yes, it is proprietary, but neither hybris, not SAP (after acquiring hybris) added any new concepts to the way how platforms are built. I assure you, 90% of the platform doesn’t have anything SAP-ish. 

Under the hood, SAP Commerce is a huge collection of ready or template solutions for a wide range of e-commerce needs. Almost all of these solutions are open for anyone to explore and tinker with. Many components, such as Solr, Drools, and Spring are actually open-source. If you know Java Spring and Solr, you can divide your ramp-up time by two. 

Claude Adrien Helvétius, a French philosopher, once said that awareness of some principles easily compensates the lack of knowledge of certain facts. Of course, you can’t learn the principles apart from learning from their concrete implementation. However, working with good implementations of the common concepts will help you to be an expert in the knowledge area rather than in a particular product. 

For example, SAP Commerce Search Module is a big piece of the platform and one of the most used in almost all projects. The architects of SAP Commerce just took Apache Solr and added a new layer on top of it – the topics which Apache Solr out-of-the-box doesn’t cover well. For instance, you can create a category-aware profile that defines facets and boosts certain results within a specified product category. SAP Commerce allows you to tweak Solr from the backoffice while Solr OOTB provides only file-based and API interfaces for configurations. Solr search is also adopted by Websphere Commerce, Magento, SiteCore, Episerver. And all of them have the same challenge: enriching the Solr’s out-of-the-box low-level interfaces with slicky and powerful management capabilities as well as tailor it for needs specific for their content. 

The underlying concepts are more or less the same in all e-commerce platforms, and probably in all e-commerce websites. Once you learn them by example of SAP Commerce, you will be able to master other platforms faster. For example, the concepts of Facet Search (Facet Search: The Most Comprehensive Guide) and base promotion mechanics (Promotion Mechanics and their implementation in hybris 6.x) are supported by many platforms, very similarly to how they are implemented in SAP Commerce.

However, many custom solutions address only a particular case relevant to their business. On the contrary, the platform solutions have a foundation and template implementations for a wider set of cases, and you can pick the best for your business. Such a design helps to get a broader vision of possible options and solutions. For example, you can group the products in the search results differently (combining product variants – see my Variant Product Modeling) and Search Module supports this functionality.   

Let’s take a cornerstone concept of any e-commerce website, a shopping cart. Basically it is just a list of items associated with a customer session, right? However, things get tricky when it comes to supporting both anonymous and authenticated shopping carts and checkout. For that, there are different strategies of how to combine cart items so a customer won’t lose the selected items when logging in from multiple devices or across multiple sessions (see my Merging Carts article). A solution for a grocery store with its large shopping carts might be different than one for a dealership website. Things are becoming even more trickier when it comes to configurable products and add-on product services with promotions on top of them. What SAP Commerce gives to you is the awareness that there are corner cases and there are standard solutions for such cases. Of course, it also equips you with a reference implementation of the shopping cart service where such cases are taken into account. 

This knowledge is equally important for any e-commerce specialist, whether they be a developer, solution architect, business analyst, or product owner. It helps the team to speak the same language. 

Beyond the e-commerce layer, this also applies to overlying and underlying tiers. Multi-level caching, database abstraction, and data access mechanism. This stuff is used in almost all large solutions, and understanding the best practices “by example” is always a big advantage.  

It will take years to learn how the platform is built and how the typical tasks are addressed. With frequent updates, it is hard to keep everything tracked and understand every corner of the platform in detail. However, you will find your ways of packing this information in your brain efficiently. No need to remember everything in detail. Mapping implementation to known concepts helps organize facts and ideas into a system of understanding. If you feel you can’t extract an abstract concept from the concrete implementation, ask those who know.  

Even though the code is proprietary, these abstract concepts are open and generic. Understanding them contributes to your career and finally a paycheck to a much greater extent than understanding concrete implementation. 

It is believed that 10,000 hours of practice can turn you into an expert. For the developers, 80% of these 10K hours are hours spent in debugging. Every time you find yourself debugging the code, every time you set breakpoints in the platform classes, you increment that counter. Writing code is not so efficient. For example, the documentation says you need to add a fragment to the XML file and magic will happen. There are hundreds on Earth who limit themselves with the skill of writing code exactly as the documentation says. The complexity starts when it is not working as it should. This is where many junior developers give up. Troubleshooting contributes to your skillset and experience to a much greater degree. If you have choices, don’t miss a chance to get yourself challenged with bug fixing and troubleshooting.  

Yes, some think that the main challenge is blackboxiness. That’s not entirely true. Indeed, SAP is still not willing to give access to the source code for developers. Access to the installation package is still restricted for partners only. However, accessing the code behind the compiled classes has never been an issue. Our IDE’s decompilers do the work.. However, SAP still maintains that making the source code fully available is not possible for security reasons. It is common for vendors to fear that one would make use of the source code to find weaknesses. Guys, we have been looking at your code for many years! So, the source code is already available for public inspection. There are no non-decompilable components. SAP Commerce has never been a black box. 

In fact, I have been observing how SAP moves away from the closed community to open source. Spartacus, a javascript storefront, is available for anyone. Github is full of extensions for SAP Commerce. They often go together with the platform code. Installing and running SAP Commerce on the local machine is simple and straightforward (If you ever tried to install Magento on the local machine, you will understand why I emphasize this point). The documentation is now public. The trend for openness is now the norm to be successful. 

Now that we’re through here, let’s imagine what could happen if SAP decides to sunset SAP Commerce one day. It is abundantly clear that such an event must be preceded by a period of loss of the vendor’s attention to the product rather than a period of intensive investments. However, history is strewn with various examples of the rapid decline in market share. We have witnessed a fall of once-powerful Nokia, Motorola, BlackBerry, HTC, and Blackberry. Windows Mobile has lost nearly a third of its smartphone market share since 2008. Have you heard of any of the Windows CE developers begging for money or support from the government? The answer is simple: any technology is tightly connected with neighboring ones. One step aside and you are in the market where almost everything is the same. Even if things go south and all existing companies will decide to step away from SAP Commerce, skilled architects and developers will be worth their experience in gold for years after it happens. 

Of course, I personally have good reasons for optimism. SAP is actively investing in SAP Commerce and CX portfolio. There are no signs of it slowing down. Of course, the e-commerce platform market is getting to become more competitive, and it is getting harder and harder to keep their leadership badge. Just because it is no longer a black and white world. There are niche solutions for specific cases. Online auctions and service subscriptions are to be built differently than online groceries and online ticket offices. It is not possible to create a big universal platform that would be the best fit for everything. Scarcity helped with the choice in the past, but now we are facing “embarrassment of riches”. That is why it is very important to learn how concepts work by examples of concrete implementations. 

My experience with Hybris started in Teamidea, an SAP partner looking for new areas and products to complement their strong SAP solution practice.  I was offered to head the e-commerce department and build the hybris practice from scratch. At that time, nobody knew what Hybris was. In Russia, if it comes to a foundation for a website, there were only two options: 1) in-house custom development from scratch and 2) leveraging Bitrix as a platform. In Teamidea, we took a risk to add a third option and bring a big platform solution to Russia. At the interview, Vasily, CEO of Teamidea, offered me to take it on. I had the same doubts as many of you, and before accepting the offer, I asked to join the team and look closer to what Hybris is. The main question was to what degree this solution is and will remain a black box for us. My fears disappeared after the first day. It was just a Java app, with decompilable code, with understandable database structure and extensibility capabilities. The key argument for me to take the decision and accept the offer was ‘It is not a black box but a well-documented and well-built piece designed and developed in Germany’. 

Appendix. The diagram below shows the technologies and concepts constituting what should you know to be part of the development team. The concepts, products, and proprietary stuff are color-coded. 

What else discourages developers from investing time in a new area? Share your thoughts.