**************************Welcoeme TO HyBris Commerace Suit 6.3**********************
1) Administrator Console – http://localhost:9001/
2) Multichannel cockpit – http://localhost:9001/mcc
3) Backoffice – http://localhost:9001/backoffice
4) Admin Cockpit:- https://localhost:9002/admincockpit/login.zul
solr – http://localhost:8983/solr
Core and catalog file
Power Tools Store B2B: http://localhost:9001/yb2bacceleratorstorefront?site=powertools&clear=true
Electronics Store: http://localhost:9001/yacceleratorstorefront?site=electronics&clear=true (Under Process)
Apparel Store B2C – UK: http://localhost:9001/yacceleratorstorefront?site=apparel-uk&clear=true
Apparel Store B2C – Germany: http://localhost:9001/yacceleratorstorefront?site=apparel-de&clear=true
HYBRIS ALF OVERVIEW:-
The Project Delivery Framework consists of a high-level understanding of how projects are organized in relation to each other and specific approaches, practices, and sub-frameworks that have been designed for particular types of projects.
Here is a high-level view of the Project Delivery Framework:
The diagram above shows a high-level example of a project scheduling plan with an initial implementation project split into three releases, followed by an integration project and a migration project. The first release of the implementation project is then expanded to show the phases.
The names of the phases shown here are based on the naming convention in DSDM’s Agile Project Management Framework, however, they could easily be named differently. It’s the activities and deliverables within the phases that are important.
The Project Delivery Framework makes a distinction between projects and application management, where:
Projects are blocks of distinct work with the aim of delivering a certain scope within a certain timeframe for a certain cost (and an assumed level of quality).
Application management is the continuous support, operations, and maintenance of the live solution once it’s been deployed to a live production environment and is being used by end users.
Projects typically run sequentially delivering into the parallel application management stream. This starts with the initial implementation project, often split into a set of sequential releases, followed by ad hoc or continuous projects in parallel
to application management activities, continuing on an on-going basis until the solution is eventually decommissioned.
Together this cycle of projects is called the application lifecycle.
There are also different types of projects, not just the initial implementation project. There may also be subsequent functional development projects, system integration projects, internationalization projects, migration projects, infrastructure projects, etc. and some projects that are a mixture of types if combined.
The Project Delivery Framework can be used as a reference for all of these projects and is adaptable to different software development lifecycle (SDLC) methods such as Agile, Rational Unified Process (RUP), or waterfall, and it’s applicable to Project Management Institute (PMI) and Project Management Body of Knowledge (PMBOK) best practices.
The framework is neither rocket science nor revolutionary. Its intention is to define a common and generic set of practices and approaches that can be readily understood and used as the basis for a variety of more specific frameworks and practices that can be selected based on the appropriate project context.
Many customers and partners will have their own methodologies or delivery frameworks, created and suited for their own contexts and strengths. Some will be based on common SLDC methods, some will be hybrid approaches, or based on less well-known SDLC methods. There’s no right or wrong approach. It’s all down to the specific context of a given project and organization.
Therefore given the variety of contexts, it’s important that the Project Delivery Framework is equally understandable to someone from a waterfall background, or RUP background or someone using a hybrid approach with their own naming conventions. So each phase within the Project Delivery Framework is within a generically named block:
Discovery & planning – the where/why/how/what of the project, including scoping, architecture, planning and costs
Design/build/test – the building of the solution, whether iteratively (e.g. Sprints) or broken down into sequential design/build/test sub-phases
Deploy – the preparation and delivery of the solution into the live production environment.
A large project is often broken down into slices or increments called a ‘release’. The size of a release can vary depending on the context. An example would be breaking down a 12-month project into 2-4 smaller releases of relatively equal duration, with each release containing all the project phases as shown below:
The set of sequential phases would then start again with the next release, although the initial up-front Initiation phase that assesses the project feasibility, business case, high-level scoping, etc. is often not required as the outputs of the
previous Initiation phase are still valid.
Smaller releases can help to reduce project risk, improve time-to-market and give more immediate visibility to the business and end-users, however, they need to be balanced with the overheads involved starting/ending each release.
Alternatively, some organizations take this even further by utilizing Continuous Delivery methods to enable continuous deployments to production on a weekly or even daily basis rather than releases spanning weeks or months. However Continuous Delivery is not easy and ideally needs to be built into the project from day one. It requires significant investment and the business drivers need to be properly assessed to match the frequency of releases. Not all organizations can properly handle or need such regular deployments.
Initiation Phase (Discovery and Planning)
The primary objective of this phase is the alignment between the customer and the delivery team in terms of the why/what/how/when of the project. The customer could be another organization or another department within the same organization. The delivery team might be an in-house IT department or an external service provider. There might be a commercial relationship, there might not. However, the high-level activities of this phase remain very similar and include:
Alignment on the vision and business goals of the project
Alignment on project methodology
Identification of high-level functional and non-functional requirements
High-level requirements prioritization
Identification of key milestones, e.g. project start and go-live dates
Early identification of 3rd party and external system dependencies
Early identification of project and technical risk
Creation of a release roadmap
Understanding of the high-level scope & estimated effort of the project/releases
Creation of high-level project plans, with estimated timescales and costs
Ultimately the result of this phase is a go/no-go for the next phase to understand the project in more depth, called the Foundation phase.
Foundation Phase (Discovery and Planning)
The primary objective of this phase is to establish firm foundations for a project from a business, technical and project management perspective, and to enable all parties to have a solid understanding of the scope/time/costs/risks of the project.
The phase consists of a series of onsite workshops with the customer and delivery teams, plus key stakeholders and 3rd parties. The specific activities and deliverables of this phase can vary depending on the methodology however they generally remain very similar (although granularity will vary greatly between different methods, so waterfall will have much more detailed requirements definition than Agile):
Appropriately detailed definition of functional requirements (prioritized if Agile)
Appropriately detailed definition of non-functional requirements
Architecture design (logical, physical, data, security, etc.)
Appropriately detailed system integration architecture & design
Definition of quality management (testing) strategy
Risk identification and mitigation
Definition of project governance, organization, and structure
Refined project plans, timescales, and costs
Usually, the result of this phase is a go/no-go for the build phase of the project, called the Engineering phase. However, sometimes there is still too much uncertainty (technical or otherwise) which prevents the teams from having enough understanding of the risks to give the go-ahead for the full Engineering phase, which is essentially the go-ahead for the whole project due to the very significant commitment of resources and people. In this case, teams may want to proceed with a smaller, optional, Exploration phase.
Exploration Phase (Discovery and Planning)
This is an optional phase. It’s only required if there remains a high degree of uncertainty or risk following the Foundatio phase. The primary objective is to explore those risks and uncertainties in enough depth to provide the teams with the confidence to proceed with the larger Engineering phase and essentially commit to the project.
Given that risks and uncertainties are project specific, they can vary widely, so the activities of this phase will also vary.
However, typically they are technology related, and often involve the development of prototypes or proof-of-concepts.
These can be throw-away or designed to be reused if the project goes ahead.
These types of phases are more common on greenfield or build-from-scratch projects, especially when using new or leading-edge technology stacks with challenging non-functional requirements such as very high numbers of requests or data volumes. They are less common when building a solution from a mature platform such as Hybris Commerce, however, an Exploration phase can still be valid where needed, e.g. if using Hybris Commerce to build a mission critical solution with non-functional requirements that exceed the boundaries of the design criteria for the Hybris Commerce platform.
Typically the Exploration phase is relatively short in duration, just enough to provide appropriate certainty to make a go/no-go decision for the project, starting with the Engineering phase.
Engineering Phase (Design / Build / Test)
The primary objective of this phase is to design, build and test the solution to meet the functional and non-functional requirements and the high-level architectural design defined in the Foundation/Exploration phase.
The approach taken to develop the solution will vary significantly depending on the SDLC method. Some methods will break this phase into small 2-3 week iterations called sprints each with smaller design/build/test cycles (e.g. Scrum), others will have larger, more well-defined design/build/test cycles maybe even with their own sequential gates and sign-offs. For example, a waterfall approach would split this into three separate design, build and test phases.
This phase will also include some form of acceptance testing, often planned as a block of time at the end of this phase, however, sometimes acceptance testing is managed iteratively throughout this phase. System integration, performance, and other non-functional testing are also key activities of this phase.
Ultimately the end result should be a high-quality solution that meets the functional and non-functional requirements and is ready for deployment to the production environment within the Deployment phase.
Deployment Phase (Deploy)
The primary objective of this phase is to prepare and deploy the software produced in the Engineering phase to the production environment, ready for use by end users.
The activities of this phase can vary significantly depending on the project context, however, typically they will include:
Readiness of the production environment & data
Deployment of the final release candidate to the production environment
Support during go-live & immediate post-live support
Teams may plan not to take the solution live in the current release for business or technical reasons (perhaps the customer is replacing an existing platform and there is only a subset of the current, live functionality in this release), so this phase is not mandatory. However, there are strong technical and business advantages to deploying early to test the solution in the real “live” environment, even if it’s a ‘soft’ launch (e.g. friends-and-family) with a subset of users. Earl feedback at this early stage can significantly reduce the risks inherent with a big-bang deployment later.
Application management is not a phase or even a project. It’s a continuous workstream providing support and live operations management, and often also providing maintenance and on-going smaller development work that can be delivered outside of a project context.
This workstream starts with the first deployment to production from the initial implementation project, however, it needs to be planned from the start of the project to ensure responsibilities are clearly defined and people are appropriately trained and enabled. The project team can sometimes manage some of this workstreams responsibilities. However, it’s often managed by a separate specialized team.
Regardless, just as much thought and planning should be dedicated to application management as projects. There’s no point having the best solution in the world if you can’t run it. Poorly managed live solutions can have a significant impac on end users and ultimately a customer’s brand and reputation.
Typical application management activities can include:
1st, 2nd, 3rd line support
Development of a knowledge base
Investigating and resolving break-fix incidents, e.g. fixing/working around technical issues
Managing and resolving service requests, e.g. supporting business users
Prioritization and management of incidents/requests
Production environment tuning, monitoring & reporting
Development of change requests
Creation of maintenance and hotfix packages for production deployment
Coordination with hosting/managed services teams and other operational/system integration teams
Release and deployment management
Coordination with project development streams