I often interview strong Java developers who have been 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 a niche product may require a lot of time in the future to retrain for a different product or technology if market conditions change and SAP Commerce fades in relevance and popularity. Proprietary platforms come and go, and developers are afraid of finding 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 with, then, is an explanation of why I think so.
One commonly held misconception is that SAP Commerce is a niche solution, which for developers means proprietary hell. Yes, it is proprietary, but neither hybris nor SAP (after acquiring hybris) added any new concepts to the way 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-made 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 cut your ramp-up time in half.
Claude Adrien Helvétius, a French philosopher, once said that awareness of some principles easily compensates for a 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 common concepts will help you become an expert in the knowledge area rather than in a particular product.
For example, the 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 that 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 Backoffice, while Solr OOTB provides only file-based and API interfaces for configurations. Solr search is also adopted by WebSphere Commerce, Magento, Sitecore, and Episerver. And all of them have the same challenge: enriching Solr’s out-of-the-box low-level interfaces with slick and powerful management capabilities, as well as tailoring it for needs specific to 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 the 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, 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 you get a broader vision of possible options and solutions. For example, you can group products in the search results differently (combining product variants — see my Variant Product Modeling), and the 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 for combining 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 from one for a dealership website. Things become even trickier when it comes to configurable products and add-on product services with promotions on top of them. What SAP Commerce gives you is the awareness that there are corner cases and 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 are a developer, solution architect, business analyst, or product owner. It helps the team 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 mechanisms. This stuff is used in almost all large solutions, and understanding best practices “by example” is always a big advantage.
It will take years to learn how the platform is built and how typical tasks are addressed. With frequent updates, it is hard to keep track of everything and understand every corner of the platform in detail. However, you will find ways to pack this information in your brain efficiently. There is 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 ultimately your paycheck, to a much greater extent than understanding a concrete implementation.
It is believed that 10,000 hours of practice can turn you into an expert. For developers, 80% of these 10K hours are hours spent 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 as efficient. For example, the documentation says you need to add a fragment to the XML file and magic will happen. There are hundreds of developers on Earth who limit themselves to 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 challenge yourself with bug fixing and troubleshooting.
Yes, some think that the main challenge is black-boxiness. That’s not entirely true. Indeed, SAP is still not willing to give developers access to the source code. Access to the installation package is still restricted to partners only. However, accessing the code behind the compiled classes has never been an issue. Our IDEs’ 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 someone would use 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 a closed community toward 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 a local machine is simple and straightforward. If you have ever tried to install Magento on a local machine, you will understand why I emphasize this point. The documentation is now public. The trend toward openness is now the norm for being 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 investment. However, history is strewn with various examples of rapid declines in market share. We have witnessed the 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 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 a market where almost everything is the same. Even if things go south and all existing companies 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 the CX portfolio. There are no signs of it slowing down. Of course, the e-commerce platform market is becoming more competitive, and it is getting harder and harder to keep the leadership badge. This is 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 from 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 choice in the past, but now we are facing an “embarrassment of riches.” That is why it is very important to learn how concepts work through examples of concrete implementations.
My experience with Hybris started at Teamidea, an SAP partner looking for new areas and products to complement its strong SAP solution practice. I was offered the opportunity to head the e-commerce department and build the hybris practice from scratch. At that time, nobody knew what Hybris was. In Russia, when it came 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. At Teamidea, we took a risk by adding a third option and bringing a big platform solution to Russia. At the interview, Vasily, CEO of Teamidea, offered me the opportunity 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 more closely at what Hybris was. The main question was to what degree this solution was and would remain a black box for us. My fears disappeared after the first day. It was just a Java app, with decompilable code, an understandable database structure, and extensibility capabilities. The key argument for me in making the decision and accepting 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 that constitute what you should 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.