A solution architect’s perspective
The Solution Architect’s role
It’s a role that should bridge the gap between the business and the technical teams; liaising with both parties, particularly in workshops where requirements are discussed, and guiding those parties through the process of how hybris functions with a focus on “out of the box” in order to avoid costly and unnecessary customisations.
Common implementation misconceptions
Integrating hybris with legacy systems
One of the biggest hurdles for businesses to overcome is trying to make hybris align with how they currently operate. What we usually see happening is that companies transfer bad practices when migrating to the new platform. This is largely driven by legacy systems. The problem is that hybris then becomes tightly coupled to the legacy system thereby making it harder to replace those systems and constraining functionality and operations to the lowest common denominator.
Ideally, the interaction between hybris and the third party systems should be abstracted away into a separate layer to remove this tight coupling.
Utilising hybris as the primary source
Another common mistake is making hybris the primary source of all things (product, customer, orders, etc.) What happens here is that as hybris contains this information, the natural approach is to query hybris when another system requires said information. This can be a very bad idea. Opening up hybris to these sorts of queries renders it vulnerable to excessive query loads from the third party system.
An alternative approach is to export the information to an external system on a regular basis, which is then queried. An exception to this is if there is a need to see real-time changes in hybris; for example, in writing copy for the product and previewing the content on a different channel, such as print catalogue.
Customisation and feature “gatekeepers”
It is only natural to want to have the ultimate eCommerce site with all the features and functionality. However, we would recommend that the client first uses the tool, test it out on a smaller portion of the site and then customise through dot releases. We must mention that the first release does not mean that it’s a spaceship sent off to space never to be touched again. The very next day, you can have a dot release to update features and customise as required. So the minimum viable product is so important: set feature expectations low and continually lower them. This is something to be managed by the customer (I use the term “feature gatekeeper”) and not the partner – we cannot be the judge if feature X is really critical to business operations.
Implementing hybris as the chosen solution
hybris is one of the leading enterprise–level solutions commerce platforms. There are two typical scenarios under which hybris is the chosen solution. The first is a brick-and-mortar retailer expanding into online channels. This is a fairly unique scenario as most retailers have some form of an online presence. Most retailers have a well–established an online presence before implementing hybris.
If there is an existing solution that hybris needs to fit into, this includes infrastructure, technical and business; the first step is to understand the existing solution and what functionality is presently offered. Under normal circumstances, a business sponsor expects an equivalent offering that has little impact on standard business processes. What are the key systems? How does data flow between the systems and how is it manipulated by the system? Which system is the custodian of the golden record for which data (the single source of truth)? What is the integration architecture – direct system–to–system or via a service bus or SOA layer? What is the infrastructure architecture? This is hardly an exhaustive list, but it provides a general idea of what should be covered before conducting any functional investigation. The output from these discussions is architectural diagrams (context diagrams, data flow diagrams, infrastructure diagrams, etc.) and non-functional requirements (security policies, deployment strategy, performance requirements, etc.).
Once the system landscape is clearly mapped out, it’s time to hop across the technological divide and engage with the business. The audience here is usually comprised of the following: business owners or decision makers, business analysts, subject–matter experts, project managers and solution architects for key systems where appropriate, especially when discussing topics where data flows from one system to another. Workshops cover the mapping of current functionality to new technology, new business process development and the adjustment of old processes to meet the new technology. At this stage, it is imperative that business processes be re–engineered while ensuring that bad practices are not transferred to the new platform.
A common mistake is for business to remain rigid and demand that the solution be customised to meet their process. Unless this is a core business functionality that cannot be changed (such as fraud credit check), customisation should be the last resort, not the first. If you’re going to splash out on a new platform, it’s recommended that you use what the platform offers out of the box. Once it has been used for a while, customise as required. My key role here is to educate business on how hybris works out of the box, steering them along the path of reduced customization and demonstrating how difficult it is to implement change. The output from these meetings is user stories or business requirement specifications.
At this stage we have two very separate, distant landscapes: technology and business. This is the real challenge: bridging the gap between the two oft-conflicting groups (which also happens to be the part of the role I enjoy the most). From a hybris perspective, some of the key design decisions are the product catalogue design, product provisioning and enrichment processes, content management process, media management, customer account design and management, CRM, stock management and price, fulfillment processes and basic infrastructure. The output from these discussions are high–level architectural designs detailing how to implement the business requirements. These designs and the business stories are then used by the technical leads to design in detail how this functionality is to be implemented. At this point, gaps in the requirements and flaws in the architecture are usually discovered, which is a lot cheaper than discovering it once the solution has been built.
Implementing hybris workflows
One common mistake is developing complex custom workflows for the benefit of enriching products. In theory, it is a great idea, but in practice, it is an impractical overhead, particularly when the team members are sitting right next to one another and quickly the workflows are a thing of the past and managed via email or drastically simplified. Workflow is a powerful feature but thinks wisely about the approach and use case.