Hybris bestPracticesGuide R21

HYBRIS
PROJECT
BEST
PRACTICES
JANUARY 2015
HYBRIS PROJECT BEST PR ACTICES | 1

1 Introduction..................................................................................................................................2
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
1. INTRODUCTION
Congratulations on your selection

of hybris software!
hybris was founded in 1997 with a simple mission: to create superbly engineered commerce solutions. Over the years, what
that means has evolved—multichannel, open standards, high performance, data centricity, customer centricity—and so our
company and products have adapted. But our mission has remained the same. We are, above all, a great commerce technology
company. hybris Professional Services has been working with customers and partners to design and implement solutions
based on hybris technology.
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.
We are committed to the following:
• 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
2 | HYBRIS PROJECT BEST PR ACTICES

The following topics are beyond the scope of this document; however direct conversations with our Professional Services team will
advise you:
• 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.
hybris Toll Gates

To help prepare you for your implementation and to avoid common project pitfalls, hybris Professional Services has introduced the
concept of hybris implementation “Toll Gates.” Every implementation team faces time pressure and technical challenges, but in
our experience the most common and obvious difference between successful implementations and those “at risk” can be traced to
skipping steps or failing to validate work at the right point in the implementation. A roadmap with a highlighted trip route is a good
analogy for project plan and timeline documentation. Toll Gates take this analogy one step further by recommending the placement
of virtual gates in the project plan/timeline where teams check to ensure they have completed the work (paid the tolls) to ensure
project success before they move on. Some of these tolls are as simple as confirming check list tasks have been completed, while
others may involve special implementation tasks in themselves which, when performed correctly and at the right point in the
implementation, can save costly rework, delays and frustration.
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]].

About the authors
This document was created and is maintained by hybris Professional Services. We have worked with hundreds of customers to
successfully implement hybris software, and we help our partners and customers with everyday project tasks. hybris Professional
Services is here to:
• 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.

2. BEFORE YOU BEGIN
Setting your hybris project up

for success before you begin
implementation—Are you ready?
The amount of complexity to implement the hybris commerce suite should not be underestimated. A surprising number of
e-commerce implementations begin without clearly defining the organization’s vision for a successful outcome and who is going
to be involved (and when). These organizations are simply not ready to begin. Typically, they lose weeks or months resetting
expectations, redefining their projects and addressing the frustrations of their stakeholders. Sometimes they run out of time or
other resources and end up going live with less than they hoped. This can be avoided; there is work to be completed before the
implementation can begin. Given the amount of time and money your organization will be investing, hybris strongly recommends
starting your project with the best possible foundation of vision and resources. Before you begin, take extra time to ensure three
pieces are in place:
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.
2.1 Defining Your Strategy

Having a clear strategy is one of the most important ways to ensure a successful project. Strategy needs to be defined in terms of
expectations of success and shared with the implementation stakeholders so there is a common understanding and motivation.
hybris Professional Services have been brought into “off the rails” projects only to discover it was never clearly defined what was
trying to be accomplished or what defined success. Again, these organizations were not ready to begin.
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.

Here is a list of recommended Before You Begin questions to help assess if your organization is ready to begin planning a hybris
implementation:
• What is your vision?

• Who are your key stakeholders?
• What are your project’s goals and objectives?
• What will define success?
• What are your pain points?
• Do you have any target metrics or KPIs?
• What is your change management strategy?
• Does your organization have the required skill set?
• Have your requirements been documented?
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.
2.2 Building Your Team

Next to strategy, your people and internal team structure is the second important factor when undergoing a commerce project. It’s
a very common project pitfall to begin a hybris implementation before adequately predicting requirements of new skills and new
roles both during the implementation and again as the organization shifts from construction to go-live to operations. Avoiding this
requires predicting business and technical skill requirements and role impacts before you begin your implementation, and building
your business and technical teams accordingly.
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?

• Do products have a natural categorization and association (cross-sells), or is intervention required to build categories
and associations?
• How dynamic is your inventory? Do you have products that are frequently out of stock and not available for purchase?
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
Marketer Responsible for generating email campaigns, promotions, and sales.
Merchandizer Responsible for relationships between products, particularly for cross-selling and up-selling.
Content Manager Responsible for managing and approving site content.
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.

Technical Support First level of technical support for the site, they address day-to-day issues and provide assistance to
internal and external users. Should a severe problem or error occur, they would likely escalate to one or
more of the above roles.
OPERATIONS & SUPPORT

ROLE DESCRIPTION
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.
2.2.1 SAMPLE ORGANIZATIONAL STRUCTURE

The diagram at right outlines the typical roles necessary for a B2C commerce Implementation.

2.3 Choosing Your Partner
All organizations have a variety of technology partners. The third important factor to consider before you begin a hybris
implementation is selecting your hybris implementation partners. Over 95% of organizations implementing hybris choose to
collaborate with a technology partner specializing in hybris. hybris has an extensive and global partner network, but experience
has shown that even the best partners and the greatest clients can be miss-matched. Organizations implementing hybris software
vary widely in what they value in a System Integrator (SI) and how they work with their technology partners. Likewise, partners vary
significantly in size, style, and focus.
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:
• Are they a hybris certified partner? (Gold / Silver / Bronze)

• Are more than 40% of their developers hybris certified?
• Are the Team Details shared, including biographies and certifications?
• Are the Architect and Team Lead hybris certified and experienced?
• Have they delivered more than one hybris implementation?
• Have they provided a valid reference?
• Do they specialize in your vertical market segment?
• Can they staff your engagement within your timelines?
• Can they share examples of how they document your project?
• Is their code quality criteria explained? Do they follow hybris recommended best practices?
2.3.1 RECOMMENDED PARTNER PROJECT TEAM

At the very minimum, hybris expects a partner to staff an engagement with the following roles. Individual partners may name the
role differently, but their competency should be the same. Additional specialist roles may also be proposed to further augment the
project team.
ROLE HYBRIS COMPETENCY
Executive Sponsor Particularly when hybris assigns an Exec Sponsor
Client Relationship/ Customer Care/Contract Role, works closest with hybris Account Manager
Program Manager
Commerce Consultant Multiple commerce engagements, industry experience

(Industry SME)
Project Manager Required: hybris project delivery boot camp
Business Analyst Recommend: hybris BA certification

hybris Architect Required: hybris certification Core & Commerce Development
hybris Lead Developer Required: hybris certification Core & Commerce Development
hybris Developer(s) Recommend: 40% of build team is hybris developer certified
QA/Testing Recommend: hybris BA Training & Core Developer
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.
2.3.2 PROJECT DOCUMENTATION

hybris expects that every partner project is formally documented, and if required, the partner will quickly provide:
• Signed contracts with client and hybris-approved budget

• Project Governance “Rules of Engagement” is documented, especially ties to hybris Account Management,
Managed Services, yServices, Support and Training, Escalations, Stakeholder roles
• Documented Requirements & Designs which can be shared with hybris as needed e.g. “Prioritized Scope Matrix”
• Methodology/Approach (e.g. agile) must be documented
• Project Org. Structure including names, certifications of assigned resources
• Delivery Model Documented (Onsite vs. Offsite work, On-Shore vs. Off-Shore)
• Infrastructure diagram/tools – Environments, Source Code Repository, Security
• Plans: e.g. Project Plan, Testing Plans etc.
• Project Status: Budgets consumed, remaining – work completed, effort to complete
When undergoing the partner selection process, hybris recommends request samples from past partner projects.

3. FEASIBILITY PHASE
The feasibility phase is an evaluation

and analysis of the potential of
the proposed project, based on
extensive investigation and research,
to determine whether it is viable.
It precedes the development and
implementation phases.
Feasibility studies aim to objectively and rationally uncover the strengths and weaknesses of an existing business or proposed
venture, opportunities and threats as presented by the environment, the resources required to carry the project through, and
ultimately the prospects for success. In its simplest terms, it’s an analysis of expected cost and expected value. As such, a well-
designed feasibility phase should provide project background or context, description of the end result or desired result (including
requirements for the ongoing operations and management), and financial data (cost and revenue expectations).
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:
• Selecting a Project Manager

• Dividing large projects into phases
• Identifying stakeholders
• Documenting business needs, project objectives, assumptions and constraints
• Developing project charter and scope statement

• Resourcing requirements
• Budget approval
The hybris pre-sales team assists your organization during your software evaluation and selection process in the following ways:
• Responses to RFI/RFP questionnaires

• Product demonstrations
• Gap analysis between business requirements and hybris platform features
• Software pricing estimates (based on volumes, number of servers, etc.)
• Implementation estimates (done in conjunction with a hybris implementation partner)
• Training estimates
• Maintenance estimates
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.
3.1 Feasibility Phase Tolls

• Internal stakeholders have been identified
• Business needs and project deliverables have been documented
• Project budget has been proposed and approved
• Implementation partner has been selected
• hybris has been licensed

4. FOUNDATION PHASE
The purpose of the foundation phase

(sometimes known as the analysis
phase) is to create an aligned scope
and plan that the architecture team
believes can be delivered.
It helps to define the scope and level of effort, and to demonstrate that there is a solution that will work. During this time, the
delivery team takes ownership of the project. The role of the Solution Architect is particularly key to the phase; while hybris delivers
a set of functionality to the project, there is a need to find out how it will work with the customer’s existing technology solutions.
The foundation phase output will consist of:
• A Project Charter describing project organization, methodology, check points

• A Project Plan for the exploration phase
• High-level business requirements
• High-level technical documents
4.1 Getting Started

Start by ensuring that all prerequisites for a successful project are in place, the areas to cover are the following:
• 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)
• All legal documents are in place:

»» Non-disclosure agreement
»» hybris Master License Agreement
»» hybris Customer Support Policy, including hotline support number
»» hybris Master Services Agreement
»» hybris Statement of Work (SOW)
• 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)

»» Billing practices
»» Expense and travel policies
4.2 Project Kickoff

A project kickoff meeting should be set to create a plan outlining how to organize the foundation phase. At the end of this phase the
team must be established and aligned with the business goals. In more detail:
• 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:
• Team members are not confirmed for the project yet

• Unclear or undocumented business requirements
• Lack of understanding of software capabilities
• Team member expertise does not correspond to the expertise required by the role
• Unclear ownership and responsibilities
• Missing or insufficient technical infrastructure
• Missing or wrong key performance indicators
• Working from multiple locations, across multiple time zones
• Pressures outside of the project
• External dependencies on other parallel project(s)
4.3 Organizing and Staffing

As discussed in project kickoff, a well-established team is key to the project’s success. Every project team is organized differently,
however most teams include one or more of the following:
• 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

• Testers: responsible for implementing and running tests
• Content Providers: responsible for product content as well as site content—typically from the business
• Technical Experts, such as database administrators, system administrators, network administrators,
or hybris experts as needed
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.

4.4 Goal Setting and Planning
Once the team has been established, it’s time to focus on the project itself. The business owners should set-up and discuss
high-level requirements. If the project moves an existing solution to a new platform the discussion should cover:
• Which existing features are essential

• Which existing features are nice to have
• Which existing features are no longer needed
• Which new features are essential
• Which new features are nice to have
• Which new and existing features can be modified to fit with existing hybris functionality
In either case the discussion should cover:
• 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):
• Initial drafts of high-level requirements

• Dates, participants, and timeline for completion of the requirements workshops & deliverable reviews
• Procedures for issue tracking, issue resolution, and change management
• Updated Project Plan
• Approval of the Project Plan from the Project Steering Committee

4.5 Team Training
Fundamental technology skills are required as the basis for hybris development teams, including: Java, Spring, SOLR, ZK frame-
work, and Apache Tomcat. There are industry-training classes that can be leveraged to help your developers learn these skills.
4.5.1 HYBRIS TRAINING
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.
hybris training offerings include:
• 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 courses include:
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.

Certification: hybris provides a certification process to developers in order to help provide
standards of hybris developer proficiency. The hybris Core Developer Certification is awarded to
developers who have passed the hybris Core Developer Certification Exam. This exam is designed
to test a software developer’s ability to use and extend the hybris core platform. It is a best practice
to certify your developers.
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.
4.5.2 SOFTWARE WORKSHOP
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.
4.6 Multi-channel Accelerators

hybris Multichannel Accelerators enable hybris customers to jump-start their implementation of a feature-rich multichannel
commerce solution. hybris Multichannel Accelerators are pre-built foundations that incorporate best-practice multichannel
capabilities, including central product content and order management at its core, and state-of-the art marketing and
merchandizing capabilities. The accelerators deliver the functionality and business tools organizations need to create an
engaging customer experience, improve customer conversion and increase average order value across all channels. By offering
sophisticated, integrated personalization, a large selection of promotions, powerful search and navigation capabilities, and
rich product information including reviews, hybris Accelerators enables retailers and consumer brand manufacturers to boost
multichannel sales faster than ever before.
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.
4.7 High Level Architecture

The technical team will identify what systems will be affected by the project and to what extent. Some components need to be
implemented, some customized, and some reconfigured. There could be dependencies on external systems during the project
(e.g., reusing the testing framework) or beyond the project (e.g., integration with a CRM system). Ultimately, we need to choose and
confirm technologies used in the project.
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.

Although it is possible to install all the software components in hybris on a single server, it is a best practice to setup
a cluster of servers to separate the functions that are dedicated to serving real-time customer web requests and
those that perform asynchronous processes or administration interfaces. This preference is driven by performance, fault-
tolerance, and networking security reasons.

The following interaction diagram shows an example of how the application server components inter-operate
to service a client request:
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.

International rollouts also have an impact on the high-level architecture. It is best-practice to decide which components will be
shared across multiple countries or regions and which will be country specific. Possible setups are (from least to most specific):
• 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.

4.8 Create Infrastructure (Development Setup)
At this stage, we need to come up with a technical infrastructure for the project. The technical infrastructure could differ from
project to project, and it is important the infrastructure is documented and readily available should a new team member need to
join at a later phase. Typically, successful projects have the following:
• 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.
Further reading on our wiki:
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

4.9 Requirements Reviews & Workshops
hybris Professional Services offers several service packages that are intended to occur during the Foundation Phase of a project.
They are specifically tailored to hybris functionality and project requirements, and help ensure the hybris Commerce Suite out-of-
the-box functionality is being maximized, customizations are being minimized, and any gaps are identified.
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.
4.10 Foundation Phase Tolls

• Internal project kickoff
• Established Project Steering Committee
• Project contracts signed
• Technical and business teams are trained by hybris on the software

5. EXPLORATION PHASE
During the exploration phase (also

sometimes referred to as the
technical design phase), the project
team investigates the detailed
business requirements of the project
and designs a solution that meets
those requirements.
The exact method and the format of the deliverables varies based on the project method selected by the team. It could take the
form of a fully-featured functional requirements document, or a lighter-weight group of user stories that are then taken forward by
the development team during Engineering.
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
The output will consist of:
• 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.

5.1 Data Management and Structure
hybris websites are data driven. It is very important to have the correct data structures in order to meet the functional
requirements and optimal customer navigation of your website.
5.1.1 Product Data Mapping
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.
5.1.2 Catalog Structure
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:
• Specific attributes—what are the business

requirements for the variant specific product
attributes? The accelerator introduces style
and size, however different variant products
could have different attributes in parallel.
• Inheritance—do you want to manage some

attribute values on the base product level?
Do you want to override these values on the
variant level?
• Search—do you want to display base

products or all the variants in the
search result?
• Structure—what is the desired data structure

to manage product variants? Is the two-level
approach demonstrated in the accelerator
acceptable? Or perhaps a flat structure
would fit the business requirements better?
• Availability—what does it mean that a

product is available and in stock? Is it the
availability of the base product, the variant
product, or a combination of both?

5.1.3 Taxonomies (Classification Systems)
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?
5.1.4 Data Import
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.
The hybris ImpEx extension’s key features are:
• Import and export hybris Commerce Suite data from and into CSV files.
• Support for import using database access.
The hybris ImpEx extension is intended to provide an easy way of:
• Updating data at run time

• Creating initial data for a project or migrating existing data from one hybris Commerce Suite into another
(during a migration, for example)
• Facilitating data transfer tasks, (e.g., for CronJobs) or for synchronization with third-party systems
(such as an LDAP system or SAP R/3, for example)
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.

The earlier the project begins to import the data (at least a subset) the better. This allows for 1) testing the accuracy of the import
process, 2) validation of the data model with the developers, and 3) providing a common test data source that the developers can
use to unit and integration test their code.
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.
5.1.5 Synchronization Strategies
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.
5.1.7 Media Management
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.

A media item in the hybris Multichannel Suite is a container object that holds a reference to a file. That is, a media item in the hybris
Multichannel Suite is not the file itself, but a reference to the file. The actual file can be stored in the hybris Multichannel Suite or be
located on a remote server or system. The size and volume of the media and the performance of the website to render the media
are two important considerations as to where the media should be stored. Also important is the business user’s ability to access,
upload and modify the media. Media updates should be done by the business independent of the website itself (meaning business
users have the ability to update and change media items without the need for IT intervention).
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?
5.1.8 Supported Languages, Currencies and Locations
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:
• Java Platform objects like Locale, Currency or TimeZone

• hybris domain objects like LanguageModel, CurrencyModel or CountryModel
‘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:

»» Type-system-related attributes
»» Classification attributes
• Localization settings: Front end users are able to switch between different locale settings. The screen texts are displayed in
different localizations, depending on the language
• Limited range of available languages for user groups
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.
5.1.10 Data syndication
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?
5.2.1 Index Data Model
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.

5.2.2 Attributes, Facets, Ranges
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.
5.2.4 Relevancy and Sorting
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.
5.2.5 Boost and Bury
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.
5.2.6 Type ahead, Synonyms, Stopwords, Keyword redirects
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.
5.2.7 Product Variants
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:
• Only base products are exported

• Base products are exported with collection values of all the variants
• Variant products are exported
The selected solution should include analysis of the performance implications as well as desired category landing page appearance.
5.2.8 Index Update Strategies
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.

5.2.9 Personalized Attribute Values
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.
5.2.10 Search Server
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:
• which nodes belong to with index

• which node is the master and which are slaves
• what the current synonyms and stopwords are.
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:
• Search results could differ for different locales

• Sorting could differ for different locales
• Stopwords, synonyms and type ahead could differ for different locales
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.
5.3 Omni Channel Commerce

When the data is successfully structured, imported and managed within the system, the next step is to focus on the channel or
presentation layer. Each project may plan to use different channels at different stages, so select the corresponding subsections of
this chapter accordingly.
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:
• Conducting detailed gap analysis against the commerce services

• Specifying what channels to support (in what phase)

The channels should not be discussed in isolation; it is usually better to understand the desired end customer user experience and
have mapped targeted cross channel journeys. These journeys need to be closely monitored and adapted, so many requirements
for analytics will become a part of functional specification at this stage.
5.3.1 Desktop Channel, Mobile Web Channel
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:
• Creating, reusing and updating wireframes

• Discussing a need for responsive design
• Specifying java script functionality and choose a technology
• Specifying JSP pages, fragments and tag libraries
• Specifying required personalization rules
• Choosing search engine optimization (SEO) strategies
• Specifying supported browsers and their versions
Accelerator / CMS specific considerations:
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:
What is the bare minimum needed to be managed by a business user?
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.
Considerations when not using Accelerator or CMS:
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:
• Proven solution deployed many times

• Large pool of architects and developers who understand and use the design and code on daily basis
• AddOn extensions for easy upgradability
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.

5.3.2 Site Design
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:
• Site Map—overall page structure of your website

• Wireframes—structure & templates of your pages
• Taxonomy/Information Architecture—hierarchy and structure of your data (i.e. categories, sub-categories, products, variants)
• Visual Elements—colors, fonts, logos, images, etc. (including CSS)
• Navigation—the flow of your website and how customers access your products
• Personalization—how your website changes based on profile attributes of the user
Ever heard the old saying “garbage in, garbage out”?
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.
Creating a completed user interface generally consists of the following steps:
1. Website wireframe
2. Visual elements
3. HTML Prototype
4. JSP Page Development
The website wireframe, also known as a page schematic or screen

blueprint, is a visual guide that represents the skeletal framework of a
website. Wireframes are created for the purpose of arranging elements
to best accomplish a particular purpose. The wireframe depicts the page
layout or arrangement of the website’s content, including interface elements
and navigational systems, and how they work together. The wireframe
usually lacks typographic style, color, or graphics, since the main focus
lies in functionality, behavior, and priority of content. It focuses on what
a web page does, not what it looks like. Wireframes can be pencil drawings
or sketches on a whiteboard, or they can be produced by means of a broad
array of free or commercial software applications. Wireframes are
generally created by business analysts, user experience designers,
developers, visual designers and other roles with expertise in interaction
design, information architecture and user research. Wireframes focus on:
• The kinds of information displayed

• The range of functions available
• The relative priorities of the information and functions
• The rules for displaying certain kinds of information
• The effect of different scenarios on the display
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

provide a close representation to what their web site will actually look like. Since your website has not been actually built yet (just
the front end UI), customer, product and other integration data is not yet available—but the HTML prototype does provide the
business a good representation of what their website will look like and how the functionality will be displayed.
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.
5.3.3 Native mobile channel
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.
5.3.4 hybris Commerce Web Services (OCC)
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.
5.3.5 In-Store Channel
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 discussion should include the following areas:
• Product search—supporting search of a product

• Product information—a description and specification of a product
• Availability information—in-store, nearby and overall product availability
• Order placement—shipping from or reserving a product in a remote location
5.3.6 Print Channel
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:
• Print cockpit • Werk II scripts

• Print services • Adobe InDesign software

The print channel also usually requires special attention to media as the media resolution used for print differs from typical
resolution used for web. The technical specification should describe usage of Media, MediaContainers and MediaContext items as
well as any media manipulation or conversion.
5.3.7 Customer Service Representative Channel
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 Prices, Carts and Checkout

Prices are a very important detail of the product content management discussed above (5.1.1) and they deserve their own chapter in
the functional specification.
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).
5.4.2 Inventory Management
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?

• When do we do check inventory? Some of the options are: when adding product to cart, when placing an order, or when
retrieving a persisted cart.
5.4.3 Carts and Checkout
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.
5.4.4 Payment Options
Some B2C projects create sites that only accept credit card payments. However, the business needs may be much wider than that
for example:
• Invoice payment used typically in B2B scenarios

• In-store payment used in “order online during pickup in-store” omni-channel scenario
• Gift cards, where the dollar amount on the gift card could be used
• In-store credit, where the merchant carries an account balance
• PayPal
• Bill-me-later
• Split payment—combinations of payment methods
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.
5.4.5 Delivery Options
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.

5.5 Commerce Integration
A typical commerce project uses a lot of commerce services, which are invoked before or after a user places an order. The
functional specification should describe the desired services and their implementation priorities. The implementation could be
either a hybris module on-premise, hybris OnDemand service, 3rd party (on demand) service or a customized implementation.
The technology is usually already chosen at this stage of the project, so the functional specification would focus on confirming the
selected approach, understanding the configuration options and detailed analysis of an impact on the business process.
The discussion should include the following services:
• 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.
5.6 Fulfillment Process

The fulfillment process integrates services described above. The functional specification should document when the are services
called and what happens if they do not succeed. A gap analysis against out-of-the-box functionality is recommended.
A typical commerce site implements several order fulfillment processes, such as:
• Order fulfillment (the customer has placed an order)

• Order cancel (the customer has cancelled the complete order before a consignment was shipped)
• Partial order cancel (the customer has cancelled an order item before the consignment was shipped)
• Return/refund order (the customer has returned an order item and wants money back)
• Replace order (the customer has returned an order item and wants a different / same product)
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.
5.7 Solution Architecture

5.7.1 Architecture
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

5.7.2 Configuration
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:
• Integration & Development—to allow developers run integration tests

• QA—for the QA group to run regression tests
• Staged—to allow business users run acceptance tests. This environment is also typically used for performance tests and
security penetration tests. Generally it is a scaled percentage (i.e. 50%) of the production environment so performance
measurements can easily be translated to the production environment.
• Production—the environment to serve customers.
System administrators would take the initial configuration and create environments before or during the engineering phase,
as needed.
5.8 Reporting and Analytics

5.8.1 Scope
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:
• Is there a need to write your own query? If yes:

»» What would be an expected role of the user writing it? (e.g., a business user, an in-house developer,
or 3rd party solution provider)
»» How long is it acceptable to wait for the query to be written? (e.g., days, weeks, months)
• Who will have the access to the query results?
• What is the desired output? (e.g., web access, spreadsheet, email)
It is not a good practice to run queries against the production system, for risk of performance degradation of your
live website.

5.9 Backend Systems
The back office could be served by three technologies within hybris: hMC, cockpits and the backoffice extensions. Always choose
the right mix of the back office tools to support your business processes. The selection criteria should include:
• deprecation of the technology in short- and mid-term

• out-of-the-box functionality included
• customizations required
• effort needed (highly dependant on your team experience)
• usability from the business user point of view
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.
5.10 Architecture Reviews & Workshops

hybris provides several Professional Services Packages to assist you during your Architecture and Design phases:
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.
5.11 Exploration Phase Tolls

• Design specifications established
• Functional requirements defined
• Risk factors identified
• Use cases, user stories and data flows identified
• Technical systems architecture and infrastructure well documented
• Data mapping and structure complete
• Project plan completed and approved

6. ENGINEERING PHASE
The engineering (development)

phase takes the preliminary solution
created in the exploration phase and
delivers it to the business in opera-
tional readiness. This could take the
form of several deployable iterations,
or one ‘big-bang,’ depending on the
development road map created in the
foundations phase.
Planned activities:
• 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
The output will consist of:
• Deployable solution, initial data set and deployment guides

• Test framework for system, integration, performance and acceptance testing as well as test results
• User guides
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 should not only fulfill the functional requirements and be well integrated with the hybris platform; it should also
avoid typical project pitfalls. There are many known design anti-patterns that could make the system work sub-optimally. Poorly
written code is often one of the primary reasons for poor performance of a website.
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.
6.2 Local Environment

Every developer will need to set up a local working environment. It is a good practice to create a setup script or document, which
will guide new team members through setting up the system quickly. The local environment typically includes:
• hybris installation, including an embedded SOLR instance

• A local (or sometimes remote) database instance. The out-of-the-box memory in HSQL is not always the best choice,
especially for larger datasets.
• Common set of property values (such as a localextensions.xml file)
• Common data set. The project should be easily reinitialized and repopulated with all the data using ‘Create Project’
or ‘Create Essential Data.’
• Additional project specific libraries (for example POI, FOP…)
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:
• Development environment (IDE such as Eclipse or STS)

• Access to a code repository (such as CVS, SVN, Git)
• Automated code quality controls (jUnit, PMD, jIndent…)

Once the local environment is created, it is also recommended to take care of it:
• Make every developer aware of conventions established in 3.7.

• Patch and upgrade hybris, libraries and tools according to project needs.
6.3 Software Design

6.3.1 Advanced Personalization (BTG)
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.
6.3.2 Data Validations
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.
6.3.3 Data and Code Deployment
Code deployment into different environments:
• 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
Data deployment into different environments:
• 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
6.3.4 Project pitfalls
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:
6.4.1 Modified Data Structure
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

via API during “create essential / project data.” In other words, appropriate impex file should be part of definition of “done.”
This will allow the system to:
• reinitialize in case of data structure changes

• reinitialize in case an extension is removed
• be easily updated when moving from one environment to another
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.3 Front end
• Design and implement the user interface

• Test the user interface for all supported browsers and their versions
6.4.4 Cockpit
• Cockpit development may require a ZK development license

• ZK framework as well as NG Cockpit framework requires some time to learn. Assign the cockpit development tasks to the
same developer(s).
6.4.5 Integration Patterns
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
6.4.6 Code Quality
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:
• Follows the best practices for upgradability

• Does not use any deprecated API
• Optimally uses out-of-the-box functionality
• Follows performance best practices for domain model deployment
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.)

Typically, the data is initially entered via hmc, because it makes development and testing faster. When the
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.
6.6 Code Review

Usually every developed and tested piece of code or data is reviewed by a peer or by a team leader. The review typically focuses on
ensuring that:
• the implemented functionality matches requirements

• the implemented functionality is covered by unit tests
• the code follows defined coding conventions
• the code is maintainable in the future
• the code uses hybris libraries optimally
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:
(DO NOT DO THIS)

/** This method returns name */
public String getName() { return this.name; }
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:

• Unit tests help the developer verify correct functionality of the smallest units of code. A typical unit test does not need a
transactional environment or a J2EE container. A highly recommended test-driven development starts with covering user
stories by unit tests and is then followed by implementation.
• Integration tests verify that all individual working pieces of code work well when assembled together. In a simple scenario, the
integration test runs in a transactional environment. More elaborate tests may require the J2EE container, or even the whole
testing infrastructure including external web services. Sometimes, the external services are mocked.
• Regression tests are used to run all the existing unit and integration test when a new piece of functionality is added. The testing
instills confidence that the new code does not negatively impact functionality developed earlier. There are many systems
providing continuous build and testing, so the regression tests could be automated.
• Performance tests are used to find the application throughput and the closest performance bottleneck. These tests are
essential for finding the optimal parameters of every implementation. Since some of the performance bottlenecks could be a
result of the architectural approach, it is highly advised to start with performance testing as early as possible. A performance
test conducted two weeks before release day would find the closest performance bottleneck and provide some configuration
suggestions, however it could also reveal some hidden design flaws difficult to fix at this stage of the 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.

6.9 Data Migration
Project requirement may include a need to import data from a legacy system to the new solution. There are two main approaches
to the migration:
• 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.
6.11 Engineering Phase Tolls

• Periodic functionality demonstration
• Third party reviews
• Workflow, roles and responsibilities established
• Validate Environment is sized to scale
• Testing completed, including Quality Testing & User Acceptance Testing
• Data conversion and migration complete

7. DEPLOYMENT PHASE
The primary aim of the deployment

phase is to deliver the solution into
live use. It can be the deployment of
one or more engineering iterations,
and includes all aspects required to
make the system operational.
Planned activities in the deployment phase:
• Go-live strategy, the actual deployment

• Data migration
• Early production support
• Trainings, system handover, creation of system maintenance documentation
• Project review and assessment
The output of this phase will consist of:
• 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.
7.1 Production Cutover Planning

Going live is a very risky step even in case of a well-tested solution. To mitigate the risks, it is recommended to prepare for go-live
and script all the activities and activity dependencies. The script should focus on the following activities:
• 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.

• Define timing. The timing covers the go-live date, but it also needs to discuss timing for all tasks before and go-live. These
could include:
»» Data migration
»» Network and system changes
»» Changes of business processes
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.
7.2 System Maintenance

The system maintenance needs to be discussed, defined and documented between the project team and future system
administrators. The areas to discuss include:
• 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.

7.4 Go-Live - Execution
Going live is essentially executing the go-live script prepared earlier. A successful go-live depends on:
• Well tested software, especially good performance testing

• Well prepared go-live scripts and resources, especially data migration procedures and production certificates. Some sites with
high traffic load may need cache warming or similar measures.
• Fast and proactive resolution of emerging issues, having the key personnel available with established communication. You do
not want to spend two hours finding a person with read access to error logs on production system.
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?)
The summary should discuss continuous improvements and lessons learned.
7.6 Deployment Phase Tolls

• Project Launch Strategy and go-live activities defined
• Peer review of detailed deployment and fallback plan
• Partner knowledge transfer completed
• Physical network and server architecture documented
• Backups are in place and functional
• End user trained
• Go-live sign-off

8. SUPPORT AND OPERATIONS PHASE
The support and operations phase

follows the deployment of the
application along with the handover
from the project team to the support
and the operations teams.
The main aims of the support and operations phase are:
• 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).
Activities during this phase:
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.
8.2 Contacting hybris Support

hybris offers three levels of production system support. There is a defined incident resolution procedure available on the “hybris
Product Support” wiki page. The page describes:
• response and resolution times

• the ticket creating process
• the ticket resolution process
• end of life dates for individual hybris releases

Anyone who monitors and supports a hybris system should be familiar with the process. Incorrectly created tickets may stay in the
system for long time without any feedback. A typical issue is creating for example a platform ticket (identified by PLA-xxxx) instead
of the support ticket (identified by SUP-xxxx). While the platform ticket is recorded by the system and a developer is assigned, there
is no guaranteed resolution or response time. In other words—the ticket resolution depends on person’s priority list.
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.
8.3 Incident and Problem Management

The new system should become a standard piece of the enterprise architecture and the existing enterprise processes need to
cover its incidents and problems. The existing processes may need adaption to:
• accept, categorize and prioritize incidents

• establish a process to analyze and fix application defects
• make sure, that the adapted process will allow achieving agreed resolution time
Some incidents may require opening a hybris support ticket; see the above section ‘Contacting hybris Support’ for the correct way
of doing it.
8.4 System Maintenance

Ongoing system maintenance includes reactive tasks (defined in chapter 6.2 System Maintenance) or results from monitoring
(discussed in chapter 8.1 Monitoring). However, there are also proactive tasks such as:
• applying the latest application patches

• verifying optimal configuration of cache, memory, jvm parameters and overall health of the managed system
• making sure that the system can handle expected steep increase of traffic for example after a planned marketing campaign
8.5 Change and Release Management

Continuous improvements, new required features, and new platform releases all lead to a need for updated versions of the
implemented solution. From a high level, there are three essential activities that will make future updates easier to implement:
• Establish a process for how to process and implement change requests
• 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:
• Keep the user guide and maintenance documentation up to date

• Make the functional specification and technical specification available for future reference
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.

The new policies and job descriptions should be communicated. The following is a sample table of contents for a hybris Site
Administration Guide:
• 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
8.7 Support and Operations Phase Tolls

• hybris Support introduced
• Maintenance and operations schedule

9. TYPICAL PROJECT PITFALLS
9.1 Business requirements not fully supported by the platform

Many projects start with the following dilemma: the business owners are not fully aware of the capabilities of the hybris platform
and the solution implementers may not be fully acquainted with the business processes. How can we accurately estimate the
development effort? The following questions must be asked:
• 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.
9.2 Overlooked functional areas

Every project contains risks where specific areas may be missed or not fully discussed or analyzed, and implementation effort
may not have been estimated properly. The exploration phase section of this document covers the functional areas of a typical
project. The hybris Solution Architecture Workshop package delivered by hybris Certified Consultants can help alleviate the
aforementioned risks to fully explore, discuss, and analyze required functional areas.
9.3 Very large functional requirements

No project requires 100+ languages, 100+ product catalogs, and 100+ different sites. No project requires every possible
touchpoint/channel, all available commerce services, having a complete list of fulfillment processes. It is unlikely that the business
requirements, the implementation, and its intended audience would require these extremes. An e-commerce project needs to
cover as many possible functional areas as possible, however, not all requirements are typically needed to deliver a successful
implementation to your target audience.
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.
9.4 Premature Go-Live

There are many important activities in the engineering and deployment phases that can easily be overlooked. The following areas
should be covered:
• User guides and training

• Testing - unit, integration, system, performance, security penetration and acceptance tests
• Backup and recovery procedures
• Maintainability strategy (new patches, upgrades)
• Scalability strategy (what to do if the traffic is higher than anticipated)
• Initial data migration

The hybris Solution Architecture Review, Performance Review, and Deployment Preparation Review packages can help ensure a
successful Go-Live.
9.5 Recommended order of design activities

From our project experience, we can distill a simplified series of steps when starting a project:
1. Design the data model

2. Design the product and content catalogs (establish initial and test data)
3. Design and test catalog synchronization

10. USEFUL LINKS
hybris 5 Documentation:
https://wiki.hybris.com/display/release5/Release+5+Documentation+Home
hybris Technical Dashboard:

https://wiki.hybris.com/display/welcome/Technical+Dashboard
hybris Business Dashboard:

https://wiki.hybris.com/display/welcome/Business+Dashboard
hybris Product Support:

https://wiki.hybris.com/display/SUP/Product+Support
hybris Training:
http://campus.hybris.com
hybris Certification:
http://campus.hybris.com/Categories/Certifications/c/certifications
hybris Third Party Compatibility Matrix:

https://wiki.hybris.com/display/release5/Third-Party+Compatibility+-+Release+5
hybris Downloads:
https://wiki.hybris.com/display/downloads/Download
hybris Partners Overview:

http://www.hybris.com/en/partners/partners-overview
hybris Company Overview:

http://www.hybris.com/en/company/aboutus
hybris Products & Services Overview:

http://www.hybris.com/en/products/product-overview

11. ACTIVITY TIMELINE
DEFINE your strategy (2.1)
STAFF your ecommerce team (2.2)
CHOOSE an implementation partner (2.3)
CHOOSE project methodology (4.1) FOUNDATION
CREATE project communication (4.1)
IDENTIFY hybris resources (4.1)
IDENTIFY legal documents (4.1)
IDENTIFY project assumptions (4.1)
IDENTIFY project documents (4.1)
IDENTIFY project policies (4.1)
STAFF account manager (4.1)
STAFF project manager (4.1)
STAFF project owner (4.1)
STAFF project sponsor (4.1)
CONFIRM business goals (4.2)
CREATE project plan (4.2)
CREATE project roles (4.2)
IDENTIFY project risks (4.2)
MAINTAIN project plan (4.2)
CREATE RACI document (4.3)
STAFF project manager (4.3)
STAFF project steering committee (4.3)
STAFF various project roles (4.3)
CONFIRM project plan by the project steering committee (4.4)
CREATE high-level business requirements (4.4)
ESTABLISH change management (4.4)
ESTABLISH incident management (4.4)
FAMILIARIZE business users with hybris (4.4)
IDENTIFY high level business requirements (4.4)

IDENTIFY need for the Endeca integration workshop (4.4)
IDENTIFY need for the architecture review (4.4)
IDENTIFY need for the architecture workshop (4.4)
IDENTIFY need for the requirements review (4.4)
IDENTIFY need for the requirements workshop (4.4)
IDENTIFY need for the software workshop (4.4)
IDENTIFY performance requirements (4.4)
IDENTIFY project goal (4.4)
MAINTAIN project plan (4.4)
FAMILIARIZE technical personnel with hybris (4.5)
FAMILIARIZE business users with a reference implementation (4.6)
FAMILIARIZE technical personnel with a reference implementation (4.6)
CREATE high-level technical documents (4.7)
CREATE bug tracking tool (4.8)
CREATE build automation (4.8)
CREATE code quality tools (4.8)
CREATE code repository (4.8)
CREATE coding standards (4.8)
CREATE definition of done (4.8)
CREATE environments (4.8)
CREATE the initial binary project (4.8)
IDENTIFY need for the requirements review (4.9)
IDENTIFY need for the requirements workshop (4.9)
IDENTIFY need for the software workshop (4.9)
IDENTIFY project risks (5) EXPLORATION
MAINTAIN project plan (5)
CREATE product data requirements (5.1.1)
CREATE data syndication requirements (5.1.10)
CREATE product catalog structure (5.1.2)
CREATE product data requirements (5.1.2)
CREATE classification systems (5.1.3)

CREATE taxonomies (5.1.3)
CREATE product data import (5.1.4)
IDENTIFY product data import (5.1.4)
CREATE product synchronization strategy (5.1.5)
CREATE workflows (5.1.6)
DEFINE product content management process (5.1.6)
CREATE media management requirements (5.1.7)
CREATE internationalization requirements (5.1.8)
CREATE product catalog structure (5.1.9)
CREATE product synchronization strategy (5.1.9)
DEFINE product content management process (5.1.9)
IDENTIFY need for the Endeca integration workshop (5.10)
IDENTIFY need for the architecture review (5.10)
IDENTIFY need for the architecture workshop (5.10)
DEFINE search attributes (5.2.1)
DEFINE search facets (5.2.1)
DEFINE search ranges (5.2.1)
DEFINE searchable products (5.2.2)
DEFINE search result relevancy (5.2.3)
DEFINE search result sorting (5.2.3)
DEFINE search result boost product (5.2.4)
DEFINE search result bury product (5.2.4)
DEFINE search keyword redirects (5.2.5)
DEFINE search keyword stopwords (5.2.5)
DEFINE search keyword synonyms (5.2.5)
DEFINE search type ahead (5.2.5)
DEFINE searchable products (5.2.6)
DEFINE search index update strategy (5.2.7)
DEFINE search attributes (5.2.8)
CHOOSE search sever (5.2.9)
CREATE front end requirements (5.3.1)
IDENTIFY gaps against the accelerator (5.3.1)

CREATE frontend visual elements (5.3.2)
CREATE wireframes (5.3.2)
DEFINE frontend visual elements (5.3.2)
DEFINE site design (5.3.2)
DEFINE site map (5.3.2)
DEFINE site navigation (5.3.2)
CREATE mobile app requirements (5.3.3)
CREATE tablet app requirements (5.3.3)
DEFINE web service api (5.3.4)
CREATE in store app requirements (5.3.5)
CREATE print requirements (5.3.6)
CREATE customer service requirements (5.3.7)
DEFINE order fulfillment process (5.3.7)
DEFINE discounts (5.4.1)
DEFINE price management (5.4.1)
DEFINE promotions (5.4.1)
DEFINE vouchers (5.4.1)
DEFINE cart management (5.4.2)
DEFINE inventory management (5.4.2)
CREATE wish list requirements (5.4.3)
DEFINE cart management (5.4.3)
DEFINE promotions (5.4.3)
DEFINE payment options (5.4.4)
IDENTIFY PCI compliance requirements (5.4.4)
DEFINE delivery options (5.4.5)
DEFINE checkout process (5.5)
DEFINE order fulfillment process (5.5)
DEFINE delivery options (5.6)
DEFINE order fulfillment process (5.6)
DEFINE solution architecture (5.7.1)
IDENTIFY sizing requirements (5.7.1)
CREATE system configuration (5.7.2)

CREATE environments (5.7.3)
CREATE reporting requirements (5.8.1)
DEFINE reporting technologies (5.8.2)
DEFINE access rights (5.9)
DEFINE backend tool configuration (5.9)
DEFINE software architecture (6.1) ENGINEERING
FAMILIARIZE technical personnel with maintainability guidelines (6.1.1)
CREATE monitoring tools and configuration (6.10)
DEFINE monitoring strategy (6.10)
CREATE environments (6.2)
FAMILIARIZE software architect with typical project pitfalls (6.3)
DEFINE code deployment process (6.3.3)
DEFINE deployment process (6.3.3)
CREATE source code (6.3.4)
CREATE source code (6.4)
FAMILIARIZE technical personnel with development guidelines (6.4.1)
FAMILIARIZE project managers with software license requirements (6.4.4)
FAMILIARIZE software architect with integration patterns (6.4.5)
IDENTIFY need for the code review (6.4.6)
FAMILIARIZE software architect with typical project pitfalls (6.5)
IDENTIFY need for the code review (6.6)
CREATE business user guides (6.7)
CREATE documentation guidelines (6.7)
CREATE user guides (6.7)
DEFINE deployment process (6.7)
FAMILIARIZE technical personnel with development guidelines (6.7)
CREATE acceptance tests (6.8)
CREATE integration tests (6.8)
CREATE performance tests (6.8)
CREATE regression tests (6.8)
CREATE security penetration tests (6.8)
CREATE test scripts (6.8)

CREATE unit tests (6.8)
DEFINE testing approach (6.8)
IDENTIFY sizing requirements (6.8)
CREATE data migration scripts (6.9)
DEFINE data migration strategy (6.9)
DEFINE production cutover (7.1) DEPLOYMENT
CREATE system maintenance guidelines (7.2)
DEFINE system maintenance guidelines (7.2)
FAMILIARIZE business users with the final solution (7.3)
FAMILIARIZE system administrators with the final solution (7.3)
GO LIVE execution (7.4)
GO LIVE debrief (7.5)
ESTABLISH monitoring of the production system (8.1) SUPPORT AND

OPERATIONS
FAMILIARIZE system administrators with contacting hybris support (8.2)
ESTABLISH system maintenance (8.4)
ESTABLISH change management (8.5)
CREATE monitoring tools and configuration (8.6)
CREATE system maintenance guidelines (8.6)
FAMILIARIZE business users with typical project pitfalls (9) PITFALLS
FAMILIARIZE software architect with typical project pitfalls (9)

12. ACTIVITIES
CHOOSE - an implementation partner 2.3
CHOOSE - project methodology 4.1
CHOOSE - search sever 5.2.9
CONFIRM - business goals 4.2
CONFIRM - project plan by the project steering committee 4.4
CREATE - RACI document 4.3
CREATE - acceptance tests 6.8
CREATE - bug tracking tool 4.8
CREATE - build automation 4.8
CREATE - business user guides 6.7, 7.3, 8.6
CREATE - classification systems 5.1.3
CREATE - code quality tools 4.8
CREATE - code repository 4.8
CREATE - coding standards 4.8
CREATE - customer service requirements 5.3.7
CREATE - data migration scripts 6.9
CREATE - data syndication requirements 5.1.10
CREATE - definition of done 4.8
CREATE - documentation guidelines 6.7
CREATE - environments 4.8, 5.7.3, 6.2
CREATE - front end requirements 5.3.1
CREATE - frontend visual elements 5.3.2
CREATE - high-level business requirements 4.4
CREATE - high-level technical documents 4.7
CREATE - in store app requirements 5.3.5
CREATE - integration tests 6.8
CREATE - internationalization requirements 5.1.8, 5.2.10, 5.4.5
CREATE - media management requirements 5.1.7
CREATE - mobile app requirements 5.3.3
CREATE - monitoring tools and configuration 6.10, 8.6
CREATE - performance tests 6.8

CREATE - print requirements 5.3.6
CREATE - product catalog structure 5.1.2, 5.1.9
CREATE - product data import 5.1.4
CREATE - product data requirements 5.1.1, 5.1.2
CREATE - product synchronization strategy 5.1.5, 5.1.9
CREATE - project communication 4.1, 4.2, 4.3, 4.8
CREATE - project plan 4.2
CREATE - project roles 4.2
CREATE - regression tests 6.8
CREATE - reporting requirements 5.8.1
CREATE - security penetration tests 6.8
CREATE - source code 6.3.4, 6.4
CREATE - system configuration 5.7.2
CREATE - system maintenance guidelines 7.2, 8.6
CREATE - tablet app requirements 5.3.3
CREATE - taxonomies 5.1.3
CREATE - test scripts 6.8
CREATE - the initial binary project 4.8
CREATE - unit tests 6.8
CREATE - user guides 6.7, 7.3, 8.6
CREATE - wireframes 5.3.2
CREATE - wish list requirements 5.4.3
CREATE - workflows 5.1.6
DEFINE - access rights 5.9
DEFINE - backend tool configuration 5.9
DEFINE - cart management 5.4.2, 5.4.3
DEFINE - checkout process 5.5
DEFINE - code deployment process 6.3.3
DEFINE - data migration strategy 6.9
DEFINE - delivery options 5.4.5, 5.6
DEFINE - deployment process 6.3.3, 6.7
DEFINE - discounts 5.4.1

DEFINE - frontend visual elements 5.3.2
DEFINE - inventory management 5.4.2
DEFINE - monitoring strategy 6.10
DEFINE - order fulfillment process 5.3.7, 5.5, 5.6
DEFINE - payment options 5.4.4
DEFINE - price management 5.4.1
DEFINE - product content management process 5.1.6, 5.1.9
DEFINE - production cutover 7.1
DEFINE - promotions 5.4.1, 5.4.3
DEFINE - reporting technologies 5.8.2
DEFINE - search attributes 5.2.1, 5.2.8
DEFINE - search facets 5.2.1
DEFINE - search index update strategy 5.2.7
DEFINE - search keyword redirects 5.2.5
DEFINE - search keyword stopwords 5.2.5
DEFINE - search keyword synonyms 5.2.5
DEFINE - search ranges 5.2.1
DEFINE - search result boost product 5.2.4
DEFINE - search result bury product 5.2.4
DEFINE - search result relevancy 5.2.3
DEFINE - search result sorting 5.2.3
DEFINE - search type ahead 5.2.5
DEFINE - searchable products 5.2.2, 5.2.6
DEFINE - site design 5.3.2
DEFINE - site map 5.3.2
DEFINE - site navigation 5.3.2
DEFINE - software architecture 6.1
DEFINE - solution architecture 5.7.1
DEFINE - system maintenance guidelines 7.2
DEFINE - testing approach 6.8
DEFINE - vouchers 5.4.1
DEFINE - web service api 5.3.4
DEFINE - your strategy 2.1

ESTABLISH - change management 4.4, 8.5
ESTABLISH - incident management 4.4, 4.8, 8.3
ESTABLISH - monitoring of the production system 8.1
ESTABLISH - system maintenance 8.4
FAMILIARIZE - business users with a reference implementation 4.6
FAMILIARIZE - business users with hybris 4.4
FAMILIARIZE - business users with the final solution 7.3
FAMILIARIZE - business users with typical project pitfalls 9
FAMILIARIZE - project managers with software license requirements 6.4.4
FAMILIARIZE - software architect with integration patterns 6.4.5
FAMILIARIZE - software architect with typical project pitfalls 6.3, 6.5, 9
FAMILIARIZE - system administrators with contacting hybris support 8.2
FAMILIARIZE - system administrators with the final solution 7.3
FAMILIARIZE - technical personnel with a reference implementation 4.6
FAMILIARIZE - technical personnel with development guidelines 6.4.1, 6.7
FAMILIARIZE - technical personnel with hybris 4.5
FAMILIARIZE - technical personnel with maintainability guidelines 6.1.1
GO LIVE - debrief 7.5
GO LIVE - execution 7.4
IDENTIFY - PCI compliance requirements 5.4.4
IDENTIFY - gaps against the accelerator 5.3.1
IDENTIFY - high level business requirements 4.4
IDENTIFY - hybris resources 4.1
IDENTIFY - legal documents 4.1
IDENTIFY - need for the Endeca integration workshop 4.4, 5.10
IDENTIFY - need for the architecture review 4.4, 5.10
IDENTIFY - need for the architecture workshop 4.4, 5.10
IDENTIFY - need for the code review 6.4.6, 6.6
IDENTIFY - need for the requirements review 4.4, 4.9
IDENTIFY - need for the requirements workshop 4.4, 4.9
IDENTIFY - need for the software workshop 4.4, 4.9

IDENTIFY - performance requirements 4.4
IDENTIFY - product data import 5.1.4
IDENTIFY - project assumptions 4.1
IDENTIFY - project documents 4.1
IDENTIFY - project goal 4.4
IDENTIFY - project policies 4.1
IDENTIFY - project risks 4.2, 5
IDENTIFY - sizing requirements 5.7.1, 6.8
MAINTAIN - project plan 4.2, 4.4, 5
STAFF - account manager 4.1
STAFF - project manager 4.1, 4.3
STAFF - project owner 4.1
STAFF - project sponsor 4.1
STAFF - project steering committee 4.3
STAFF - various project roles 4.3
STAFF - your e-commerce team 2.2


Hybris bestPracticesGuide R21

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Hybris bestPracticesGuide R21

Загружено:

Авторское право:

Доступные форматы

HYBRIS

HYBRIS PROJECT BEST PR ACTICES | 1

Congratulations on your selection

We are committed to the following:

2 | HYBRIS PROJECT BEST PR ACTICES

hybris Toll Gates

HYBRIS PROJECT BEST PR ACTICES | 3

4 | HYBRIS PROJECT BEST PR ACTICES

Setting your hybris project up

2.1 Defining Your Strategy

HYBRIS PROJECT BEST PR ACTICES | 5

• What is your vision?

2.2 Building Your Team

6 | HYBRIS PROJECT BEST PR ACTICES

Marketer Responsible for generating email campaigns, promotions, and sales.

Content Manager Responsible for managing and approving site content.

HYBRIS PROJECT BEST PR ACTICES | 7

OPERATIONS & SUPPORT

2.2.1 SAMPLE ORGANIZATIONAL STRUCTURE

8 | HYBRIS PROJECT BEST PR ACTICES

• Are they a hybris certified partner? (Gold / Silver / Bronze)

2.3.1 RECOMMENDED PARTNER PROJECT TEAM

ROLE HYBRIS COMPETENCY

Executive Sponsor Particularly when hybris assigns an Exec Sponsor

Commerce Consultant Multiple commerce engagements, industry experience

Project Manager Required: hybris project delivery boot camp

Business Analyst Recommend: hybris BA certification

HYBRIS PROJECT BEST PR ACTICES | 9

hybris Developer(s) Recommend: 40% of build team is hybris developer certified

QA/Testing Recommend: hybris BA Training & Core Developer

2.3.2 PROJECT DOCUMENTATION

• Signed contracts with client and hybris-approved budget

10 | HYBRIS PROJECT BEST PR ACTICES

The feasibility phase is an evaluation

• Selecting a Project Manager

HYBRIS PROJECT BEST PR ACTICES | 11

• Responses to RFI/RFP questionnaires

3.1 Feasibility Phase Tolls

12 | HYBRIS PROJECT BEST PR ACTICES

The purpose of the foundation phase

The foundation phase output will consist of:

• A Project Charter describing project organization, methodology, check points

4.1 Getting Started

• All legal documents are in place:

HYBRIS PROJECT BEST PR ACTICES | 13

4.2 Project Kickoff

• Team members are not confirmed for the project yet

4.3 Organizing and Staffing

14 | HYBRIS PROJECT BEST PR ACTICES

HYBRIS PROJECT BEST PR ACTICES | 15

• Which existing features are essential

In either case the discussion should cover:

• Initial drafts of high-level requirements

16 | HYBRIS PROJECT BEST PR ACTICES

4.5.1 HYBRIS TRAINING

hybris training offerings include:

hybris courses include:

HYBRIS PROJECT BEST PR ACTICES | 17

4.5.2 SOFTWARE WORKSHOP

4.6 Multi-channel Accelerators

4.7 High Level Architecture

18 | HYBRIS PROJECT BEST PR ACTICES