In many projects, I hear the same thing: minimize the number of customizations and stick to out-of-the-box. The rationale is clear: the more things you add or change, the more expensive and complex the further support is going to be. Systems are getting bigger, less transparent, comprehensive and changing the default behaviour creates unpredictable, hard-to-detect side effects. The cost of errors is increasing too. However, there is a flip side to that, and that is the lack of flexibility and responsiveness. What is a greater evil?
There is another trend that we need to take into account: amazonization. Yesterday this great company reached one trillion dollars in value. Amazon has been killing brick-and-mortars and independent online stores by offering better service and prices. Standard best-practice solutions may not work anymore, because giants will always be certainly out front. Small start-ups will have the advantage of personalized, custom way of interacting with a customer. Being unique is a great leverage to get ahead.
All IT solutions, and e-commerce platforms are not an exception, are aimed at automating and enhancing the business processes you currently have or you need to have. If your business is built with some standard “business template”, you will likely be happy with many packaged solutions. Simply because they were made for such companies as yours. However, such businesses are getting to be a thing of the past. In order to survive in this new age, you need to be unique.
Loving diversity, on the other hand, allows us to grow, to understand others in order to better understand ourselves and to evolve. Being different is crucial. Who would want an exact copy of themselves next to them their entire life? The same is with the systems. Can you imagine a world where all human beings are identical? What we see now is a lot of identical stores. Yes, it is a working model today, but what will we have tomorrow?
In the world of the similar-looking things, any bright idea makes you visible. The e-commerce platforms give you some space for that, but, with time, it will stop to amaze customers: your store is no longer better than Amazon. Your solution will be as grey as thousands of others on the market.
Changes are to be implemented across the people-process-technology stack, the golden triangle of change.
Each component of this triangle needs to be aligned with others. The technology stack is inextricably linked to the processes and people. Of course, you can train people to make tools and technologies useful, but you need also to change processes. Alternatively, you need to change the system having the processes and people fixed as is.
Changing the processes is a challenging issue. You may find your processes a key competitive advantage. However, from the IT project manager point of view, changing the processes is something that outside the project, while changing the system and training is part of it. That is why many prefer to recommend changing the processes rather than customizing the system.
Configuration and customization?
Configuration is about behaviour adjustments while customization is rather perceived as filling a capability gap. This “gap” is actually not simply about “capability”; it also includes differences between business expectations and OOTB features.
A configurable system is an out-of-the-box solution that allows the owner to easily personalize certain aspects of the system themselves, without the help of experienced software developers. The configurable software is flexible, scalable and can be continually shaped to meet an organization’s industry-specific and organization-specific needs. Zero customized hybris is a configurable system.
A customized system is developed specifically and only for one customer, locking that organization into a static workflow that can only be changed by hiring cost prohibitive engineers to make updates to the system’s code. The e-commerce solution written completely from scratch on top of the framework is a good example of the customized system.
How to harmonize those two extremes?
My answer is simple: split the system into parts, and categorize the parts, not a whole. Go with “configurable” for parts that don’t make you unique. Customize things that form your competitive advantage.
As utopian as a zero customization implementation may sound, the fact is that most companies customize their SAP hybris systems – at least to some degree – after the “zero customization” project is started. The truth is the cost of zero customization becomes too high.
In one of my previous projects, for each of the changes, we’re weighing the cost of a change against the benefit. Of course, it is very judgmental, but the thing is that such topics were discussible made the project successful.
For example, hybris CMS system is not a critical part if your e-commerce system is not going to have hundreds of multi-language multi-domain pages with different layouts and dynamic structure. So, customization is not very important for this component. At the same time, if promotions is your strong suit, then simplifying your current offers to get them better aligned with SAP Hybris out-of-the-box capabilities may not be a good decision.
Keeping control over changes
Hybris e-commerce components are very complex, and even slightest change may lead to a ripple effect with various corner cases resulting from each other. A good solution architect must be able to assess the risks and impacts as well as deliver the findings to the business and technical teams in a clear and simple way.
There are many examples where taking changes timely is over a fear of risk. A good example is a concept of testing in production
. Yes, it is risky, but those who do nothing ever make mistakes. The same is with modifying the commerce components of hybris.
If you go with the customized solution, the complexity will grow every month.
I interview SAP Hybris Solution Architects from time to time. I noticed that many of them look at the e-commerce system as a set of black boxes with some predefined functionality. For some, the boxes are smaller, for others they are huge. They know how to put them together and configure. Yes, in many cases it is a very good approach. However, many of them are not much interested in what is inside these boxes. For example, is it possible to replace Solr with Elastic Search? Taking Drools out? Replace the template engine? Centralize the caching subsystem? That upsets me.
What are your thoughts?
5 September 2018 at 07:52
Great article, thanks for sharing, Rauf!
You know what? Originally, I also thought that given such a flexible system as Hybris and assuming that we have a bunch of Java devs in the team, why not hack the whole system apart? Then, I had to realise that there may be a significant risk in implementing something that already exists (even if partially) in Hybris, since this system has been used by many clients over years, after all.
That said, I would say clients should STRIVE to minimising the level of customisation and of course shall never believe that zero-customisation systems exist. Let’s aim at doing configuration over customisation, don’t be afraid of changing domain/organisational processes with the introduction of such an expensive/important system in their ecosystem as Hybris. They usually also treat Hybris as black box and would like to use it so that it perfectly fits into their existing processes – which probably have been developed over years, if not decades, using tools that now want to get rid off. As such, they must be educated that Hybris is not just a new, shiny tool, but it will bring in some changes in the way how they’ve been operating until now. Consultants must pass on this advice as well, not just merely focusing on the necessary technical changes.
Cheers and keep up with the good work!
5 September 2018 at 15:51
Thank you, Gabor! Sorry for the delay, too many spam replies, and I turned moderation on. Can’t approve it outside the office that adds.
The great addition to what I tried to say, thanks.
5 September 2018 at 11:30
I think this is a good question, and I think the answer is “it depends”. I’ve seen the cases when people try to solve some particular problem using OOTB tools, which are not appropriate here, and personally, I find this as a big Evil, to fit un-fittable.
From another side, we have Hybris, whose biggest value is its generic way. Where any developer in a relatively short time can start developing because he already knows these tools and ways how to solve some particular problems.
The only thing I’m sure, that if some tool does not fit here well, we do not need to force it there just because it’s OOTB.
5 September 2018 at 15:54
>I’ve seen the cases when people try to solve some particular problem using OOTB tools, which are not appropriate here
One of the great examples is implementing News via Product data model. News item extends from Product, Product list controller and Product Page controller are ready for News too, just change the templates, search will work too OOTB. Almost zero customization and the client got what it looked for. I’ve seen such design, and it was created one of the big four companies.