SAP C4/HANA (Former Hybris) Suite
by Mariusz Święs
4 Apr 2019 • 10 min read
SAP acquired Hybris in 2013 and incorporated it into its broad range of products, further underpinning its digital end-to-end ambitions on the software market.
SAP has done a lot in recent years to integrate this remarkable platform seamlessly into the existing SAP software package. As a brand, Hybris has largely been marketed under the global X/4HANA branding strategy since June 2018, and from now on, the Hybris product range will be found in the C/4HANA suite. To avoid confusion, we will use the term Hybris in this article.
Hybris is first and foremost a Java framework that does not dictate rigid forms to the client, but instead puts the client in a position to meet its individual business-process requirements flexibly and quickly. Hybris is based on the Spring framework, and in general uses almost everything else of significance in the open-source universe as well. This makes it easy for good Java developers to quickly get their bearings in the software, although experience is needed to choose the “right” path to take for any given project, because many roads lead to a working software, but they often neglect aspects such as maintainability or performance. Another benefit of the Hybris software application lies in the fact that it is upward and downward compatible, so that Hybris version updates can normally be implemented during the ongoing development.
The Hybris Function Structure
The Hybris Core offers all the functionalities that a modern framework should have. Things like persistence, caching, clustering, etc. are of course all provided. All functionalities at this level are made available to functionalities that are based on the Core.
Hybris runs in any Java Servlet container that meets the JSR specifications. The Apache server (Tomcat) is used most frequently, as Hybris includes it in the standard package. But any other server can also be used for the Hybris platform. Common alternatives include JBoss, IBM Websphere, SpringSource TcServer and Oracle Weblogic.
Hybris builds its functionalities on this level. As a rule they are held together in what are known as “extensions”, where one can find software packages the likes of CMS, PIM (PCM) or the entire Commerce suite. Every functionality block can hold 1-n extensions. As Hybris is a framework, any conceivable software discipline can be implemented here, including ERP or CRM.
But of course you don’t necessarily have to use the Hybris CMS or PIM. You can also install external systems that provide this functionality in your IT landscape. Some examples are Adobe AEM as CMS or Stibo as a PIM system. Hybris has no problem with that. At this level we then trigger a discussion about modular systems and the dismantling of monoliths in services (more about this later).
Hybris can make all its services implemented out of the totality of the extensions used, available to all conceivable channels. As the front-end export standard, the Hybris platform offers a number of storefront applications, but the back-end systems also make direct use of these services.
Also conceivable are front-end applications that address the Hybris software by means of RESTful services, in order to access functions and data. In this kind of constellation, Hybris acts as a service platform that makes its services available to distant applications.
Domain & Industry
Hybris offers a number of front-end exports that focus on various business domains. These applications then generally (but not necessarily) in the same JVM. The advantage of using these “templates” is easy to see: For one thing, these front-end applications already offer a level of functionality that one can easily call a “commodity” or “best practice”, such as product search, product list, product detail pages or checkout and payment. This considerably reduces the amount of work required in the overall project implementation; all that is then required is the customizing. And secondly, they reduce the latency through the Web, as both the service platform Hybris and the front end run in the same JVM.
The Hybris Extension Principle
As mentioned above, Hybris has a modular structure, as the following diagram shows:
As described, the basic Hybris functionalities are encapsulated in the platform and made available to all the extensions that build on it. These include things such as persistence, clustering, caching, a workflow engine and a process engine, and much more besides.
Hybris builds functionalities, sometimes even essential disciplines, in extensions on the platform, with any given functionality having 1-n extensions. Good examples of this are the Hybris CMS, the e-commerce functionalities, and the PIM/PCM. You should definitely take a look at the namespace of the concealed object classes before designing your own extension. A good rule of thumb is to give all of your own classes a special prefix, so that they do not collide with the Hybris namespace in the future.
Proprietary extensions add to the Hybris functionalities that are delivered to you with the platform. You can expand or overwrite objects and functionalities of the Hybris platform in your own extensions, or build an entirely new function stack from the ground up. The sky is the limit here. It is important to remember, however, not to program in the Hybris extensions if you do not wish to jeopardize the future maintainability of the platform.
A note on the front-end exports: Hybris delivers a number of domain-specific, preconfigured front-end solutions, which are then customized and vastly altered in the project.
If you are looking for a proven and future-proof platform that is also highly flexible and modular, supports your time-to-market ambitions and keeps costs to a minimum, there is quite simply no alternative to Hybris on the market today.
The fact that Hybris comprises best-of-breed open-source libraries makes it the ideal option. And if you already use other SAP software, this solution integrates seamlessly, perfectly complementing your software strategy.
At Striped Giraffe, we are well versed in Hybris and in the integration of legacy systems, especially with SAP. You can call on us at any time if you have further questions or wish to talk about any other aspects of an e-commerce solution.
The (Un)Truths about Hybris
Many customers contact us because someone has told them that Hybris upgrades make a change freeze necessary when developing features. That is nonsense. Hybris upgrades can be implemented parallel to the further development of functionalities. Ask us how.
Hybris is a Software Monolith
Exactly the opposite is the case. Hybris is a platform that provides services. You can construct Hybris as a system that covers as many functionalities and services as possible, but you can also break it down to the extent that even OOTB functionalities are shifted out of Hybris. It always depends on the context of the application case, which can vary from project to project and from customer to customer.
Hybris Runs Immediately, Without Major Adjustments
That is true, but doesn’t make a lot of sense. Yes, the Hybris platform could in fact run without any greater effort once you have integrated your own product data, installed and configured the database and made some other minor settings, but that never meets the customer’s demands. A customized front-end, connection to the company’s systems and individually tailored business process implementation are just a few examples of what makes a Hybris application a fully-fledged IT project with long-running attention and maintenance. Ask us for advice, so that you can feel confident about your plans.
The idea behind Hybris was to offer customers a service platform on which 3rd party services could also be offered. This concept did not prevail. Alongside the latency and security issues, inadequate billing models also presented obstacles. What is more, for data protection reasons many customers don’t want or aren’t allowed to store their data with third parties.