Professional Documents
Culture Documents
PROJECT
BEST
PRACTICES
JANUARY 2015
CONTENTS
2 Before You Begin...........................................................................................................................5
2.1 Defining Your Strategy........................................................................................................ 6
2.2 Building Your Team............................................................................................................. 6
2.3 Selecting Your Partner....................................................................................................... 9
3 Feasibility Phase........................................................................................................................11
3.1 Feasibility Phase Tolls...................................................................................................... 12
4 Foundation Phase.......................................................................................................................13
4.1 Getting Started.................................................................................................................. 13
4.2 Project Kickoff.................................................................................................................. 14
4.3 Organizing and Staffing.................................................................................................... 14
4.4 Goal Setting and Planning................................................................................................ 16
4.5 Team Training.................................................................................................................... 17
4.6 Multi-channel Accelerators............................................................................................. 18
4.7 High Level Architecture.................................................................................................... 18
4.8 Create Infrastructure (Development Setup)................................................................... 21
4.9 Requirements Reviews & Workshops............................................................................. 22
4.10 Foundation Phase Tolls.................................................................................................... 23
5 Exploration Phase......................................................................................................................24
5.1 Product Data..................................................................................................................... 25
5.2 Search................................................................................................................................ 30
5.3 Omni Channel Commerce................................................................................................ 31
5.4 Prices, Carts and Checkout............................................................................................. 35
5.5 Commerce Integration..................................................................................................... 37
5.6 Fulfillment Process.......................................................................................................... 37
5.7 Solution Architecture....................................................................................................... 37
5.8 Reporting and Analytics................................................................................................... 38
5.9 Backend Systems.............................................................................................................. 39
5.10 Architecture Reviews & Workshops................................................................................ 39
5.11 Foundation Phase Tolls.................................................................................................... 39
6 Engineering Phase......................................................................................................................40
6.1 Architecture...................................................................................................................... 40
6.2 Local Environment.............................................................................................................41
6.3 Software Design................................................................................................................ 42
6.4 Development..................................................................................................................... 42
6.5 Data.................................................................................................................................... 44
6.6 Code Review...................................................................................................................... 44
6.7 Documentation.................................................................................................................. 44
6.8 Testing............................................................................................................................... 44
6.9 Data Migration................................................................................................................... 46
6.10 Monitoring......................................................................................................................... 46
6.11 Engineering Phase Tolls................................................................................................... 46
7 Deployment Phase......................................................................................................................47
7.1 Production Cutover Planning........................................................................................... 47
7.2 System Maintenance......................................................................................................... 48
7.3 Training.............................................................................................................................. 48
7.4 Go Live - Execution........................................................................................................... 49
7.5 Debrief............................................................................................................................... 49
7.6 Deployment Phase Tolls................................................................................................... 49
8 Support and Operations Phase...................................................................................................50
8.1 Monitoring......................................................................................................................... 50
8.2 Contacting hybris Support............................................................................................... 50
8.3 Incident and Problem Management................................................................................ 51
8.4 System Maintenance......................................................................................................... 51
8.5 Change and Release Management.................................................................................. 51
8.6 Documentation.................................................................................................................. 51
8.7 Support and Operations Phase Tolls............................................................................... 52
9 Typical Project Pitfalls...............................................................................................................53
9.1 Business Requirements Not Fully Supported by the Platform..................................... 53
9.2 Overlooked Functional Areas........................................................................................... 53
9.3 Very Large Functional Requirements............................................................................. 53
9.4 Premature Go Live............................................................................................................ 53
9.5 Recommended Order of Design Activities...................................................................... 54
10 Useful Links................................................................................................................................55
11 Activity Timeline.........................................................................................................................56
12 Activities
.....................................................................................................................................62
HYBRIS PROJECT BEST PR ACTICES | 1
1. INTRODUCTION
You are in good company. We now serve over 500 customers, including some of the most recognized companies in the world
(global B2B brands as well as consumer brands). We are now by far the fastest-growing major commerce platform company—
our compound annual growth rate since 2009 is 83%.
As much as we are a company built on better technology, we are also a company built on a philosophy of partners and a culture
of innovation.
From the beginning, we have relied on partners who are deeply knowledgeable in their industry specialties and very close to
our customers to lead most implementations. We can now count among our 200+ partners some of the most widely respected
names in the industry, around the globe.
To compliment our partner ecosystem, hybris’ highly skilled Professional Services consultants deliver pragmatic advice and
guidance, helping leading brands, manufacturers, and retailers to maximize the value of their multi-channel programs by
effectively balancing function, time to market, and expected return on investment. Adding hybris Professional Services to your
project allows hybris to have a “seat at the table” and help ensure your success and best practices with the implementation of
hybris software.
• Shaping your multi-channel vision by understanding the true potential that multi-channel holds for your company
• Appraising your current situation and identifying the blockers and enablers for multi-channel in your organization
• Planning your approach with a roadmap that will help you achieve your multi-channel goals
• Realizing your plans and helping you deliver the multiple programs and projects required, on time and on budget
• Growing your revenue and profits and uncovering ways to improve and expand your multi-channel business
What to expect
This document provides a summary of hybris project best practices as collected by the hybris team responsible for project
delivery. The main intention of this document is to provide the reader with “a set of activities an implementation team should
consider during a hybris commerce project implementation”. The target audience includes:
• Project managers, to better understand recurring specific hybris e-commerce project activities, their dependencies and timing
• Architects, to better understand typical recurring design considerations
• Business consultants, to get a better idea of mapping of general e-commerce functionality requirements into hybris
commerce project.
• Technical consultants, to better understand how chosen technical approach will impact the final solution
• Team leaders and scrum masters, to be able set up and run hybris project in an optimal way
• Project owners, to have a better insight what a typical hybris project consists of
• Development methodology or communication style. Our extensive partner network provides expertise on building a project
approach and timeline that is right for your specific requirements.
• Specific and deep project answers to architectural, design or technical questions. The document does provide general
guidelines and considerations, but specifics often differ from one project to another. Only a deep understanding of
requirements, technology and available scope of work lead to an optimal solution in each individual case. We are committed to
keep extending our knowledgebase on our wiki where specific knowledge sharing happens.
• This document is bound to hybris technology, but is not bound to any specific hybris software version. Some functionality
changes from one version to another.
This document is under continual improvement—with future version releases expected. So please always ask for the latest
version. (You can always find the latest version on hybris wiki: https://wiki.hybris.com/display/hyps/Project+Best+Practices)
Document Structure
The document is structured into the following chapters:
Each chapter describes typical activities in each individual phase. The phases themselves should be seen as building blocks and
can be used repetitively with both agile as well as waterfall development methodologies.
Of course, it is tough to perform or validate work if you don’t know what to look out for. hybris Professional Services has prepared
this series of recommended Toll Gates and Tolls based on industry best practices and past project experience. hybris clients and
partners are encouraged to adopt, modify and expand on this list to suit each implementation project. Gates align with each phase
of the implementation and one or more “tolls” need to be “paid” prior to moving to the next phase. Paid tolls should be documented
and acknowledged while unpaid tolls should (of course) be escalated and addressed during project status and/or steering
meetings. In this document, each section will end with its corresponding “tolls,” marked as [[T]].
• Enable you to implement hybris projects better, faster and with confidence
• Provide real life experience from many projects
• Provide best practices and service programs to make projects successful
• Augment your project team where needed (reviews, specific customizations, integrations, etc.)
• Provide a “hybris recommendations filter” on your implementation
The content of this hybris Project Best Practices guide is highly confidential and the conditions of the confidentiality agreement strictly apply. This guide is for
informational purposes only and must not be disclosed to anyone and/or forwarded or copied in any way or form. The hybris project best practices and the
information contained in this guide may be subject to change, updates, revisions, verifications and further amendments by hybris at any time without notice.
While the information contained in this guide has been prepared in good faith, neither hybris nor its shareholders, directors, officers, agents, employees, or advisers
give, has given or has authority to give, any representations or warranties (express or implied) as to, or in relation to, the accuracy, reliability or completeness of the
information in this paper, or any revisions thereof, (all such information being referred to as “information”) and liability therefore is expressly disclaimed. Accordingly,
neither hybris nor any of its shareholders, directors, officers, agents, employees or advisers take any responsibility for, or will accept any liability whether direct,
express or implied, contractual, tortious, statutory or otherwise, in respect of the accuracy or completeness of the information or for any of the opinions contained in
it, or for any errors, omissions or misstatements or for any loss, howsoever arising from the use of this guide. In furnishing this guide, each of hybris and its advisers
does not undertake or agree to any obligation to provide the recipient with access to any additional information or to update this guide or to correct any inaccuracies in
it, or omissions from, this guide which may become apparent.
1. Company Strategy: First, identify what the organization needs to achieve then define specific expectations around how the hybris
implementation will impact and benefit these strategic objectives.
2. Company Team: Identify responsibilities for technical and business stakeholders during the implementation, and consider
changes to roles, skills and responsibilities (org. structure) post implementation.
3. Partner of Choice & Partnering Strategies: Even the best partners and the greatest clients can be miss-matched. Define what
is important to your organization and be ready to share it with your partner(s).
By ensuring these have been defined and understood by your organization, you are on the way to preventing some of the common
pitfalls we have seen while undertaken a hybris project.
Every organization should start with an overall vision, which can be company-wide or commerce-specific. A good practice is to
validate that your team shares an easily understood top-level strategic goal, typically one or two sentences long, that stakeholders
should be able to communicate regardless of their role. From there, you can drill in to more department specific goals, prioritize
them, and define their success criteria. Whenever possible, define measurable success (and Return on Investment) by setting
revenue targets, measuring baseline metrics, and identifying KPIs.
Additionally, leading change is essential and often overlooked aspect of many software projects. There are many moving pieces to
a commerce implementation and each piece can require new skills and impact people and roles. Regardless of your organization’s
philosophy on change management, it’s a good practice to communicate what you know (and don’t know) early and often. Focus
first internally on the people, process, and technology - ensuring everyone in the organizations knows what you are driving towards
and how you will get there. Other proven practices for leading change include: demonstrating strong leadership, communicating
early and often, and training/educating throughout the process. As you get closer to go-live, begin looking externally towards
adoption; bringing user feedback into the system as early as possible has value as well.
Finally, hybris also recommends having an organizational strategy around Intellectual Property (IP). Every hybris implementation
has unique and often very innovative elements specific to the organization, often related to the strategy. hybris recommends
having a complimentary IP strategy for documenting and preserving your work, for example where your code will live and how it
will be maintained. hybris sees many organizations become tied to their partner or system integrator because they don’t have a
long-term maintenance and preservation strategy. Regardless of where you environments will live, it is strongly recommended to
have a copy of your code internally, as well as a resource to maintain it.
hybris specialists are often asked, “What’s the best practice requirement staffing requirement our new omni-commerce solution?”
It can be difficult to calculate the number of staff required for your e-commerce team, both during implementation and for live
operations. According to published industry surveys, three quarters of online retailers have more than three employees devoted
to e-commerce. For an omni-channel organization running hybris, many essential business functions are shared across all
channels. Product sourcing, creative, human resources, accounting and even some fulfillment responsibilities are shared with
brick-and-mortar and catalog channels. In this environment, it is important to understand the essential roles that make up the
e-commerce team.
While there is no easy “best practice staffing level” recommendation for hybris or any commerce solution, we do know that 75% of
e-commerce sites require at least three staff members. So unless your site is very small, filling the essential e-commerce roles
(marketing, merchandising and operations) with dedicated FTEs should be your bare minimum level of staffing. Better staffing
predictions can be made by evaluating common variables should help guide your staffing decisions:
E-Commerce Marketing
• How frequently do you send out emails?
• How frequent are your site promotions? Do you have web-only promotions?
• Do you have or plan to have affiliate programs?
• Will paid search be managed internally or by a vendor?
• Are you planning on social community outreach: Blogs, Reviews, Facebook, Twitter, etc.?
E-Commerce Merchandising
• How many products are you selling online?
• How often do those products change?
• What is the quality of the product data you receive? How much rework is needed?
E-Commerce Operations
• How much of the site development is being done in-house vs. outsourced?
• How many vendors do you need to manage?
• How complex is the site?
Predicting staffing levels for the implementation team is even more difficult and driven by many variables such as build complexity,
experience and timeframe. Just as strong leadership starts from the top down, successful teams are built in the same fashion.
Traditionally, this falls into three groups: business, IT, and operations. Organizations should begin mapping out which roles will
exist in-house, and which will be done through a third party. This will typically be related to the deployment model of the solution,
specifically whether it will be on-premises or hosted. Once this has been determined, you can determine which roles need to be
created and establish a hiring plan from there.
At a minimum, hybris recommends accounting for the following roles. Note: Many of these roles are not full-time positions, and
are often combined and performed by single individuals.
BUSINESS
ROLE DESCRIPTION
Merchandizer Responsible for relationships between products, particularly for cross-selling and up-selling.
Graphic Designer Responsible for creating the media content that is displayed on the site, particularly images and video,
it may or may not also include HTML and CSS.
Payment & Fraud Responsible for ensuring the books are balanced, and monitoring and preventing fraud.
Analytics & Business Specialist role that analyzes site data, and monitors customer behavior for optimization.
Intelligence Specialist
SEO Specialist Specialist role responsible for maximizing search exposure and results.
Translator Responsible for translating the content when the site is available in other languages.
IT
ROLE DESCRIPTION
Operations Manager In charge of the day-to-day technical operations of the site, support, and IT. They are primarily
responsible for keeping the site up, and ensuring all SLAs are met. They are also the primary
liaison to the business.
Developer May be skilled in one or more of Java, HTML, CSS, and JavaScript. An in-house resource can be
useful for making day-to-day changes to the site and small to medium feature changes.
Database Admin An optional resource, person skilled in SQL for operation, maintenance, and support of the database
and its underlying technology.
Network Admin Responsible for operating, maintaining, and supporting the network. This includes servers, firewalls,
switches, and routers.
On-line Store Manager Responsible for the day-to-day operations of the site, including managing products, pricing,
and promotions.
Support Team Lead Responsible for managing the CSR team, dealing with escalations, and ensuring issues are resolved
in a timely manner.
CSR Customer Service Representative who would be responsible for handing in-bound customer calls and
emails.
Purchaser In situations where the organizations does not manufacture their own goods or sells third party
products, this role works with suppliers to source and order product.
Warehouse Manager In charge of the pick/pack staff, they are responsible for the day-to-day operations of the warehouse
and ensuring shipping service levels are met.
Picker/Packer Warehouse personnel who are responsible for receiving and shelving inventory, counting stock, and
picking, packing, labeling and shipping individual orders.
Knowing that carefully selecting a systems integrator is a critical step to a successful project, hybris is often asked to recommend
partners or provide guidance on how to make the best selection. Of course, every customer must choose its partner according
to its own internal criteria and selection process. Before you begin, hybris does recommend you define what is important to your
organization and be ready to share it with your partner candidates, the following questions will assist this process:
• Do you have an incumbent agency / SI that you would like to work with?
• What range of service do you require? The typical services provided by partners are: strategy, design, program management,
implementation and ongoing application support.
• Would you prefer to work with a large consulting organization or a smaller boutique firm?
• What other key technologies expertise is expected within the company? (ERP, Search, WCM)
• Do you have preference for on-site versus remote delivery? What about off-shoring?
• Where is the SI team located that will be involved with the implementation?
• Do you have a preferred implementation methodology? (Such as Agile or Waterfall)
Below are recommended questions to ask when interviewing candidate hybris implementation partners:
Client Relationship/ Customer Care/Contract Role, works closest with hybris Account Manager
Program Manager
hybris Lead Developer Required: hybris certification Core & Commerce Development
Some customers prefer to do all the development using internal resources and to not depend on partners at all. However the
typical feedback towards the end of these projects is, that at least some partner involvement would have been a better option.
When undergoing the partner selection process, hybris recommends request samples from past partner projects.
The feasibility phase evaluates the project’s potential for success; therefore care must be taken to deliver a balanced, credible
review. The project stakeholders depend upon hybris to conduct this assessment with an objective, unbiased approach and to
provide information upon which decisions can be based.
The assessment is based on an outline design of stated business objectives and technical system requirements, to determine best
technology and process fit. This could include assessment of the technical expertise required to successfully complete the project
and assessment of the likelihood that the proposed technical solution will support the business requirements. When writing a
feasibility report, the following should be taken to consideration:
• A brief description of the business to assess possible factor(s) which could affect the study
• The part of the business being examined
• The human and economic factors
• The possible solutions to the problems
At this point, the objective is to identify the facts that will help determine if the proposal is feasible from a technical and business
perspective. Financial analysis may be included (e.g., breakeven analysis, EVA or other metric generally used by the customer to
gauge project value).
Mapping this phase to the Project Management Institute (PMI) PMBOK project phases, the feasibility phase would overlap some of
the activities in the initiating and planning phases. Some (not all) of the activities in this phase include:
The hybris pre-sales team assists your organization during your software evaluation and selection process in the following ways:
Feasibility phase deliverables should provide enough information for the organization to be comfortable with the selection
and purchase of hybris software, and can then be used as inputs to start the project. Information gathered from the feasibility
evaluation should provide the basis of documented business requirements for the project.
• Key stakeholders are identified and contact information is available (this should include representation from the client,
partner(s), as well as hybris):
»» Project Sponsor(s)
»» Project Owner(s)
»» Project Manager(s)
»» Account Manager(s)
• Project framework:
»» Vision and Business goal, what is driving this project
»» Project Methodology – (e.g., waterfall or agile)
»» Communication/project status plans
»» Project assumptions
»» hybris resource access (wiki, support, forums, training, hybris Professional Services)
• Roles have to be established. The team structure and reporting lines need to be created across all involved parties (project
owner, hybris, implementation partner), and during the project kickoff, team members will be assigned to the various roles.
• Each team member needs to understand their role, when they will start participating on the project, and how much of their time
will be allocated. Whoever was responsible for assigning the right people to the project during project kickoff will now need to
proactively manage the involved team members and their participation during the project itself.
• Define who will create and maintain the Project Plan. There are three dimensions to every project: time, cost, and feature set.
While any two dimensions can be easily managed, the remaining third dimension could potentially spin out of control. The Plan
should prepare for such situation, and prioritize the dimensions.
• Communication channels should be discussed as well. What will we use in everyday communications? Where will the issues be
tracked? Who to call in case of urgency? The goal of the kickoff meeting is to find the responsible owners of all these decisions
for all parties involved.
The meeting should also reconfirm the already set strategic business goals, and make sure everyone on the team members
understand them.
It’s also important to identify and discuss all risk factors and make somebody responsible for risk mitigation. The risk factors differ
from project to project, but these examples could serve as a good starting point:
• Project Manager: responsible for coordinating the whole project externally and internally. Make sure the
• Project Manager is given the authority he/she needs—all others are stakeholders
• Business User Representative: responsible for detailed functional specifications and acceptance criteria
• Business Analyst: responsible for defining and facilitating functional requirements and understanding to the
project team and stakeholders
• Solution Architect: responsible for the technical solution architecture and integrations
• Software Architect: responsible for software design, modules, design patterns, and use of hybris platform functionality
• Team/Tech Lead: responsible for supervision and mentoring of software developers
• Software Developers: responsible for software implementation, testing, and maintenance
• User Experience/UI Experts: responsible for ergonomics and usability of the solution
hybris Professional Services offers an example RACI document, which provides a matrix for typical activities on a hybris project.
Each activity has assigned parties (customer, partner, hybris, third party), each party has an assigned role for each activity. The
roles are: Responsible, Accountable, Consulted and Informed. hybris Professional Services can help you with creating the RACI
document for your project. An example RACI document maintained by hybris managed services could be found on our wiki:
https://wiki.hybris.com/display/MSS/Roles+and+Responsibilities+-+RACI
Some team members are on the project for its entire duration (for example Project Manager), while other members may join later
(Quality Assurance), or leave early (Solution Architect). Some team members could be fully dedicated to the team (Application
Developer), while others may work only part time (Subject Matter Experts). It is important to establish processes to ramp-up every
new team member as fast as possible. It is similarly important to establish processes to document all the important knowledge if
a member leaves the team to allow smooth transition.
Establishing internal and external communication processes is also key. Too many people involved in communication,
attending meetings, and providing input results in slow progress and lack of accountability. On the other hand, lacking or poor
communication leads to confusion around project goals, requirements, architecture, or API contracts. It is always important
to find the right balance for your specific project.
We recommend overseeing the project progress by a Project Steering Committee. This Committee ideally meets at a minimum
of every two weeks; a hybris Service Delivery Manager should be in attendance at these meetings. This is also a good time to
establish policies, controls, and formalize the project organization. The project size is usually the most important contributor
to the level of recommended formalism.
• Do we want to maximize the initial feature set? This could make the project long and beyond budget constraints.
• Do we want to deploy as soon as possible? This could make the initial feature set below expectations.
The discussion should not only cover functional, but also non-functional requirements, including performance requirements.
There’s a huge difference between building a solution for 2000 orders/day and 2000 orders/second. Sometimes there can be a
trade-off between functionality and performance.
The discussion should also cover all functional domains from the business point of view (commerce, data management, media
management, order management, stock management, etc.). Very rarely are all the domains managed by one system. The business
users will work with multiple systems, and technical people need to integrate them. It is too early to discuss individual details (such
as individual features or integration patterns), but it should be clear what business processes will be modified, created, or become
obsolete. Every Business User Representative should have a clear vision or at least an understanding of how his everyday work
would be affected or improved.
Risk management should also be established in this phase. The risks uncovered in the kickoff meeting or during the project need
to be managed in a structured and formalized way. This will not only minimize the risk, but also provide insight into what decisions
were made to mitigate the risks and why. This could be a valuable source of information in later stages of the project if necessary.
Business users need to familiarize themselves with the capabilities of the software—especially the use of hybris cockpits. There
should be no surprises at the end of a project that pre-built hybris components do not meet the requirements of the business.
hybris Professional Services provides business user workshops can help assist in this area.
The project team should accomplish the following tasks as a result of the initial project planning (also refer to the planning phase
of the Project Management Institute project phases):
hybris Training is responsible for developing and delivering training programs for all hybris customers and partners. hybris has
trained thousands of developers in hybris technology. To examine our standard training programs and offerings, please see our
Academy training shop website at http://campus.hybris.com.
• Instructor led Courses: hybris role-based curriculum is designed to address the needs of every member of your team—
Business Managers, System Administrators, and Developers. Courses provide informative lectures and hands-on labs to
maximize your experience
• Global training centers: students can attend courses at a variety of hybris training center locations, including Chicago, Boston,
Munich, Paris, and London
• On-site training: a convenient and cost-effective way to train groups of students at the same time. On-site training provides the
additional benefit of allowing the course delivery to be focused on your needs
• Web-based virtual classes: available for select courses
• hybris Certification: This program sets the standard for hybris knowledge within our customer and partner community. These
web-based exams can be registered for and taken online at any time
hybris Quick Start: a one-day, intensive training designed to give attendees a thorough introduction to the entire hybris platform
and its extensions.
hybris Developer Training Part I - Core Platform: This four-day training has a 60/40 hands-on/lecture format, and leans heavily
towards Java J2EE developers. All of the core functionality of the platform is covered, as shown in the list below. This course does
not aim to teach the domain of e-commerce.
hybris Developer Training Part II—Commerce: This three-day hybris e-Commerce training is a hands-on training course
designed to teach attendees the fundamentals of creating a high-quality, state-of-the-art e-commerce application. The training
uses instructor-guided technical trails to teach the developer step-by-step how to create a fully-featured e-commerce application
using the hybris Accelerator. Over the course of the training, developers will learn how to implement an attractive and fully-
functional merchandise web shop.
hybris System Administrator: This two-day class reviews hosting, running, and monitoring a hybris application and requires
specific know-how on used system components and tools, as well as a general system overview. Browsing the whole
technical hybris universe, participants learn to set up, install, test, and debug a hybris application. Project managers may attend
this course, as it provides a broad range of information about how to deploy applications and data, backup/restore, monitor,
and debug the application.
Other courses are also available. For training registration simply send a message to training@hybris.com.
After classroom training we highly recommend our development trails, which are available on wiki. The trails are written as
tutorials and will let you to write code, experiment, use, and modify functionality hybris platform provides. The development trails
wiki also offers documentation describing the reference implementation (the Accelerator) from many aspects: Project Process
Guide, Delivery Framework Guide, Functional Specification, Business Guide, Technical Design and End User Guide.
The hybris Commerce Developer Certification is the second software developer exam in the hybris
developer learning path. For developers who have already passed the hybris Core Developer
Certification Exam, the Commerce Developer exam further tests your understanding of the
commerce concepts and APIs of the hybris platform.
The software workshop is format that is intended for business users (non-technical audience) who will be working with the hybris
platform. The workshop usually starts and facilitates discussion about required feature set, planned business processes and
complexity of the project.
With a fully-functional storefront, call center capabilities, and social network integration, the accelerators also offer support
for additional channels like mobile, print and point-of-sale (POS). The accelerators also come with a wide array of ready-
to-use backend integration points, how-to guides, sample data as well as best practice guidelines—all intended to simplify
implementation and maintenance.
Furthermore, built using best-practice development coding and standards, the hybris Multichannel Accelerators deliver source
code that organizations can easily customize without requiring heavy coding, accelerating the development process.
There are many types of system and software components that can make up a hybris system architecture; there is probably
not one “typical” hybris system architecture. The numbers of servers and components completely differs depending on
implementation requirements. To give you an understanding of the kind of system and software components you will typically work
with on a project, starting with the hybris Multichannel Accelerator as a base, the following section describes how various types of
component physically and logically fit together. You can find more details about each component in the counterpart sections of the
hybris Multichannel Accelerator documentation on the hybris wiki.
The diagram on the next page shows an example deployment setup of a hybris Multichannel Accelerator based implementation.
It is common to use a web server, such as Apache, to store static assets such as images, CSS and JavaScript files.
This is typically done to ensure the application server resources are not troubled with assets that can be served from the web
server with greater performance.
The following diagram shows an example of how components are arranged into their logical tiers:
The hybris Multichannel Accelerator provides much of its functionality straight out of the box, but projects
need to consider additional integration points to other external systems. The following deployment diagram
identifies integration points to some third-party systems that may need additional development effort. This list
is not exhaustive, but it includes some fairly common integration points in a B2C implementation.
The high-level architecture should describe the desired approach of your solution: what systems will be integrated, what
technologies and design patterns will be used, and how the desired solution will handle the expected load.
• Shared catalogs
• Separate catalogs, but shared data (as seen in the Accelerator)
• Separate data (tenants), but shared web container and Java Virtual Machine (JVM) process
• Separate web containers, but shared code base
• Separate code base
Having separate tenants (separate data but the same web container and code base) should be backed by good justification. From
our project experience we see that most projects requiring separate data also require a separate codebase.
With platform version 5.1.0 you can customize extensions built on top of the Core+. A Core+ extension can be deployed in the
same Tomcat web container used for the core platform, which is good for simplicity, or it can be deployed in a separate Tomcat
server(s), allowing for better scalability and performance tuning for both the hybris server and Core+ based extension. Consider
the expected traffic volumes and load.
• Development environments: These consist of individual computers with typical hybris system requirements, both hardware
and software. Allow 2G RAM for the tomcat JVM as well as 2G RAM for Eclipse for comfortable development. The system
requirements are defined on the wiki, as are the JDK (Java Development Kit) with the latest distribution of the currently used
java version, IDE tool such as Eclipse, and several other utilities. A local database is also very useful for quick development.
Other environments used for integration tests, acceptance tests, or production environment are typically built later, in parallel
within the exploration phase
• Code repository: Here, you maintain the latest version of your code as well as additional versions created during the project.
Choose the versioning technology carefully with respect to the team experience, need for features, as well as privacy options.
Make someone responsible for maintaining the code repository. Larger projects might also establish a release manager
responsible for merging code before a release and writing release notes
• Build automation: Automatic nightly builds help to maintain higher level code quality by continuously running unit and
integration test for the latest version in the trunk. Even though setting up the build environment consumes time and hardware
resources, it always pays off in a long run.
• Communication tools: set up documentation processes, incident management tools, as well as tools to monitor daily progress.
Some tools need to be configured in conjunction with processes, so this is a good time to establish or verify them
• Code quality tools: There are tools, such as PMD, which provide automatic code quality control. A sensible choice of PMD rules
will improve your code quality, readability and maintainability
• Coding standards: The project should also establish basic rules such as coding conventions (e.g., agreed indentation rules),
code acceptance criteria (i.e. a definition of “done”), code review processes, documentation templates, useful mailing lists, etc.
Make sure you install the hybris Commerce Suite only with modules available through your license agreement. This will prevent
developers from unintentionally using a codebase the solution is not licensed for. Removing deeply integrated code without proper
licensing or buying additional license towards the end of the project can be problematic and cause delays; not good news for the
Project Steering Committee.
Detailed developer installation steps and instructions can be found on the hybris wiki. The hybris Commerce Suite is a very
lightweight and completely Java based application that runs on many system combinations. For a quick start, it is important to
know the basic software and hardware requirements for running a hybris Commerce Suite.
There is no need to install a separate web server. With the hybris Server, the hybris Commerce Suite includes a built-in and
preconfigured server based on Apache Tomcat, ready to be used to serve web pages.
There is no need to install a separate database if you want to try out and demonstrate the hybris Commerce Suite. hybris has
bundled and preconfigured the lightweight HSQLDB database, which typically is sufficient for primary tests. When you implement a
hybris solution, we highly recommend the use of a professional database system such as Oracle, MySQL, or Microsoft SQL Server.
The hybris supported environments, browsers, and databases along with their versions can be found on wiki on page called
“Third-Party Compatibility.”
If hybris managed services will be used to host the solution, they should be involved in discussions of configuration, access and
other details necessary before development starts.
https://wiki.hybris.com/display/general/Test+Tools
https://wiki.hybris.com/display/general/Atlassian+Suite
https://wiki.hybris.com/display/general/hybris+Eclipse+IDE
https://wiki.hybris.com/display/release5/Application+Performance+and+Monitoring
Software Workshop: Intended for business users (non-technical audience) who will be working with the hybris platform, the pre-
requisite for the workshop is attendance of either the hybris Quick Start or Features & Concepts class. The workshop provides
an environment whereby the business users can ask specific questions about the functionality of the platform and how to work
with the hybris UI (cockpits), as well as using hybris Accelerators (non-customized). The agenda includes a high-level refresher
on the functionality of the software, demos of its capabilities and how to work with the system (i.e. add/modify products, provide
promotions, etc.). An open Q&A forum is encouraged, allowing business users an understanding of how they would modify their
website using hybris tools/cockpits. hybris recommended best practices are provided as part of the workshop. The workshop
helps business users get familiar with the technology, which allows for faster and clearer definition of additional business
requirements. This workshop is typically performed early in the project life cycle.
Requirements Workshop: In the Requirements Workshop, hybris will help facilitate and contribute to the functional requirements
gathering process for the project, identifying requirements that can be supported through the base platform or accelerators
vs. customization. This package is especially useful in helping to define the scope of a project, as custom requirements need
to be evaluated and estimated as part of the overall project cost and timeline. Integrations are also reviewed for best practices
approaches to integrating with the hybris platform. This workshop is typically performed early in the project life cycle, prior to the
Exploration (Technical Design) phase.
Requirements Review: The requirements review performs an analysis of your requirements and maps them to the functions and
features of the hybris platform. A “gap” analysis is performed and documented to identify specific features that require custom
development or customization of the hybris platform. Recommendations on how business processes can be modified in order to
fit the existing hybris functionality—thus helping to minimize customizations—are also provided. This package is especially useful
in helping to define the scope of a project, as custom requirements need to be scoped and estimated as part of the overall project
cost and timeline. Integrations are also reviewed for best practice approaches to integrating with the hybris platform. If hybris
Accelerator is being considered additional detail is provided regarding the fit and feasibility of hybris Accelerator. This review is
typically performed early in the project life cycle, prior to the exploration phase.
Planned activities:
• Analyzing the requirements, adjusting business processes, creating proof of concepts, functional and
technical specification documents
• Discussing all aspects of a typical commerce site / PCM implementation (expose implicit requirements)
• Making architectural decisions and precise effort estimates
• Capturing use cases, user stories, data flows, and integration details
• Specifying acceptance tests
• Setting up environments
• Functional requirements definitions, modifications to the original business process that are clear and agreed upon
• Technical design specifications and proof of concepts, including UI sitemap/wireframes, product catalog structure, site
navigation/flow, integration design specifications, and customization specifications
• Documents with desired, but currently out-of-scope, functionality
• Additionally identified risk factors, such as complex business requirements, complex integration patterns or lack of data
ownership / availability
• Build plan
• Test plan
• Build and test environments
• Update the project plan based on the latest estimations
The hybris Requirements Workshop or Requirements Review are recommended in this phase of the project to help map business
requirements to the functionality of the hybris platform.
There could be several exploration-phase blocks, so the project could be divided according to different project domains.
Data mapping identifies what data types (such as products, prices and media) are needed in the product content including their
attributes. The data mapping discussion includes data domains of the legacy systems, desired extensions of the existing business
process as well as taking the existing platform functionality into consideration. It is necessary to understand the core business
requirements as legacy systems could be cluttered with workarounds, which may not be needed in the new solution.
An example of such a discussion is visibility of a product on the storefront. The hybris platform functionality provides online date
and offline date as well as approval status. A legacy system could provide additional attributes such as visibility, availability and
search ability. The discussion would compare the meaning of attribute values as well as their combinations to the core business
requirements with an aim to simplify the process and reuse the existing platform functionality as much as possible.
Including thousands or more products in the system requires a structure, which will help business users to manage vast quantities
of product content. The main aim of putting structure in the place is not only to find and manage products but also to be able to
assign a common attribute in one place (for example, applying a 30% discount to all new products).
The structure can be purely internal or it could be exposed to the outside world to help customers navigate in the data structure.
However, customers would typically use search services, such as free text search or facet navigation, therefore the catalog
structure is important for the internal data management. hybris allows for zero, one or multiple structures and discussions should
find the right structure for the business needs.
The hybris elements creating a structure include catalogs, catalog versions, categories, products and variant products. These
elements provide a wide range of structure modeling. For example, we can build similar structures supporting different business
needs by having two catalogs or having one catalog with two top-level categories as shown in the hybris accelerator.
Using variant products should be also discussed, as the design would vary from project to project. Typical discussion would cover
requirements for:
The product attributes could be defined at compile-time, or it could be assigned at run time via a taxonomy structure, which
is sometimes called classification system. While the taxonomies provide a comfort for business users, it also brings some
constraints and limitations. A typical question to discuss is: Do we need taxonomies and classification systems? What attributes
should be defined at compile-time (so called ‘type attributes’) and what attributes are of more dynamic in nature (so called
‘classification attributes’)? Who will manage classification structures and attributes? Will the taxonomy be managed in hybris or
will it be imported from an external ERP (Enterprise Resource Planning such as SAP) system?
The product instances and product attributes should have a master system. A typical discussion should determine what the master
system will be for the new solution, and for what data. Changes of the data need to be imported into hybris and there is no one
bulletproof, recommended approach for all possible use cases. The discussion usually focuses on technology (hybris ImpEx, hybris
Data Hub, web services, JMS, import cockpit, product cockpit, hMC, proprietary technology, etc.), but business aspects are equally
important. To name a few: How often will the updates happen? Do we need to import data on-demand? What is the target catalog
structure? Are there any impacts on data management workflows? Timing of the imports and the impact on site performance (in
memory cache).
The hybris Commerce Suite ships with two integrated import and export extensions. The original text-based import and export
extension is called ImpEx and allows creating, updating, removing and exporting platform items such as customer, product or
order data to and from Comma-separated Values (CSV) data files—both during run time and during the hybris Commerce Suite
initialization or update process.
• Import and export hybris Commerce Suite data from and into CSV files.
• Support for import using database access.
The other import-export extension is called Data Hub. Its main features include:
• Simple user experience that hides the complexity of the hybris data structure
• Acting as a staging area where external data can be analyzed for errors and corrected before being fed into hybris
• Ability (but does not necessity) to be deployed to a standalone web server independent from hybris
The Data Hub is currently used as primary technology for asynchronous integrations with ERP systems.
Sometimes there is a requirement to export data, enrich it in a spreadsheet and upload it back to the system. This requirement
is typically discussed when there is a need for collaboration with a translation agency. The solution could implement the exact
process as described above, while sometimes a direct integration with the translations provider or a limited access to the product
cockpit could be a better choice.
Having multiple suppliers could result in a need of merging data, finding duplicates, choosing the most dependable “golden record”
and enriching the data as needed.
The hybris out-of-the-box solution allows the structuring of data using catalog versions. Each catalog version would contain a
whole set of products, each catalog version intended for different business cases. The hybris Accelerator comes with two catalog
versions: a staged catalog version is used for editing purposes, while the content of the online catalog version is displayed on the
front end. However, each project could require a different number of catalog versions.
The synchronization process takes content from one catalog version and puts it into another. This process is highly configurable
and should be defined as a synchronization strategy. Typical areas to discuss cover:
• What types, attributes and languages need to be synchronized? While the answer could be obvious for products, there are
many other types where the answer could require a longer discussion, such as product keywords or product related rich
content like brochures or videos.
• When will the synchronization take place? Do we want an automated synchronization of approved products? Or is it better to
synchronize selected products, categories or even whole catalog versions on demand by a user? What is the impact on the
performance of the website and data caching strategies? When and how is the search engine re-indexed with new data?
• Sometimes, the synchronization strategies could become complex with many rules. In these cases we need to pay a special
attention on the final effect: Does the synchronization potentially overwrite a manually entered value? Does the synchronization
flag always correspond to the expected value?
• Catalog structure and synchronization—the catalog structure needs to consider the synchronization process—a very complex
catalog hierarchy with many table joins can impact the performance of the synchronization process. Testing the sync process
with catalog extensions is a very good way to ensure proper performance of the catalog update process.
• Having multiple synchronizations in the system: are they truly independent or does an item from one catalog version make a
reference to an item in another catalog version? Is there any attribute that needs to be updated via multiple synchronizations?
If the proposed solution is not trivial it is highly recommended to do a proof of concept on the chosen synchronization strategy
to understand potential side effects. Again, having a representative data set to test with at this stage will allow for meaningful
evaluations and decisions.
5.1.6 Workflows
Managing products in the systems typically requires a defined approach regarding what should be done when and by whom. Who
needs to approve content updates? The approval process can use the hybris delivered workflow engine and templates. However
even if the engine is not used, the workflow should be clearly described to allow business users to understand their future
responsibilities.
The discussion should cover workflows for specific use cases, as well how to enforce these workflows using the workflow engine.
The functional specification should also discuss access rights to catalog versions, synchronization process, languages and
different type attributes.
Discussions and specification of media management are somewhat similar to the discussions of the product management. As in
the product management we need to understand how will be the media imported, structured, managed and synchronized in hybris.
The hybris Multichannel Suite supports media files of all sorts. A medium can be basically anything that can be saved on a file
system, such as a Flash animation file, a JPEG image, an MPEG video file, a CSV file, a text file, an XML file, etc.
Discussions regarding Media management and performance should also include options for distributed Media management tools
using a content delivery network (CDN) solution such as Akamai.
The file referenced by the media item is managed by the hybris Multichannel Suite MediaWeb. Where the MediaWeb actually keeps
the files (in the MediaWeb itself, on the local computer, on a network share, etc.) is not significant in this case.
Media items need to reference their file via an URL if the file is somewhere outside the hybris Multichannel Suite MediaWeb,
such as:
• An image database
• A Media Asset Management system
• The classpath of a JAR file
• The webserver cluster
On top of these requirements the media discussion needs to cover the following topics:
• Where will the media stored? In hybris locally or outside hybris? What technology will serve media requests? hybris provides
a wide selection of media management as well as media storage and there is no one best solution that fits all projects.
• Are there any specific requirements around managing access to media (think authentication and authorization)?
• How will the media be assigned to the products? Automatically? Using a Digital Asset Management system? Or will the relation
be simply imported?
• Is there any need for media manipulation, such as resizing, watermarks, etc.?
• Is there any need to support multiple media formats, such as for different landing pages?
• Is there any need to support multiple media channels?
Some projects start with single currency, language and geographic location in mind. However it is important to understand
business potential and to not lock the system into this initial configuration. The functional specification should keep options open
for adding multiple languages, currencies or locations.
Some projects work with requirements for internationalization from the very beginning. The functional specification should
describe how the internationalized content is to be managed. Multiple teams in different geographic locations need to agree on the
level of autonomy as well as content approval strategy.
Internationalization can bring complex issues to the table. For example, product availability, legal implications, and distributed
system deployment can vary across the globe.
Internationalization in the hybris Multichannel Suite is language- and country-specific logic that is independent of the operating
system. It is related to:
‘Locale’ refers to settings related to the language and region in which requests are responded. Localization in the hybris
Multichannel Suite is the logic used to fetch a locale-specific resource (String or ResourceBundle), which is used to present
region-specific content to the outside world.
Localization and Internationalization in the hybris Multichannel Suite is not limited to just switching between different languages,
but also takes into account:
• Language-specific values: For every individual language, it is possible to specify a value for:
5.1.9 Multisite
With hybris you can run multiple sites from one hybris installation. It is important to understand how much of the content will be
shared across multiple sites, what is the impact on the catalog structure and the overall content management.
hybris handles internationalization concerns very well. A typical requirement for multi-country and multi-channel sites is that
they must allow for different product assortments (different products being offered in different locations at the same time). The
standard solution would be to create a new catalog for each country-catalog combination. This quickly leads to exponential growth
in the size of the database (as each new catalog is a copy of the original), which for many customers will lead to performance and
maintenance issues.
hybris offers a different approach to the problem that allows us to use just one Product Catalog (single source of truth) with just
two copies of the Product (staged/online).
Some requirements discuss spawning multiple sites at run time. It is important to have business processes defined, understand
the impacts on back end management systems as well as web servers and network infrastructure in general.
Apart from the differences in product and content data between sites, consider functional differences as well. One typical area is
the checkout flow, which can be country-specific based on legal or business operational requirements.
The multisite functionality could also help you to implement vanity domains hosting a personalized microsite.
In PCM/MDM implementations, the data needs to be syndicated to several output systems. This can be a very complex topic and
the following areas should be discussed:
• What is the desired timing, exported item instances as well as exported item attributes. Also incremental / batch exports
should be discussed with respect to data consistency and performance requirements. Special attention needs to be paid to
incremental removes, as they could require storing foreign keys in the target system.
• Use technologies for the purpose: data extracting and manipulating.
• Data versioning. Does the downstream system require different data versions? For example, a print version could differ from
web version
5.2 Search
hybris’ external as well as internal user searches (such as searching for customers and products in the Customer Service Cockpit)
includes search functionality that helps customers find their merchandise. Search engines provide the search functionality and it is
important to verify selection of the right search engine to ensure, that the engine features match your business requirements and
expectations. The most common search engines that hybris works with are Solr and Endeca. In fact, a version of Solr is included
with the hybris platform.
Keep in mind, since product data is rendered via the search engine and search engines index the data for display, your product
display will only be as current as your most recent index update. Thus a strategy is required with your product content owners to
determine when they will be updating the product catalog and how often the search index needs to be updated with new product
data. This can also impact the performance of your website depending on your caching strategy. Other aspects to consider are
externally aggregated data sources, such as ratings, review comments or popular products. Should these be included in the index
for search, display or even sorting?
The single most important decision on the index data model is what a record in the search index represents. The selected solution
should include an analysis of the performance implications as well as desired category landing page appearance.
The content of a category-landing page is typically rendered from a search result data for performance reasons. The search
engine needs to contain both attributes, which will be used just for rendering and facets, which will be used for refining a given
set of products. The functional specification should describe these properties and facets of the search engine and their domains,
which could be ranges (e.g., price range $5-$15).
It is also important to find out how is the data stored in the product content management system, and how it will be exported. Some
data could be exported using hybris value resolvers, while some would require a customized resolver (e.g., retrieving usage data
from an analytics system or external review data).
5.2.3 Filtering
The solution typically does not need to display all items in the system; some should be filtered out. For example, hybris filters out
of box all the unapproved products. The specification document should describe any additional required filtering and a technical
approach. The technical approach should discuss all the aspects of the chosen solution including performance, data size,
rendering, and customization effort.
The search result could be sorted in a user-specific way, which will help merchandisers promote some products over the others.
Similarly, boosting moves results up and down within the search result set according to the predefined rules. It is important to
understand how much business users wants to set and leave this functionality at project time and what would be modifiable at run
time. While business users prefer as much flexibility as possible, on the other side of the equation are either expensive queries or
extensive customization. The functional specification should aim at finding the optimal balance.
Merchandisers have the capability of boosting some products at run time to get them higher in the search results, or alternatively
to do the opposite and bury the product down in the list. If search result tuning is very important for your project we recommend
paying special attention to the selection of the search engine. Each engine provides different capabilities to influence such tuning.
The search engine typically provides additional functionalities, such as type ahead (typing suggestions), synonyms (aliases for
search keywords), stopwords (words not used for search) and keyword redirects (takes users directly to landing page instead of
search results page).
While the values needs to be initially set during the project, it is also important to provide a strategy for updating and managing
data in a long run. Each search engine provides a different set of business tooling.
The search engine works with the items provided at export time. The functional specification needs to discuss how to handle
product variants (i.e. different SKUs, color, size, etc.). There are generally three options:
The selected solution should include analysis of the performance implications as well as desired category landing page appearance.
Each project needs to aim at having data in the search engine consistent with data in the product content management system.
The functional specification needs to describe timing and exported items of full, incremental and delete exports. On one side
of the balance is typically almost perfect consistency, while the other side of the balance has performance implications and
implementation effort.
One approach is to fetch time sensitive values from the product content management store or application business logic, however
performance implications as well as additional caching needs to be considered.
Many projects, especially B2B commerce projects regularly work with attribute values dependent on a session context. For exam-
ple, there could be different product prices for different users. This raises a very important question: what attribute values will be
exported to the search engine? And consequently what attribute values will be displayed on the storefront search result page?
The functional specification needs to find the right balance between business requirements, manageable data volumes and
desired speed of rendering of a search result landing page.
For production environments it is recommended to set up an external Solr cluster. External in this context refers to a deploy-ment
of two or more Solr instances in their own Java Virtual Machines (JVMs). This follows best practices for:
• process isolation, in that now the JVMs can be tuned independently from the application server JVMs
• fault tolerance by having more than one Solr slave serving search requests, and
• search scalability, since each index replica uses the same search index for search queries.
This is set up in a traditional way with Solr in a master-slave configuration, where the master instance is only creating the bina-ry
search index, and the one or more slaves periodically checking for and replicating the latest search index. A more flexible and archi-
tecturally more desirable approach is the use of SolrCloud. Here, a search cluster consists of one leader and one or more replicas.
The important differentiation is that the roles of master and slave are determined at runtime - typically startup order - and can/
will change over time. The current leader will perform indexing and index distribution, and all replicas will serve frontend search
requests. This setup is in contrast to the master-slave configuration, where the roles are fixed by configu-ration in which a master
will always be a master, and a slave always a slave. SolrCloud further decouples the frontend and search subsystems and allows for
a fluid topology change if/when needed. This can be the case of an outage, a scheduled maintenance or increased capacity needs.
With SolrCloud it is also noteworthy, that the schema and other configuration files are hosted by a central repository called
ZooKeeper. ZooKeepers maintain the cluster state and keep track of:
Note: that with hybris 5.2 SolrCloud is not yet fully supported.
5.2.11 Internationalization
Because some of the data exported to a search engine is localized, you will need to pay additional attention to the following:
Every search engine deals with internationalization differently. It is important to have a discussion to analyze and describe the
selected solution with possible impacts on business processes and the technical implementation.
The Accelerator is a reference implementation of a web storefront as well as a reference implementation of a rich set of services
enhancing the hybris platform commerce functionalities in areas like search, cart manipulation, and order fulfillment. The typical
tasks in this stage of the project include:
While analyzing the storefront channel (web channel) the first discussion should include a detailed gap analysis against the hybris
Accelerator and deep understanding of its architecture to make a very important decisions about how much of the code will be
based on it.
Regardless of the use of the Accelerators, the next steps in the functional specification should include:
For those using the Accelerators, the next steps in the functional specification should include:
• Understanding what content will be managed in content management system (CMS) out of the box, and identifying any
additional content that needs to be managed in CMS. Understand what content change will require a development effort.
• Understanding how mobile and desktop web channels are managed within CMS. For example, some changes require two
modifications and some changes can be made in one place only.
• Specifying customized CMS components
When defining the strategy for the structure of the WCMS managed pages, it cannot be stressed enough to carefully find the
optimal balance between CMS components and JSP tags. Keep in mind that each CMS component will incur an internal server call
(besides the initial request from the user), a database access, and potentially a limitation of the deployment table width in the data-
base. The latter is only an issue with MySQL’s InnoDB and manifests itself in the database error “Max RowSize Limit Exceeded.”
A good and prudent question to ask when deciding which parts of a page need to be CMS components vs. JSP tags, is:
Answering this, however, with “everything” will set up the project for major refactoring later when the performance is sub-optimal
or database problems arise.
Also, some of the Accelerator functionality may not be needed in your solution. Do not forget to remove unused functionality such
as included JavaScript libraries and tags, unused attribute values in DTOs and populators, unused Solr fields.
The Accelerator templates are widely accepted by majority of our customers. A good justification should be given in case your
project does not plan to use it. The main advantages of the Accelerators include:
If the project will not reuse the hybris Accelerator, the required functionality needs to be compared against the hybris platform
functionality and the gap should be specified. Also, special attention needs to be given to the choice of the front end technology,
software architecture and design patterns used.
After the architectural choice to use the Accelerator has been made, one of the first steps in the definition of your website is to work
with the marketing/business users on the visual design of your site. Sometimes a UI/design agency (they can also assist with your
branding) is called in to assist with this part of the project. This process will define the following for your website:
It is very important for your developers to have a solid understanding of what the inputs and outputs are to your website in
order for them to build correctly to specifications. This process can be very time consuming, but is a very important input for
your Java developers.
1. Website wireframe
2. Visual elements
3. HTML Prototype
4. JSP Page Development
Your website wireframe connects the underlying conceptual structure, or information architecture to the surface, or visual design of
the site. Wireframes help establish functionality, and the relationships between different screen templates of a website. An iterative
process, creating wireframes is an effective way to make rapid prototypes of pages, while measuring the practicality of a design
concept. Wireframing typically begins between “high-level structural work—like flowcharts or site maps—and screen designs.”
Visual design then takes your complete wireframes to the next step by adding elements of color, font, style, icons, etc. to provide
the visual elaboration of what your website will look like. This typically includes the use of Cascading Style Sheets (CSS) which are
essentially a repository of standards (fonts, colors, etc.) that are used across your website.
The HTML prototype then takes this as input and creates a “clickable UI” that can be displayed/demo to the business users that
Your web (Java) developers will then use the HTML as input to building your website JSP pages. Once this process is complete it
is no longer a simple task to make changes to the look and feel of the page originally provided in the HTML file. That is because
these elements are now intertwined with JSP logic necessary to render the pages dynamically. This is important to understand, as
making changes at this point can extend the duration and cost of the project.
Following these guidelines will help your project minimize changes later in the project, which will help to keep your project on time
and on budget.
Mobile devices could serve the content in two ways: as a web application optimized for mobile devices (see 4.3.1) or as a native
application. The discussion should find all the arguments for both web and native channels for mobile devices. The functional
specification should also name all supported operating systems (including those from different vendors as well as different OS
versions from each vendor) – for example Apple’s iOS or Google’s Android.
hybris comes with several examples of a native mobile application including the source code. Similarly to the hybris Accelerator, it
is recommended to perform a gap analysis to determine whether the example application could be used for further extension, or if
it should be merely a working example of an example storefront. The application architecture should be also discussed.
If the storefront technology is not JVM based, or if the JVM is different from the Tomcat container, there is a need to connect to the
hybris content storage and commerce services. The hybris commerce web services offer a set of REST services for this purpose.
First we need to analyze what services the client expects, followed by a detailed gap analysis against the hybris commerce web
services to understand the API. The resulting technical specification will contain what additional services need to be exposed,
modified or eventually even implemented.
One page impression handled by the storefront could generate more than one request to the hybris commerce web services.
It is recommended to analyze the performance implication of this architecture as well as well the desired authentication and
session handling.
Utilizing addons is a best practice approach for customizing the Commerce Web Services. Direct changes to the generated web
services extension could lead to poor upgradability, and a separate extension would lead to complex session management and
authentication issues on the storefront.
Similarly to the other channels and functionality in general, this phase includes business functionality and user experience gap
analysis against the in-store module.
The print channel requires a deep understanding of a very specific publishing process. The technical specification should include a
mapping of the publishing process requirements to tools used in the solution, namely:
The Customer Service (CS) channel requirements overlap to some extent with the front end requirements. The functional
specification needs to map business requirements to the following three technologies:
• Customer Service (CS) Cockpit as the standard tool for customer service representatives
• The hybris management console (hmc) for selected admin tasks
• The front end (using impersonation techniques) for any front end specific requirements
The discussion should also include any specific requirement to the order fulfillment process. An example could be a specific return
or replace order, appeasements, rush orders, special order handling (such as wrapping), etc.
Note: the CS Cockpit does not “inherit” your custom website cart, checkout and other custom website components as it is a pre-
built UI. If your implementation requires the same functionality for the customer service representatives that your end customer
sees, there will be customization(s) required for the Customer Service Cockpit.
5.4.1 Prices
There are always two aspects of price: what is displayed on a product detail page or cart, and what is used for cart calculation. In
very simplistic scenarios these two are exactly the same, however the business needs usually bring additional requirements. The
functional specification should map these requirements to the appropriate technologies:
• Standard price is the price assigned to a product (could differ based on the ordered quantity)
• Standard price / your price displays two prices, typically in apparel stores
• Discount can reduce the price without any further restriction
• Promotion can reduce the price if a business condition is met (for example the total order price is above a threshold)
• Voucher can reduce price if a voucher code is explicitly set by a customer (the customer has to type a voucher code
during checkout)
The functional specification should also describe supported currencies and pricing strategies. There could be different prices
set for different currencies, or perhaps the requirement is to compute the price based on a set exchange rate to a predefined
base currency.
Another area to discuss is price alternations for specific users or user groups such as custom price lists and B2B prices. The price
on a product detail could differ from the price in search result / search facet as was already mentioned in (5.2.8).
The inventory is a special product attribute that changes frequently. A typical implementation takes the following aspects
into consideration:
• What is the master system for inventory? How often would the inventory be updated in hybris (usually very current)?
• Do we want to implement reserve / release functionality? How will we make sure that reserved stock
• is always released?
• Inventory changes very often. Do we want inventory to have effect on search result pages?
• Do we need to override values, such as forced in stock, forced out of stock?
• Do we support pre-order?
• Is available to promise an option?
The cart requirements should find a right balance between business needs and customization effort in the following areas:
• Persisted cart rules—when is the cart persisted and when is the content retrieved back to the session. Additional discussion
should cover logic for clearing abandoned carts as well as merging cart content in case a customer logs in. The merging
strategy could take product availability or other business conditions into consideration.
• Wish lists—what is a wish list from the business perspective and what is the relation to a persisted cart. A typical discussion
covers the following topics: Is the wish list public? Is the item on the wish list moved or copied to the cart? Is the whole wish list
convertible to a cart and vice versa? Are multiple wish lists desirable? Is the wish list different than a gift list?
• Multiple carts—is there a business need for multiple carts? The technical specification should describe the intended
technical approach.
• Promotions—cross sells/upsells.
The platform and the Accelerator provide many services and several implementations of the checkout process. These include
single page checkout, multi-step checkout and multi-step checkout with a hosted order page. The desired checkout strategy
should be selected for every applicable channel.
The specification should also include requirements for guest checkout and a need for user registration.
Some B2C projects create sites that only accept credit card payments. However, the business needs may be much wider than that
for example:
The credit card information requires protection and that could be subject to PCI compliance requirements. The compliance
requirements could have a significant impact on the implementation, architecture and surrounding processes. The functional and
technical specifications should make these impacts explicit.
The gap analysis will identify what options and their combinations are available and required. The discussion should include
estimation how difficult it is to configure or implement the missing functionality. For example, the requirements for delivery
options could include several options such as standard shipping and express shipping. Shipping prices can be calculated
automatically based on distance and product size and weight. Having multiple shipping warehouses adds to the complexity. The
requirements could also include a free shipping option via promotions. Hazmat products and military shipments APO/FPO require
special shipping arrangements. In the omni-channel scenario, the delivery options would also include in-store pickup.
Site internationalization could bring additional requirements, such as increased shipping fees or shipping constraints (e.g., no
shipping to North Korea).
Integration to the shipping service’s website is needed to allow customers to track their shipments from your website.
• Payment provider—authorize, capture, refund and similar services using credit card information
• Tax calculation—tax calculation for US and Canadian jurisdictions. VAT (Value added tax) calculation services are usually
implemented separately.
• Address verification –verification services could differ from country to country
• Fraud check—helps to flag a suspicious or fraudulent order
• Stock level—provides product availability across multiple warehouses and stores
• Order splitting—splits the order according to business requirements such as shipping proximity, product availability,
minimizing number of packages, flattening out stock levels or workload and so on.
• Order management—organizes picking, packing, labeling and shipping of each order
• Shipping—provides shipping methods, labels and fees for different shipping providers (UPS, FedEx, etc.)
• Geo-location—will find a geo-location (longitude and latitude) for an address and vice versa.
A typical commerce site implements several order fulfillment processes, such as:
The customer should be able to look up where there order is in the fulfillment process based on the order status. Once it has been
handed off to the shipping service, the customer should be able to track the shipment with a tracking number.
Solution architecture puts all the hardware components together to support the designed functionality. The solution architecture
needs to discuss:
• Servers (application servers, web servers, search engines), including clustering and replication mechanisms
• Storage (database, media storage, content delivery networks) including clustering and replication mechanisms
• Connectivity (networks, demilitarized zones [DMZ], firewalls, load balancers, integration points to external systems like DAM,
backend ERP systems, payment gateways)
• On-demand services (commerce infrastructure services)
• Core+ components and their specific needs for scalability and connectivity
• High availability and scalability of all components
Once the solution architecture is created, the configuration needs to be supplied so the environments can be built. Generally the
system admin team, network management team and project team need to collaborate to specify the:
• System configuration (such as app servers, web servers, load balancers, SMTP servers, FTP servers, File synchronization,
access rights, solution monitoring)
• Network configuration (such as IP addresses, DNS records, NAT configuration, access rights, network monitoring)
5.7.3 Environments
The general solution architecture is typically similar for multiple environments, while the configuration would differ for each. The
desired environments could vary from project to project and, a typical setup has four environments:
System administrators would take the initial configuration and create environments before or during the engineering phase,
as needed.
Commerce projects, as well as content management projects, specify various requirements for reporting. The initial analysis
should discuss the areas for reporting:
• What are the needs for reports from data stored in a (relational) database? (For example, “What is the number of orders over
$100 in the last month?”)
• What are the needs for reports from customer interaction? (For example, “What is the percentage of visitors who placed an
order last month?”)
• What are the needs for reports of an omni-channel customer journey? (For example, “How many customers bought something
online when they previously selected something in-store?” or, “Track the usage of QR codes placed in a specific store.”)
• What are the needs for enterprise reports combining data from various sources? (For example, “What is the achieved average
margin on products in the last month?”)
A process needs to be in place to extract the data from the database and load the data warehouse for reporting.
5.8.2 Technologies
At this point, the reporting technology could be already preselected. It is important to verify the fit of the technology to the business
requirements and make adjustments either to the business expectations or selected technologies. While verifying the fit of the
technology, several other aspects should be considered:
It is not a good practice to run queries against the production system, for risk of performance degradation of your
live website.
While the selection process is never easy, it is critical, as it will have a big impact on project scope, project success (from the
business and usability point of view) and solution upgradeability.
If your customization requires just a display configuration (hmc.xml or cockpit xml snippets), it is always highly recommended to
provide the configuration as long as the corresponding extension (hmc, cockpits) is included in the project extensions.xml file.
Individual requirements for backend systems should have been covered in the individual domain specific area.
Solution Architecture Workshop - The Solution Architecture Workshop aims to provide technical information to allow architects
and developers to design a system fit for its business purpose and implement hybris best practices. This workshop might be
requested by a client during the exploration phase. The most value will be realized if this workshop is conducted before design or
implementation work has started. hybris first performs a review of the requirements to gain a clear understanding of the solution
needs, then helps align requirements to core platform functionality, identifies areas in which customization may be required,
contributes their product knowledge, and suggests proper extension usage or customization according to best practices.
Solution Architecture Review - hybris performs an analysis of the technical design specifications for completeness and alignment
with hybris best practices. The review focuses on integration specifications, custom code specifications, data model design, and
upgradability. This review is typically performed immediately after the conclusion of the technical design phase and before coding
begins. hybris also evaluates the architectural design of the most important components of a site to ensure best practices. An
optional Source Code Review may be conducted to analyze code/configurations for best use of hybris APIs, and for general Java
best practices.
hybris/Endeca Integration Workshop - This one-day workshop provides customers and partners a technical exploration of the
data integration options between hybris and Endeca, as well as front end integration options with or without Page Builder (a.k.a.
inFront Assembler). At this workshop, hybris consultants will provide information on the subject matter and best practices from
the field. The workshop can be conducted on-site or remotely. It is the responsibility of the client or partner to implement the
activities outlined during the workshop.
• Develop and unit test the solution, maintain initial data set, provide mock implementations for various integration touch points,
and implement user interface (UI)
• Deploy the solution on test environment and pass integration, performance, security and acceptance tests
• Data cleansing
• Write user guides and deployment guidelines
6.1 Architecture
The software architect should already have a good idea about the planned architecture from the exploration phase. The exploration
phase usually covers the most intricate technical aspects of the planned solution, and now is the time to provide all the details. The
detailed architecture should be clear and unambiguous for developers who will develop the solution.
It is a best practice to utilize industry standard design patterns as well as naming conventions. This will enable unambiguous
discussion about the software architecture with internal and external stakeholders, including eventual new members of the
team. It is recommended to discuss the architecture and its limits with the development team to make sure that the solution is
understandable and optimal.
The architecture and design should be the last occasion to refine and confirm technologies and libraries and how they will be
used in the project. For example, the architect should decide when and where inventory checks are performed to ensure product
availability.
6.1.1 Maintainability
Project maintainability should be one of the non-functional system requirements. The software architecture has the biggest
impact on future maintainability of the code. We can achieve maintainability the following way:
• The architecture should aim to create modular, reusable, replaceable units of code
• Minimize customization of deprecated code. The hybris framework is constantly evolving, so some of the concepts and
development approaches become obsolete while new technologies keep emerging. Make sure your architecture is aligned
with the hybris product roadmap. Sometimes it is advisable to wait for a new hybris release. If waiting for new technology is not
acceptable and the project is forced to use “soon to be deprecated” technology, it is important to document the decision and
provide approach for eventual future upgrade.
• Minimize a need for refactoring big portions of the original code. As hybris constantly releases patches and upgrades of the
existing stack, it is desirable to make the upgrade path as smooth as possible. The architecture should follow the following
principles:
»» Always use your own extensions for modified code. Never touch the shipped code even if you have access
to the source code. The recommended approach is to extend both interfaces as well as implementation
classes and replace the out-of-the-box functionality when necessary.
»» Do not copy and paste content of a whole class. Consider extending the original class and overriding
functionality you need.
»» Choose decoupling over extending where possible. For example, if the new functionality is functionally
decoupled from an out-of-the-box service implementation, it is always better to delegate calls to the
untouched service rather than extending it.
»» Keep Accelerator modifications at minimum and use the AddOn and bean generation functionality
where possible.
»» Expert customizations of cockpits
[https://wiki.hybris.com/display/release5/cockpit+Extension+-+Technical+Guide] are known to depend
on large portion of the original code. Try to avoid them if possible.
Besides the project itself, the developer typically needs more tools for daily work. A document should describe all the tools (and
their versions), libraries and their dependencies:
The advanced personalization rules can have a significant impact on application performance. It is always good to understand the
volume in which the advanced personalization will be used and scale the solution accordingly. Try to use CMS restrictions as an
alternative when possible.
The data validation framework allows adding validation rules at run time, therefore making it a powerful engine. An interceptor
on model save operations invokes the validation framework, so only save operations managed by service layer are validated. The
classification attributes are persisted dynamically across several tables and therefore data validation of classification attributes is
not easily achievable.
Note: Data conversions can sometimes take more time than anticipated if the existing data needs to be cleaned up or is not in a
format that can be easily converted into a logical structure for import into hybris. Make sure your current data structures are
investigated early in order to avoid delays at the end of the project due to data conversion issues.
• Local developer’s instances are typically deployed directly from compiled source
• Code into the development environment is typically deployed from compiled source from versioning system
• Code into the staged environment is typically deployed from development environment using ant production
• Code into the production environment is typically deployed from staged environment using ant production
• All data before going live should be stored in impex files or generated programmatically using “create project data” or “create
essential data” hooks
• All data after going live uses project-specific integration
• If there is a need to initialize a database after going live, use the automatically generated impex file as a starting point
Every team lead and software architect must be aware of typical project pitfalls. There are numerous platform version-specific
anti-patterns documented on hybris Wiki and Jira. Consider a solution architecture workshop in case of doubts.
6.4 Development
The development phase implements the functionality on local environment according to the software architecture. This is the most
visible part of every project and should be familiar to all stakeholders. hybris recommends periodic functionality demonstration to
provide project visibility to the business users as well as to facilitate discussion between business and technical teams.
Special considerations for some selected aspects of a typical hybris project implementation:
Ideally, the data structure is defined in early stages of a project. However, even the best projects could run into a situation where
data initialization is needed in a later phase of the project. The re-initialization will essentially remove all the project data created
so far. Since the re-initialization cannot be avoided, it is recommended to store all the data in the form of impex file, or generate it
6.4.2 Backend
• Do not forget to take care of border cases (null arguments, empty lists, specific subclasses); it is recommended to
code defensively
• Implement corresponding unit tests and consider using test driven development
6.4.4 Cockpit
hybris supports many integration patterns, as it is built on Java. Typical integration is implemented using impex and REST web
services, however there are also modules and projects using spring integration or jms. While choosing the optimal technology for
your case it is good to focus on:
• Data volume
• Real-time, near real-time, and offline exports
• Full exports or incremental changes
• Caching
• Error handling
• Maintainability in future
The code should adhere to the established PMD rules and general coding best practices discussed in chapter 3.7.
The hybris Professional Services code review package provides another set of eyes over the code. A hybris consultant would verify
that the implementation:
6.5 Data
The development phase not only provides executable code, but also supporting data. Typical data contains:
• Project-specific configuration (e.g., Solr export configuration, scheduled cronjobs, access rights, user groups, currencies, and
catalog structure)
• Mock sample data (typically example data like products, media, customers, orders etc.)
configuration is tested, it is good practice to store the example data in the impex files, which will be loaded automatically during
“create essential data” or “create project data.” This will allow fast and convenient project setup for other developers, and will
provide tools for fast re-initialization of the project (e.g., if the domain model needs to be changed later in the project).
Some example data is already provided by hybris in extensions like ‘sampledata’ or ‘yacceleratorinitialdata’. However there could
be also data in every extension. If you remove an extension from your project, it is highly recommended to reinitialize and retest the
system to make sure that no required project data is missing. Avoiding this step will only postpone revelation in the event that some
configuration data is missing. Late revelation means that nobody can tell what code change caused the missing data, increasing
resolution time. For the same reason, it is highly recommended to reinitialize your local instances periodically to make sure the
data in the impex files is in sync with the code and project deliverables.
Also, do not forget to remove the unused data (such as sample products) from the system before going live.
You could also consider hybris code review, which focuses on using hybris optimally and looks for typical hybris project pitfalls.
6.7 Documentation
Software architecture and code documentation should be an integral part of the deliverable. The documentation (Javadoc) should
not state obvious things that are clear from the code, for example:
Rather, it should explain main concepts and not trivial assumptions, conclusions and dependencies.
A separate documentation should include deployment guidelines. Admin users will use these to update, patch, migrate or spawn
a new instance of the software. The deployment guidelines should focus on recommended and tested procedures to deploy
system to production in clustered environment, what steps are essential and which are optional, and in which order they have to
be executed. The same applies to all technologies involved in the project such as database servers, app servers, web servers, and
search servers.
And lastly, the implemented solution will allow creating business user guides. The documentation should capture business
processes and user stories as they are implemented. The solution allows capturing screen shots and will provide example data
loads or system configuration. Example user guides from the hybris wiki can be used as a starting point.
6.8 Testing
Testing aims to make sure that all specified functionality, as well as non-functional requirements, is correctly implemented. A good
test database with loaded data that developers can use will help with the quality and effectiveness of the code delivery. Different
stakeholders participate in different types of testing. The following set of tests is recommended for each project:
Performance testing is usually very elaborate, but there are three key factors to conducting a successful test:
• Make sure that the tested physical environment is same or very similar to the production environment. Different solution
architecture as well as different hardware configuration could easily lead to different observed performance bottlenecks and
therefore to sub-optimal configuration.
• Make sure that the testing scenarios correspond to reality as close as possible. For example:
»» Sites rarely experience 100% conversion rate. Therefore, there are many more landings on product detail pages than on
place order pages.
»» Having one user “testinguser” in hundreds or thousands of parallel shopping threads will result with hundreds of carts and
orders under one account, which is not a typical real world situation (since one customer generally would not generate all of
the site traffic).
»» Customers rarely look at only one product. Realistic variability of requests will make sure that the cache is configured
optimally.
»» Do not underestimate the complexity of the scripts. A good set of scripts could take weeks to write.
• Make sure that the hardware generating requests and analyzing responses does not become a performance bottleneck itself,
especially if we need to create enough firepower to overwhelm a clustered environment.
• Find the optimal technology. While jmeter could be sufficient for simple JSP requests, the ajax applications
(e.g., our backend systems) require browser automation tools, such as selenium.
And last but not least: performance testing of a clustered environment is much more challenging than performance testing of one
node only. Do not forget, different nodes are typically dedicated to different tasks, and each node has its own admin console with
unique sets of data. A stress test is also recommended to understand where the maximum point of failure is.
• Acceptance tests verify valid implementation of business processes, user stories and business requirements in general.
A QA team typically conducts the tests on behalf of business users. Issues that surface during acceptance testing could be
sign of underestimated exploration phase. Also make sure that any change to data configuration is properly stored in the
corresponding impex files as discussed in chapter Data earlier. The time pressure sometimes leads to developers making the
changes via the hmc only, which could be a shortsighted tactic resulting in problems with system re-initialization later on.
• Security penetration tests verify that the system is well protected from intrusion from both inside and outside. It is
recommended to have an independent trusted third party involved in the security testing to avoid a “thief controls thief”
situation, in case of rare but possible deliberate security holes.
• Every test needs a representative, complete and uniform test data. ‘Representative’ means that all types (i.e., base main
products, product variants, product families) need to be available for testing. ‘Complete’ means that product should have their
attributes properly filled (no missing product names, prices, categories, etc). ‘Uniform’ means that the same product set should
be available for each environment.
• The “big bang” approach migrates all the data at once when going live. The critical aspect of this approach is speed of data
upload, as both system need to be down during data migration. Also, this approach is considered the most risky, as it will affect
all the customers at once and the site will be hit with full traffic from the very beginning.
• The “gradual deployment” approach migrates small subsets of entities (users, products, sites) in several waves. While this
approach is less risky, it requires more development time because the two systems usually need to be tightly integrated. Also,
both systems need to be managed and supported in parallel.
In either case, the data migration needs to be developed and the development should consist of the following phases:
• Type and attribute mapping. This is very similar to product data mapping discussed earlier, however we need to map all
migrated data types (user accounts, orders, etc).
• Verifying consistent unique identifiers and data merging. If the legacy and new system have different unique identifiers it is
possible that migration would result in “duplicate rows” errors. The error resolution typically requires good and ongoing
communication between the development team and business users.
• Additional data validation and data cleansing. The new solution could contain more restrictive validation rules than those
implemented in the legacy system. It is recommended to run several dry runs to make sure that all the data is uploaded
correctly. Sometimes the dry run will identify data quality issues, which can take considerable amount of time to fix, either
programmatically or manually.
• Consider rollback strategies, particularly with the “big bang” approach in case the rollout is not successful. The rollback
strategy should discuss what would happen to all the data changes, new customers, orders and started processes between the
rollout and rollback times.
6.10 Monitoring
Prepare the system for monitoring. There are different monitoring tools and each environment is monitored differently. A typical
tool would include log monitoring, JMX beans and periodical HTTP requests to the application server.
It is also good practice to enable the hybris shipped Dynatrace monitoring functionality.
In this phase we would configure application and server log levels, enable or disable JMX polling and eventually also implement
other required JMX beans. The periodical HTTP ping request should be also configured properly, for example the ping should
reuse the same JSession on the hybris server to not pollute system with many unused sessions. Alternatively you can write a
dedicated resource, which will not instantiate a JSession inside the container.
• Planning
• Training of business users
• Handover from development to operations support and maintenance teams
• The actual go-live activities of implementation
Solution Architecture review, performance review and code reviews are recommended in this phase.
Chapter 5.3.3 discussed how to deploy code and data to different environments. (See chapter 4.7.3 for discussion about typical
set of environments on a hybris project). This section aims to describe specific activities for deploying the solution to the
production environment.
• Define an ideal go-live. Is the main aim the smallest commerce site downtime, smooth cutover for the organization, or lowest
risk of unsuccessful deployment? Is gradual deployment considered? Different priorities lead to different activities.
• Define go-live activities and responsibilities. All involved parties need to be consulted and provide resources as necessary.
Create a plan for all the go-live activities and their dependencies. Escalation activities are important as well—the right people
need to know that they may receive an urgent call.
• Consider a gradual cutover and/or soft launch. There are various strategies you can deploy to gradually increase traffic to your
new website to minimize risk. Also, a preliminary “friends and family” soft launch can allow you to see your website operate in
production to a limited audience.
Avoid go-live on Fridays or weekends, close to holidays, and near your peak volume season. While the traffic on your site may be
smaller on weekends compared to a typical week, the accessibility of key personnel to help support your launch is limited.
• Define rollback strategies in case the launch is not successful. If there is a point of no return, it needs to be well known.
Also there must be a person responsible to make a decision whether the point of no return can be crossed.
• Define the set of smoke tests. These will help to measure the progress of the go-live activities as well as trigger escalation
activities as needed.
• Define information flow (who informs who, when and how). For example, “When the tests pass, Joe calls Bill to change the
DNS A record.”
• Have a go-live checklist for the hybris platform. The checklist goes through all important settings and configuration to support
successful launch from the hybris technology point of view. Schedule time with hybris system admin specialists, who will help
you review the site for production readiness.
• Document all project relevant configuration files and their content. Update the configuration if necessary.
• Define setting and handling passwords for production systems
• Define cleanup scripts for old products, customer accounts, orders, etc.
• Define data backup and rollback strategies
• Describe data import flows
• Describe and configure log levels
• Describe and document escalation procedures
The system administrators should have a staging version of the environment, where they can test and preview all modifications to
the system.
7.3 Training
Having the system implemented, tested and documented in the engineering phase, it is a good practice to train those who will use
the system. There are three types of trainings:
• Train the trainer. If the number of business users is larger than one class, it is a good practice to have one separate session
to train the trainer. This would provide scalability by saving time of key individuals such as software architects who need to
oversee many other aspects of the deployment phase.
• Provide end-user trainings. The end-user training needs to be tailored to the project-specific customizations and is delivered
by the system integrator team. The training usually contains relevant use cases, which are taken from the acceptance testing
use cases. The end-user training should also provide all information about user guides, support processes (what to do if
something does not work), rollout strategy, current state of the project and a Q&A session.
• Provide system admin training. This training should go through typical tasks done by system admins, such as setting
passwords, and navigating in the admin console and the hMC. The training should also cover monitoring, deployment
documentation and system maintenance discussed in the earlier chapter. Dynatrace is the monitoring tool offered and
integrated with the hybris platform, however final monitoring tools are usually project- (or rather infrastructure-) specific.
As mentioned above, going live is potentially risky operation, so it is recommended to have proactive, hot standby support during
the initial days of operation. “Hot standby support” means that there is somebody responsible from the project team participating
on proactive monitoring of the system, and all its vital indicators. He/she is responsible for resolving the issues or immediately
delegating tasks to responsible persons if the situation requires different competence. A responsible person also communicates
the list of discovered and observed issues to project management, and participate in issue prioritization.
The hot standby phase usually ends when service-level agreements are fulfilled, but not earlier than 24 hours after go-live.
7.5 Debrief
The project team should debrief and summarize the project to discuss what went well and what could have been done better. This
evaluation should be done from at least the following points of view:
• Is the customer happy? (Does the customer have what they asked for within the budget?)
• Is the finance manager happy? (Was it a profitable project?)
• Is the project team happy? (Is it a sustainable project?)
• Is management happy? (Were there only a few escalations?)
• ensuring the availability of the application as agreed upon in the Service Level Agreements (SLAs) between the end customer
and application support team / operations & hosting team
• reporting on encountered malfunctions and their resolutions
• patching and maintaining the system
• maintaining system configuration and maintenance documents
• maintain communication with hosting team(s).
8.1 Monitoring
Having monitoring in place enables proactive and faster resolution of many issues. The effective monitoring requires:
• proper SLA with application support team and hosting teams in place
• monitor logs and proper use of resources (CPU, DB, Network, disk space)
As the traffic, data volumes, managed data and functionality change over time, it is essential to keep and improve the ongoing system
monitoring based on your experience.
Members of the project team should continue to monitor user satisfaction and system performance for a few months following
production cut-over. Project team members should be available to address areas of frustration or difficulty experienced initially by
the users. Keep in mind that the learning curve is quite steep and that frustration is typically the result of a lack of understanding.
Continue to work with the users and offer suggestions on how to maximize system usage.
Generally, support will help to resolve issues connected with the hybris platform. Project-related issues should be resolved with
the implementation partner or with hybris Professional Services on a case by case basis. If the nature of the issue cannot be easily
or clearly identified, it is recommended to contact hybris support team, who will help with issue analysis. The ability to recreate
the issue is critical to helping to diagnose and resolve the problem.
Some incidents may require opening a hybris support ticket; see the above section ‘Contacting hybris Support’ for the correct way
of doing it.
• Identify your strategy for upgrading to the latest release of the hybris suite (e.g., upgrade to every third minor release)
• Make sure that your solution sizing correlates with the expected incoming traffic. Starting a discussion about adding additional
nodes two weeks before Black Friday could be too late
8.6 Documentation
When the functionality, configuration, use cases and environment change, so should the documentation. The key aspects are:
As a result of the implementation of a new hybris site, custom code and interfaces should be documented and procedures should
be written to describe the timing of updates, data loads, etc. In addition, maintenance policies and procedures may be affected.
• Introduction
• About this Document
• Related Documents
• Project Description
• Product Requirements (reference to)
• Server Software
• Client Software
• Supported Browsers
• Names and Passwords
• Nightly Data Migration
• Data Architecture
• Naming Conventions
• Before Data Migration
• During Data Migration
• After Data Migration
• Collecting Data
• Content Deployment
• Setting up the Staging Environment
• Setting up the Production Environment
• Troubleshooting Data Migration
• Soft Failure
• Hard Failure
• Installing the Web Server
• Installing hybris
• Module Directory Structure
• Build Structure
• Working with the Content Management System
• Workflows
• Installing a hybris build on a Staging or Production Server
• Running the Website
• Starting and Stopping hybris and the Website
• Configuring the Website
• Maintaining Servers
• Load Management
• How much does the intended business process overlap with hybris functionality?
• Does the platform require significant customization to accommodate and adapt to the requirements? If so, how much effort
and complexity is involved?
• Conversely, can the business processes and requirements be modified to adapt to the platform?
• Who will be responsible for mapping the requirements to make sure that the business processes are implemented while the
customization stays within budget and is easy to upgrade in the future?
Over time, the business processes and platform capabilities become clearer to each other. Who will be responsible for facilitating
and streamlining this discussion? This process contributes to the majority of earlier unforeseen requirements. The goal is to
identify all unforeseen requirements during the exploration phase and avoid new unexpected requirements being discovered
during the engineering or deployment phases.
The hybris Requirements Workshop package can facilitate and address these situations. hybris Certified Consultants can facilitate
and assist with the workshop to ensure that the requirements are identified and fully align the capabilities of the hybris platform.
Consequently, there is a high risk that exploring all the areas and endless possibilities will introduce more requirements
leading to increased scope, while the budget and timeline stays the same. Requirements prioritization is recommended in the
exploration phase.
hybris 5 Documentation:
https://wiki.hybris.com/display/release5/Release+5+Documentation+Home
hybris Training:
http://campus.hybris.com
hybris Certification:
http://campus.hybris.com/Categories/Certifications/c/certifications
hybris Downloads:
https://wiki.hybris.com/display/downloads/Download