**************************Welcoeme TO HyBris Commerace Suit 6.3**********************
Hybris
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
User:- admin
Password:- nimda
************************************************************************************
solr – http://localhost:8983/solr
Core and catalog file
C:\software\hybris\bin\platform\ext\core\resources
C:\software\hybris\bin\platform\ext\catalog\resources
*****************************************************************************************
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
*****************************************************************************************************
ALF OVIERVIEW
Framework 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.
Introduction
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.
Releases
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 Communications planning Change management Resource planning 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 Foundation 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. Early feedback at this early stage can significantly reduce the risks inherent with a big-bang deployment later.
Application Management
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 impact 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
HYBRIS METHODOLOGIES
Methodologies SAP Hybris Commerce is a software platform. Solutions are built on top of the platform and the various selected modules by developing new software to extend the existing behavior or to develop new functionality.
During any software development, there will always be complexity and uncertainty that customers and delivery teams must manage. This cannot be entirely eliminated but can be significantly reduced by developing on a stable software platform such as Hybris Commerce, with the remaining complexity and uncertainty being managed using an appropriate software development lifecycle (SDLC) method.
There are various software development lifecycle (SDLC) approaches that have evolved over the years to enable teams to manage this complexity and uncertainty and help them deliver successful projects.
Here we summarize that evolution from Waterfall through Rational Unified Process and Agile to help create an understanding of the different SDLC options for Hybris Commerce projects.
Waterfall
1. 2. 3. 4.
5.
First, there was the predictive Waterfall method developed in the 1970s. This method was characterized by a sequence of stage-gated (sign-off) phases: requirements, design, implementation, and testing/verification followed by on-going maintenance. This method is still commonly referred to as the ‘traditional’ SDLC method.
Since its development in the 1970s, the Waterfall approach has been used on a huge number of projects and is still frequently used to this day, with its successes and also many high-profile failures.
We attribute the sequential nature of the Waterfall approach to Winston Royce’s 1970’s paper that defined stage-gated “Waterfall” model of the software process, similar to that shown below:
Here the Waterfall method typically progresses as follows:
Requirements – the customer documents and sign-off on the detailed requirement specifications. Design – then the technical design specifications to meet the requirements are documented and signed-off. Implementation – then the software is developed to meet the requirements/design specifications. Verification – then the test team verifies (tests) the software to ensure conformance to the requirements, the software acceptance is signed-off, and its deployed to the production environment. Maintenance – on-going support & maintenance of the software in the production environment.
However, the paper was commonly misunderstood and actually promoted activities that are not regarded as traditional Waterfall activities such as feedback cycles, prototyping and an iterative and incremental approach (http://en.wikipedia. ). However, these additional activities were ignored and the traditional Waterfall methodorg/wiki/Winston_W._Royce evolved as we know it today (as described above).
Critics of the traditional Waterfall method point to the fact that software requirements often aren’t known in enough certainty at the beginning and/or that requirements often change throughout a project. Both of which are counter to the big up-front requirements analysis/design phases and the subsequent restrictive (and often expensive) change request process this method requires.
Even if the up-front requirements are managed successfully, subsequently the customer isn’t closely involved in the project until the end verification phase when the software is tested, and by then it’s often too late to change anything.
So customers risk not getting what they thought they were getting.
With testing deferred to the end of the project, defects are also discovered very late. If these are architectural or design defects, it’s often too late or too expensive to fix them.
From a planning perspective, the up-front fixed requirements combined with the sequential critical path nature of the activities mean that if there is a delay in any activity or phase, it has a direct knock-on effect on all remaining activities and phases. This often leads to cost and time overruns. When this occurs teams often reduce the duration of the verification phase (testing), which subsequently directly impacts quality.
Therefore it’s common for projects implemented using the Waterfall method to run over budget, over time and with poor quality, particularly when there is a reasonable amount of change or uncertainty.
However, where there is a very high degree of certainty and understanding of requirements/design up-front, and low change during the project, this ‘traditional’ Waterfall method can still be successful today.
Iterative & Incremental
In the 1980s and 1990s, in response to the failures of many Waterfall projects together with the increased time-to-market pressures, iterative and incremental SDLC methods were developed, including the well-known Rational Unified Process (RUP).
Like Waterfall, RUP recognized the importance of lifecycle phases. However, it was the first method that also realized the importance of activities that overlap these phases rather than being distinct activities within each phase as per the Waterfall method.
The diagram below shows the phases and how activities (represented by disciplines) occur throughout multiple phases:
With RUP and the other iterative and incremental methods, there was a purposeful move away from the big up-front requirements and design associated with Waterfall to a more discovery-based approach with lighter-weight documents and models and an iterative approach to development where requirements are discovered and elaborated in early
iterations.
The approach taken by RUP was to cater for all types of projects by providing a superset of prescribed disciplines, artifacts, and processes. Unfortunately this has led to it becoming labeled as a heavyweight method, because to be successful teams need to be highly skilled in the RUP method to understand what they can discard from these disciplines, artifacts and processes for their particular project without undermining the others that remain, which has, in turn, led to teams leaving many things that they don’t need which directly increases both cost and time.
So although RUP has been used successfully to deliver many projects, it’s also had its share of failures due to unnecessary complexity and cost/time overruns.
Agile
In the late 1990s in response to the perceived heavyweight and overly prescribed approach taken by RUP, lighter-weight adaptive methods were developed. Together they became known as Agile methods, culminating in the Agile Manifesto created in 2001 that was a set of practices and principles which define and underpin all Agile methods. These Agile methods included Scrum and Extreme Programming (XP) among others.
Agile methods focus on delivering high quality, high value, working software quickly to customers in an iterative and incremental fashion, accelerating time-to-market while also being highly adaptable to changing business environments.
Agile methods take the opposite approach to RUP with its superset of project disciplines, artifacts, and processes, and instead encourage teams to start with the minimum and only add to them if necessary. High value, high quality, adaptability to change and low cost are the hallmarks of projects using well-managed Agile methods.
Agile methods have become increasing popular in the last 10 years and are now used successfully in organizations all over the world. For example, the Hybris Commerce platform was successfully built internally using Scrum and other Agile methods, and these practices and processes have been adapted as the platform and company size grew in size and sophistication.
Over time, the various flavors of the Agile methods converged and now when people refer to Agile they typically refer to Scrum usually combined with XP technical practices such as continuous integration, test-driven development, pair programming, etc.
An overview of the Scrum process is shown below:
However Agile is not without its disadvantages:
It’s great for continuous streams of development in a production-like mode for a company producing software products but doesn’t cater for project environments with kick-offs, requirements analysis, acceptance testing, deployment phases, etc. or corporate governance processes. It’s designed for small collocated teams, not large distributed teams. It’s designed for internal teams and doesn’t specifically cater for commercial environments where there are contracts and potentially multiple different organizations responsible for delivering the solution.
So although projects using Agile methods have been very successful, there have also been a significant number of failures, particularly when the above constraints are not adequately being considered. Also, many of these project teams claim to be Agile when in fact they are only following a subset of Agile principles or practices, or often they are actually following a Waterfall approach dressed-up asAgileapproach (“we have daily stand-ups and a backlog, therefore we are Agile”). For Agile methods to be effective and successful their principles and practices are finely balanced as they are dependent and support each other.
Counter to many people’s understanding, to be successful with Agile teams require a high level of discipline and focus, and it doesn’t mean throwing all process and documentation out of the window. You will probably find more process in a properly executed and managed Agile project than in a Waterfall project. However, those processes are there for a very specific reason, and all add demonstrable value.
DSDM Agile Project Framework
Although not as well known as the previous methods, DSDM (Dynamic Systems Development Method) was originally developed in the UK in 1994 as a closed consortium of several large UK organizations. They collaborated to create a project management method called DSDM based on their shared experiences with Waterfall, unified process and other SDLC approaches.
Members of the DSDM consortium were also involved in the origins of Agile and the creation of the Agile Manifesto as they recognized the importance of leaner software development practices within projects. Later the consortium was opened up to other members outside these large enterprises, to grow and widen the use of DSDM.
There were two major revisions of DSDM in 2007 and 2014 to combine the existing project management best practices
with Agile development best practices, and it was renamed to the ‘DSDM Agile Project Framework.’ Effectively becoming a best practice project management wrapper around Scrum, and specifically designed to fit corporate environments and governance without compromising Agile principles.
The diagram below shows the phases of the DSDM Agile Project Framework:
DSDM is based on a fundamental principle that scope, time, cost and quality cannot all be fixed, and of these, on time, on budget and high-quality are the most important aspects of successful projects, so scope needs to be allowed to vary. This is very much in line withAgilepractice which typically controls the same aspects hence it’s a natural pairing with Scrum, where Scrum is used for the Engineering activities, wrapped by the other DSDM phases that provide the other activities, reporting, governance, etc. required for project environments.
So despite being used successfully in many organizations, DSDM is not well known because it has not had the same evangelizing and self-promotion activities over the years compared to several of the other well-known methods. Additionally, it’s been designed for internal use, i.e. for running projects within an organization and not where there’s a customer/supplier relationship and contracts between the customer and delivery teams. So some adaptations are required in commercial environments. It is also not designed for fixed-scope type projects, and again needs to be adapted in these cases.
The ‘Right’ Approach
So what is the ‘right’ approach to delivering a successful software development project?
In the right context, the Waterfall method can be used successfully. In environments where all detailed requirements are known with high certainty up-front, where there is very little change or business uncertainty and where there is little technical risk. However, even in these environments, considerable risks remain by leaving testing and customer visibility until the very end when it’s too late to change anything of significance, and the longer the project duration the greater these risks become.
RUP can also be successful where customer and project teams have in-depth knowledge of the method and are skilled
at tailoring it to their needs. However this is difficult to get right, so teams often leave unneeded work in the project, leading to additional cost and time.
Agile methods such as Scrum are great for the development of software in environments where there are highly collaborative relationships between the business owner and project teams, however, these methods have very little regard for the types of activities that typically occur at the start and end of projects. Although in recent years, methods like DSDM have evolved to tackle these shortcomings with the development of Agile project management frameworks and wrappers around the process and practices used by Scrum and XP.
There is no one-size-fits-all method for successful software development. With all methods, there are successes and failures, regardless of whether using Waterfall, RUP, Agile or less well-known methods like DSDM. The ‘right’ approach is to select the appropriate method for a given project context, and sometimes by taking a blend of different methods. The key is being appropriately skilled and experienced to understand the different options and how best to apply them.
HYBRIS ALF IMPLEMENTATION
Implementation Projects During the lifecycle of a Hybris Commerce solution, there are various types of projects, starting with an initial implementation project. The goal of this project is to define the requirements for the solution, build the solution to meet the requirements, and then deploy the solution to the production environment where it’s accessible to end users. Sometimes this is a ‘re-platform’ project, i.e. replacing an existing solution, or ‘greenfield’ where there is no existing solution.
Following the initial implementation project, when the solution is built for the first time, there can be subsequent implementation projects to build additional slices of the solution during its lifecycle.
An example initial implementation project is highlighted in red in the diagram below:
In the above example, the initial implementation project is split into three releases, each release deploying to the live production environment and the application management workstream, and each release building upon the solution developed in the previous release. The project can be managed with any number of different release cycles, and generally, these initial sequential release cycles are often referred together as ‘the implementation project.’
In some cases, the implementation project can continue on a long-term basis with any number of consecutive releases, e.g. if there’s a continuous stream of development. In other cases, the project activity stops once development is ramped down, and smaller change requests can instead by managed by the application management team outside of a project environment. Each approach depends on the customer and the situation.
The above example also shows other types of project examples, e.g. integration and migration projects. These are projects specifically to manage other types of activities in a project environment, such as building integrations to a new external system or migrating the underlying Hybris Commerce platform from one major version to another. There may
also be other types of projects, e.g. infrastructure, security, performance, etc. The integration project may also be managed as an implementation project if the Hybris Commerce solution is being extended or new features are being developed.
In this section, we are looking at specific approaches to managing the initial implementation project, although these approaches and practices will also be applicable for subsequent implementation projects.
Project Considerations
SAP Hybris Commerce implementation projects involve software development to build the solution on the Hybris Commerce platform. Therefore these projects need to be managed as software development projects. Over the years, many different SDLC methods have evolved to help teams manage the inherent complexity and uncertainty of software development projects. There is no one ‘right’ method to use; it depends on the context of a particular project.
This context will include factors such as:
Governance processes and policies – Are there strict sign-off or other corporate project governance requirements that need following? Decision-making processes – Who can make project-related decisions? Are they empowered? Or is it decision-by-committee? How quickly can decisions be made? Levels of collaboration – Can the people involved in the project collaborate real-time during the project? Or will it be a hands-off approach? Availability of skills and relevant experience – Do relevant technical skills and experience exist? What project management experience does the team have? Are teams more familiar with one SDLC compared with another? Certainty of requirements – What is the likelihood of changing requirements? What flexibility is required? Compliance constraints – Are there any compliance or other constraining factors? e.g. Sarbanes-Oxley (SOX) compliance? Language and Location – Where are the team located? What time-zones? Do they speak a common language? Team distribution – Is the team co-located or distributed? What are the ways of working with the teams? Are they part of a single organization or multiple? Legal – Are there contractual relationships between different parties? These will drive behavior. Plus other considerations
In any project, one of the most important considerations is to decide what to control. This is demonstrated by the well-known project management triangle (also known as the iron-triangle):
The project management triangle shows the relationship between projects scope, time and cost. These three fundamental aspects of any project are all dependent on each other and tightly related. Adjustment to one will have implications for the other two. Quality, in the middle, must always be considered too, although unfortunately it’s often overlooked and assumed because there is no specific direct dependency.
In an ideal world project teams want to control all four aspects, so all scope is delivered on time, on budget and with high-quality. However in a project environment, no matter how good the planning, something unexpected will always happen, so the plan must be adjusted. It won’t be possible to fix all four. The question is: how is the plan adjusted? What aspect will be flexed?
When considering this question, it’s very important to think about the likelihood of something unexpected happening. As mentioned earlier, software development is inherently complex and uncertain, and one of the major factors is the rate of change. The greater the rate of change, the greater the risk. For e-commerce projects, the rate of change during a project is typically very high. For example:
Businesses often don’t know exactly how they want the solution to work functionally or non-functionally (e.g. how much traffic to expect, peak periods, etc.) The e-commerce solution often integrates with multiple external systems, each of which can be subject to change with direct knock-on effects to schedule or scope The competitive environment can be very fast changing. If a leading competitor makes significant changes to their e-commerce website to offer new features, often other competitors want to react very quickly. Technology changes very quickly, e.g. social media, web technologies, mobile technologies, new releases of the Hybris Commerce platform, etc.
Therefore Hybris Commerce projects often operate in a very high change environment, which leads to much greater uncertainty and complexity that needs to be managed. So it’s critical that the rate of change is properly considered when selecting the approach and deciding which aspect of the project management triangle to flex.
It’s not a good idea to allow quality to flex. A poor quality implementation leads to much greater issues once the solution is live. Issues are much more expensive to fix later and end users are exposed to lots of problems which can lead to lost sales and long-term brand damage, which will often far outweigh any perceived upfront savings. Not to mention the morale of the teams left to deal with the issues, often in firefighting and escalation mode for extended periods.
Therefore the decision on what to flex should be a choice between scope, time and budget. To almost all businesses,
1. 2.
the cost is very important. It is a key factor in the return-on-investment (ROI) decision-making process when they decide which projects to invest in, and they want to ensure these costs are controlled and projects delivered for that budgeted cost, otherwise it will have knock-on effects elsewhere in the business. In e-commerce environments, time is often also very important. There are usually business critical factors that drive a particular timeframe or go-live date.
For people-intensive projects, cost and time are tightly dependent because people are required to develop the scope, and these skilled resources are expensive. For example, in a software development project, if scope is fixed, and delivery is behind schedule it’s very difficult to flex cost and keep time fixed by ‘throwing extra people’ at the problem, as this often creates new inefficiencies which have consequences for quality and often doesn’t actually deliver the intended time-saving benefits, resulting in both time and cost increasing, or quality suffering, or all three. On the other hand, where scope delivery is fixed, and behind schedule, it’s not possible to keep costs fixed and allow the time to flex because extra time means extra person days which means extra cost.
Therefore typically there are two choices for managing these types of project:
Variable scope – control time and cost, and allow scope to vary (risk managed by reducing scope) Fixed scope – control scope, and allow cost and time to vary (risk managed by incorporating additional risk buffer in planned time & cost)
The business and project team need to agree to this choice before the project starts, and if there are contracts between the parties, these contracts need to be set-up accordingly because they will drive relevant behavior.
Fixed vs Variable Scope
Within this Project Delivery Framework, Agile (developed for variable-scope there are frameworks covering both the implementation projects) and Iterative (developed for fixed-scope implementation projects) approaches. SAP Hybris Project Delivery Teams use and recommend the Agile Framework. This is because many years of experience with e-commerce solutions has shown that successful projects are more often measured on whether they were delivered on time and on budget and not whether every scope feature was delivered irrespective of value. It also showed that the naturally high rate of change in e-commerce projects requires an approach that supports very flexible scope changes, which the variable-scope approach does by design. So the focus has been on developing a variable scope framework, called the Agile Project Delivery Framework. This approach has been developed, continuously improved and used very successfully with many different customers by SAP Hybris Expert Services project delivery teams over several years.
The Iterative (fixed-scope) approach can be equally valid in the appropriate context if managed correctly, and many organizations prefer this more traditional approach. If the requirements and exact scope/deliverables need to be agreed and signed-off before the build begins, to avoid any ambiguity later in the project, then the Iterative Project Delivery Framework can be used or adapted.
Selecting the ‘Right’ Approach
As discussed earlier, the ‘right’ approach or method to deliver a successful Hybris Commerce implementation project depends on the particular context of each project. Every project is different, and trying to force a method on a project where it doesn’t fit will create problems and hugely increase risks.
For example, applying a Waterfall (Iterative) approach with fixed-up front requirements and design to a project with very fluid or uncertain requirements in a very changeable environment will be very challenging. Instead, a variable scope Agile approach would be much better suited for this project to allow for flexible scope changes throughout the project as
requirements change, as well as other benefits of Agile such as providing regular deliveries of the solution as the project progresses to allow business users to assess whether it meets their needs and being allowed to change their minds. However this very flexible Agile approach might not be suitable for other reasons, so another method might be more appropriate.
It is critical to design the approach for a specific project by taking the needs of the project first, selecting the most appropriate method, then fine tuning it as necessary. There is no one ‘right’ approach for all projects across all organizations. The key is understanding the options and how to apply them without compromising the underlying factors that form the foundation and underpin the benefits of that method.
The factors discussed above need some consideration when selecting the right approach for a particular project. For some projects, Agile will be a perfect fit, for others, the Iterative approach will be more suitable.
HYBRIS ACTIVATE COMMERCE INTORDUCTION
SAP Activate for Hybris Commerce SAP Activate is an ‘innovation adoption framework’ focused on expediting implementations throughout the customer lifecycle while maximizing their use of out-of-the-box features and minimizing extensions or customization, to enable customers to take advantage of future product innovations with minimum effort.
Starting in 1998, SAP developed the Accelerated SAP (ASAP) methodology for the implementation of its on-premise Enterprise Resource Planning (ERP) solution. This methodology followed a traditional Waterfall approach that was typical for ERP implementations at the time. It was continuously enhanced over subsequent years with new releases of ASAP, and as SAP developed new solutions, it was expanded to cover other on-premise implementations of products such as Customer Relationship Management (CRM), Supplier Relationship Management (SRM), etc.
When ASAP 8 was released in 2012 and supported the implementation of SAP Business Suite including Analytics, Business Warehouse, and other predominantly on-premise solutions. This version of ASAP was built to support SAP’s transition to using the assemble-to-order approach in services and project delivery.
The ASAP 8 release consisted of multiple variants including:
Standard ASAP Assemble to Order (A2O) ASAP Simplified Rapid Deployment Solution (RDS) ASAP Agile ASAP
Recently SAP added cloud-based solutions to its portfolio including solutions such as ByDesign, Cloud for Customer (C4C) and Ariba. These cloud-based solutions required a different implementation approach, so SAP developed a new additional methodology specifically for these solutions called SAP Launch – built on existing methodologies developed for SuccessFactors, ByDesign, and Ariba.
As SAP acquired new companies, its product portfolio further expanded with new products with different technologies and their specific implementation approaches, methodologies and deployment models; some cloud-based, some on-premise. SAP also added mobile solutions to its portfolio, again with different implementation and deployment models.
SAP quickly recognized that all these different approaches and standards were adding complexity, with a lack of alignment in terms of language, naming, deliverables, tasks, artifacts, etc. which if left alone would create confusion and inefficiency internally and for customers and partners. So in 2015 SAP created SAP Activate.
1.
SAP Activate consists of three components:
SAP Best Practices – business and technology processes optimized for the relevant SAP products Guided configuration – content lifecycle management tools to configure and test the selected SAP Best Practice processes, enabled for business users without IT involvement. SAP Activate methodology – new implementation methodology that builds on proven approaches and SAP’s experience to offer a consistent, Agile-style approach for any deployment type – cloud, on-premise, hybrid, or mobile.
The methodology contains the best practices from ASAP and SAP Launch to create a harmonized methodology and practices for all SAP solutions while allowing for product specifics and variations within different variants. SAP Activate will replace and succeed ASAP, SAP Launch and other product-specific methodologies.
SAP Activate Methodology
The SAP Activate methodology is developed to take a whole-lifecycle approach, similar to the SAP Hybris Application Lifecycle Framework (ALF) for Commerce. So in addition to the initial implementation project, it is also focused on operations and future innovations. As such a key goal of SAP Activate is to use best practices to reduce customizations away from the standard product, which in turn reduces effort and cost, and subsequently allows customers to take advantage of faster deployments of innovations released in new product releases.
SAP Activate recognizes there are distinct differences between cloud-based and on-premise implementations, and also hybrid approaches, so there are different SAP Activate variants that specifically cater for these different types of deployment models, and also product-specific variants where appropriate.
For example, SAP Activate variants include:
SAP Activate methodology for S/4HANA – New Implementation: On-Premise SAP Activate methodology for Business Suite and On-Premise – Agile SAP Activate methodology for S/4HANA – Cloud Enterprise Edition SAP Activate Methodology for Public Cloud
However, all variants will share the same overall structure, phases and objectives and all focus on the same key characteristics:
Start with ‘best practices’ (knowledge assets and pre-built content) that serve as starting point for initial fit-gap analysis workshops, to ensure implementations are in line with product best practices and not excessively
1.
2.
3.
customized. Use Agile practices during the implementation to validate the solution with end-users as quickly as possible and ensure fast feedback cycles. Ensure quality is built-in from the start, with a structured quality management plan, quality-gate checks, and appropriate forms of testing throughout the project including acceptance testing.
SAP Activate & Hybris Commerce
SAP Hybris Commerce is a platform with various modules that customers can select depending on their needs. The customer’s Hybris Commerce solution is built on top of this platform by the development of software that extends or overrides the default behavior, and to implement new features and functions.
Because the solution is built around software development, Hybris Commerce implementation projects are managed as software development projects, and as such can be managed using a variety of different software development lifecycle (SDLC) methods depending on the particular project context, from Waterfall to Rational Unified Process (RUP) to Agile. There is no single ‘right’ approach; it depends on the customer, the ways-of-working, the delivery team’s skills and experience, the governance processes, the amount of uncertainty, the rate of change, etc. Therefore Hybris Commerce customers and implementation partners use a wide variety of methods and hybrid approaches.
Over the past years utilizing their experience of a wide variety of different projects, the Hybris Expert Services teams developed an implementation framework called the Project Delivery Framework that was designed as a high-level reference framework specifically for SAP Hybris Commerce projects, with sub-frameworks focused on a specific SDLC approach. The direct delivery teams within the Hybris Expert Services teams specifically developed a sub-framework called the Agile Project Delivery Framework documented in this Hybris Application Lifecycle Framework (ALF) for Commerce, with scope for other frameworks to be created in the future.
This Project Delivery Framework has been developed to be shared with customers, partners and all internal SAP teams so that it can be used as a reference framework for teams implementing SAP Hybris Commerce. With SAP Activate being released, it has also been adapted and realigned to work within the overarching SAP Activate framework while retaining the specifics required for Hybris Commerce implementations.
SAP Activate Methodology Overview
As many SAP Hybris Commerce implementations are on-premise, the ALF was adapted to SAP Activate, for on-premise, as it was the most similar of all the flavors. The following will present an overview of SAP Activate for on-premise as an introduction, for more detailed information, refer to the SAP Activate Jam site.
This diagram shows the phases and life-cycle behavior of the SAP Activate methodology that is common to the overarching framework and all variants:
The adaptation of SAP Activate for Hybris Commerce implementation continues to evolve. The team can apply the SAP Activate for Hybris Commerce by referring to phase activities and key deliverables described in the wiki and the details will be maintained in the Roadmap Viewer in the future.
The specific objectives, activities, tasks and deliverables will vary between variants. The below diagram shows the different phases and primary goal and activities for SAP Activate for on-premise.
Each of these phases is summarized for quick reference purposes. Please refer to the Jam site for more details.
Important note The SAP Activate steps presented here are relevant to other SAP products; therefore they may vary for Hybris Commerce, and some steps may not be applicable. This information is provided for reference only to give a flavor of how the Project Delivery Framework documented here in ALF for Commerce will be adapted to SAP Activate in the future.
HYBRIS ACTIVATE OVERVIEW
SAP Activate – Overview The SAP Activate methodology for SAP Hybris Commerce is designed to support project teams in the new implementation of SAP Hybris solutions on-premise or in privately managed cloud environments.
Overview
The methodology is structured into project phases, each containing a list of deliverables and supporting tasks. Along the hierarchy, users will find accelerators such as templates and examples to support their implementation project (for example or Fit/Gap Analysis Workshop Guide ALM – Solution Manager Processes).
Benefits
The SAP Activate methodology offers the following benefits:
It enables consistency, reduces complexity and increases quality by creating and delivering services on one common platform. It is scalable – supporting all types of services delivery from RDS/A2O deployments to large prototyping solutions. It is Prescriptive and Comprehensive – offering guided work procedures for project teams, deliverables for project managers and accelerators for all users. It delivers innovation through the focus on Agile Deployment, Application Visualization and use of Cloud-based Deployment approaches. At the same time, it is leveraging sound project delivery practices like formal Project Quality Gates for traditional and RDS projects.
Guiding Principles
The SAP Activate methodology is built to support customers, SAP and partner teams during the implementation projects that are delivered individually or as part of an engagement under the SAP MaxAttention or SAP
ActiveEmbedded agreement. The methodology builds on the following guiding principles
Re-use of knowledge assets and pre-built content like Model Company, RDS or Best Practices Leverage the flexibility of the cloud Agile solution deployment with incremental and iterative build of high-priority capabilities Co-Innovate with Customer Implementation and Operations fully supported with / a Innovation Control Center Operations Control Center nd for Premium Engagement Customers Mission Control Center
Target Audience
The methodology is developed primarily for SAP customers, partners and the Service and Support Teams, specifically the following roles:
Project manager and project leadership Project team members Application and technology consultants Solution and Application Architects Business Process owners IT organization leaders SAP partners
- HYBRIS ACTIVATE DISCOVERY
SAP Activate – Discover Phase The Discover phase is the first part of the discovery and planning activity of a new project.
Its primary objective is high-level alignment between the customer and the project team on the why/what/how/when/cost/risks of the project. This is essentially a feasibility/pre-sales activity before any significant implementation effort is spent on the project.
The goal of the Discover phase is for the customer and project team to explore and agree on a high-level common understanding of:
The ‘why’ – business goals and objectives of the project The ‘what’ – high-level scope, prioritization, and estimated effort The ‘how’ – approach, methodology, and ways of working The ‘when’ – high-level project plan, milestone and resource planning The ‘cost’ – estimated project costs including project team, infrastructure, licensing, etc The ‘risks’ – business/project/technical risks of the project
Together these will give the customer enough information to decide whether to invest in the next phase of the project, i.e. the Prepare phase, which will explore these topics in depth. Or maybe the customer decides to not continue with the project at this stage. It’s much better to discover this earlier rather than later when significant effort and resources have already been committed.
Typically, the Discover phase starts with the first discussions between the customer and the members of the project team and concludes when the Prepare phase begins. It could last weeks or months, depending on the readiness, the availability and the timeline of both the customer and the project team. Usually, the Discover phase only occurs once in the lifespan of a single project when the customer is assessing whether to proceed with the project or not.
Key Activities
Discover the business goals and objectives of the project Validate the approach, methodology, and ways of working Define a high-level scope of the project, both technical and functional
Key Deliverables
Strategic Planning Application Value and Scoping Trial System Provisioning (optional)
- HYBRIS ACTIVATE PREPARE
SAP Activate – Prepare Phase The primary objective of the Prepare and Explore phases is to establish the foundations for the project from business, technical and project management perspectives.
The Prepare phase focuses on conducting proper preparation and planning to get a project started optimally. Otherwise, it can become an inefficient and frustrating exercise for all parties and the project team will not have all the information it needs.
Key Activities
Identify business value objectives Validate the project objectives Define project goals, a high-level scope, and a project plan Document all initiation activities in the project charter Establish project standards, organization, and governance Define the implementation strategy Define roles and responsibilities for the project team Establish a project management, tracking and reporting mechanism for delivery Prepare for the Explore phase
Key Deliverables
Init Planning Organizational Change Management (OCM) Enablement Charter (optional) Team Enablement Activate Solution (optional) Project Delivery Platform Setup Run Prototyping QG1 – Run Quality Gate Prepare to Explore
- SAP ACTIVATE EXPLORE
SAP Activate – Explore Phase Every project release will have an Explore phase. If it is the first project release, the Explore phase will immediately follow the up-front Prepare phase. If it is a subsequent release, the Explore phase will follow the Realize/Deploy phase of the preceding release.
The activities and deliverables remain the same for each Explore phase, however, subsequent Explore phases are typically shorter as they already have a starting point from the previous Explore phase.
Unless otherwise noted, this guide will describe the Explore phase for the first project release. This will enable the reader to understand the full set of activities. For subsequent Explore phases, some of these activities may be shortened or omitted as appropriate.
The Explore phase is best delivered as a series of onsite workshops in close collaboration with the customer, the project team, and other important stakeholders. As well as being the best format for gaining understanding and discussing the various topics, these collaborative workshops also enable the various parties to establish personal and working relationships which are very important for the success of the project.
Key Activities
Prepare, setup and conduct workshops Identify master data and organizational requirements Define functional requirements Define non-functional requirements Design Architecture & System integrations Define environments and tooling Define Quality Management and Testing strategy Associate business requirements to the process hierarchy Analyze learning needs and develop a training strategy Plan and finalize project release schedule and budget Obtain business sign-off prioritized backlog and design documents
Key Deliverables
Organization Change Management Planning Enablement Analysis Data Migration Design Technical Architecture Definition Technical Design (optional) Fit-Gap Design Design Review Story Prioritization
Verify and Accept Data Volume Planning (optional) Data Volume Design Custom Code Impact Analysis (optional) Sizing (optional) IT Infrastructure Definition Operation Impact Evaluation Security Design Dev Setup Project Delivery Platform Setup (optional) Q2 – Run Quality Gate Explore-to-Realize
- HYBRIS ACTIVATE REALIZE
SAP Activate – Realize The primary objective of the Realize phase is to iteratively analyze/design/build/test the software to meet the functional and non-functional requirements of the current release as defined during the preceding Explore phase.
Essentially the Realize phase is based on Scrum, the most commonly known Agile method (https://en.wikipedia.org/wiki /Scrum_(software_development)).
However whereas textbook Scrum is designed for continuous software development internally within a single organization, here it’s used within the context of a release which in turn is within the context of a project, often where the project team and customer belong to different organizations and the project is being delivered on a contractual basis. Therefore the textbook Scrum approach has been adapted within this phase to cater for these additional factors.
Note that in Scrum iterations are called ‘sprints’. These terms can be used interchangeably during the Realize phase as they have the same meaning, however, it’s recommended to use sprint because that communicates to everyone that the teams are using a Scrum-based approach.
The sequential activities of the Realize phase are:
Set-up sprint (commonly called sprint zero) – preparation for the subsequent implementation sprints, e.g. set-up tooling, environments, and test data. Implementation sprints (multiple) – fixed duration software development iterations, i.e. analyze/design/build/test. Hardening sprint – finalization of the software produced in the previous implementation sprints in preparation for UAT. User acceptance testing (UAT) – formal customer acceptance testing of the software.
Typically there are also a number of parallel activities that are often planned as part of this phase, although often they are managed as a separate cutover activity, for example, end-user training. However, they are all dependent on the software (and therefore deliverables) of this Realize phase so need to be planned together.
These other types of activities can include:
Non-functional testing – e.g. performance testing System integration testing – validating interfaces with external systems
Security testing – e.g. penetration, cross-site testing End-user training – e.g. training business users or train-the-trainer Content creation – e.g. creation of web content images, text, etc. Data loading/enrichment – e.g. preparation of product images, prices, text, etc. Data migration – e.g. importing customer/order data from a system being replaced Knowledge transfer – e.g. to support transition to application management team
Key Activities
Setup sprint that covers infrastructure, development and tool-setup activities, knowledge sharing and first sprint preparation Establish the solution landscape Implementation sprints where analysis / design / build / test activities are performed in time-boxed iterations Conduct overall end-to-end testing of the solution within the QA environment Setup production environment Prepare for data migration and data archiving Conduct system integration testing Conduct performance testing Conduct security testing Hardening sprint activities as the last sprint of Realize phase Conduct project team and key user training Finalize end user training materials and documentation Support User Acceptance Testing
Key Deliverables
Execution, Management, and Controlling Organizational Change Management Enablement Realization (Optional) Configuration – Introduction Test Execution Project Delivery Platform Setup Dev Setup QAS Setup Cutover Preparation Data Migration & Verification (Optional) Test Preparation Custom Code Management Execution (Optional) Product Enhancement (Optional) Security Implementation Sizing, Scalability Verification (Optional) Operation Implementation (Optional) Business Process #1-n – Detailed Design (Iterative) Business Scenario #1-n – Detailed Design (Iterative) Technical Solution Design (Iterative) IT Infrastructure Setup and Test (Optional) QG4 – Run Quality Gate Realize to Deploy
- HYBRIS ACTIVATE DEPLOY
SAP Activate – Deploy Phase The primary objective of the Deploy phase is the successful deployment of the solution delivered by the preceding Realize phase into a production environment so it’s accessible to end users. This phase includes the provision of immediate post-live support to ensure stability and fast resolution times in case of any issues.
One of the key fundamentals of Agile is that software is delivered regularly in an iterative and incremental manner. This is done by splitting projects into releases and releases into sprints. It’s also important that each of those deliveries is thoroughly tested as soon as possible, ideally by real end-users.
Therefore although not mandatory, it’s highly recommended the software developed during every release is deployed to the live production environment accessible to real end-users during a deploy phase at the end of each release. This will allow the customer and project team to:
Verify functionality, assess real business value, and gather feedback from end-users as soon as possible so changes can be fed into the planning for the next release. This feedback will allow the customer to adjust the prioritization of new features according to real feedback, rather than based on assumptions about what end-users want. Verify non-functional aspects of the software by proving the solution in a real production environment, e.g. the solution scales as expected, performance meets requirements, caching strategies work as expected, etc. Testing can only verify so much. Only a real-live production environment with real end-users will properly verify that the non-functional requirements are met. Feedback here will also allow for better prioritization in the next release, e.g. the technical value of a new caching strategy to improve performance might be increased which makes it higher priority compared with some less valuable functional requirements. Avoid the much riskier “big-bang” approach where software is developed over several releases but only deployed to live environment after several releases. With big-bang releases, any issues will be found too late to change, which will have a major impact on users and the long-term success of the project, e.g. architectural issues are very costly to change later.
The purpose of the Deploy phase is to support this deployment into the live production environment and to provide the customer with dedicated post-live support immediately following the go-live.
Key Activities
Organizational and production readiness check Pre go-live user training delivery Technical and system testing, as necessary Setup operational support organization Cutover to production including: Cutover plan update Cutover simulations Data migration Content creation User IDs and profile created
Operational and live production system environment Project closing including lessons learned
Key Deliverables
Execution, Management, and Controlling Operation Readiness (Optional) Enablement Realization (Optional) Organizational Change Management (Optional) Dress Rehearsal (Optional) IT Infrastructure Service Finalization (Optional) Product Cutover (Optional) QG4 – Run Quality Gate Deploy to Run
- HYBRIS ACTIVATE RUN
SAP Activate – Run Phase The primary goal of this phase is to further optimize and automate the ‘operability’ of the solution.
Operability is the ability to maintain IT systems in a functioning and operating condition, guaranteeing the system’s availability and required performance levels to support the execution of the enterprise’s business operations.
Key Activities
Run the implemented SAP solution Assess operation standards to optimize solution operation Set the standards for tool use Transition the optimized system to production Continue value tracking and reporting
Key Deliverables
Closing Hyper Care Support (Optional) Handover to Supper Organization (Optional) QG5 – Transition to Support Organization
- HYBRIS ACTIVATE STREAM VIEW
SAP Activate – Stream View The stream view of the methodology allows for an overview of the phases, streams, quality gates and optionally deliverables in a relative time perspective.
The stream structure provides flexibility in that additional streams can be added to allow for situations that are not covered with the standard streams. In addition, deliverables can be scaled to meet the size and complexity of the project.
Level 1: Stream View
Level 2: Stream View with Deliverables
Workstream Descriptions
Project Management – Covers planning, scheduling, governance, controlling and monitoring the execution of the project
Application: Design & Configuration – Covers the validation of scope, identification of detailed business process requirements, fit-gap analysis, and functional design of the solution. This work stream also covers the demonstration of the configured/developed solution to the customer project team after each iteration cycle for customer acceptance and identification of adjustments needed for the next iteration
Application: Testing – Covers test strategy, planning, test case development, and execution of User Acceptance Test, Integration Test, Performance Test, System Test, Regression testing
Application: Integration – Covers identification of integration requirements, integration points, integration approach, and integration solution design. The work stream also includes the setup of integration environment and middleware between the solution and any external systems
Application: Customer Team Enablement – Covers value management, organization change management, and end user training
Custom Code Extensions – Covers the enablement of the customer project team to work on the project effectively. This include standard product orientation to prepare the customer for product requirements and design discussion, as well as key user and admin training to prepare the customer for test case development and test execution
System & Data Migration – Covers the discovery, planning,
and execution of moving legacy data to the new system and archiving of legacy data. This work stream also covers planning and execution of activities to cutover the system i nto production including the hyper-care support period shortly after cutover
Technical Architecture & Infrastructure – Covers the solution landscape, deployment concept, system architecture, technical system design, environment (development, testing, production, failover) setup, technology operations standards and process
Transition to Operations – Covers the establishment and setting up of the helpdesk process, incident management process, post go-live change management process, & user related operations standards and process
A Deliverable is an outcome that is delivered during the course of the project. Several deliverables comprise a workstream.
A Task is the work to be performed. One or several tasks comprise a deliverable.
1 comment