The path to the cloud can be complex. Cloud infrastructures aren’t necessarily enablement ready; therefore, successful companies have a strong understanding of how an infrastructure-as-a-service (IaaS) model works. During a recent SAPinsider Online Q&A, cloud and virtualization experts Ettienne Wilson and Harrison Holland of Big Concepts answered live reader questions on adaptive enablement, the financial benefits of moving SAP systems to the cloud, and how to manage customizations for an effective migration. Following is an abridged version of some of the questions that Ettienne and Harrison fielded. The full transcript is available on SAPinsider Online.

 

Q: What does adaptive enablement mean in terms of cloud migration, and why is it so critical to the success of cloud-based SAP solutions?

Ettienne Wilson (EW): When people talk about virtualization in the IT world today, it’s typically perceived as the abstraction of the physical compute layer from the rest of the software stack, including the operating system (OS). SAP adaptive enablement takes this a step further and abstracts the SAP application from the OS layer as well. Each component in the SAP system gets “containerized.” For example, the database, central service, and dialog instances get an IP address and storage specifically associated with that component. The best way to think of this is how you would implement high availability and allow the SAP components to fail over and fail back from one physical or virtual machine to another. There is obviously a lot more to adaptive enablement, for example, planning instance numbers, user provisioning, and so on. This is important because this allows you to not only be agile in failures of a physical or virtual machine, but it also gives you flexibility in maintenance and, most importantly, can ultimately help you avoid vendor lock in, even to the extent where you could move from one provider to another.

Q: What are the most common challenges when migrating a traditional SAP ERP solution to SAP Business Suite on SAP HANA in the cloud?

EW: Doing any form of migration is not just a lift and move, and the challenges can be more significant depending on the current state of your SAP ERP system. Migrating a traditional system to SAP HANA is very much like a traditional migration from a process perspective, but the big challenges I have seen are understanding your current workload and growth so you can plan the target environment correctly; getting to the correct source level on your systems (for example, are you at the required support stack level? Are you already Unicode compatible?); and also understanding your level of custom code involved. Another big challenge is that customers tend to not take the opportunity to re-architect the solution and do things like adaptively enable their environment and address high availability and disaster recovery. They also often do not have an overall cloud strategy that includes IaaS, platform-as-a-service (PaaS), and software-as-a-service (SaaS) models.

Q: What are some considerations when moving from on-premise SAP products to SAP SuccessFactors solutions, and what are the typical issues going into the realization phase?

Harrison Holland (HH): From a functional perspective, the key elements to consider would include: First, how you envision the end-user experience (for example, a single portal for all HR functions versus simply talent management); and second, whether you are eventually looking to migrate off the SAP platform to a full cloud solution. In a hybrid model, all talent-related functions (learning, recruiting, performance reviews, and so on) are managed through the SAP SuccessFactors cloud platform, while all core HR functions (such as hiring, employee moves, and payroll) remain on premise. A side-by-side model is different because core HR functions for certain employees are placed in the cloud, while these functions remain on premise for other employees. It’s important to note that the side-by-side model is typically an intermediary step between transitioning all core HR functions to the cloud and not a recommended long-term solution. From a technical perspective, it’s important to consider connectivity and security: For instance, will your gateway be standalone or embedded in SAP ERP? How will you use the web dispatcher?

Q: Beyond the fact that you are changing capital expenses into operating expenses, are there other financial benefits to using the cloud?

EW: When comparing the costs of on premise to cloud, one needs to compare apples with apples, and this would then not just compare hardware costs, but all costs related to the data center, power and backup power, floor space, access control, and so forth. A customer should also look at the cost of lost opportunity. If you need to run a pilot or R&D project, it would make far better sense to use the cloud. Your proof-of-concept environment could be available immediately, and you would not have layout capital expenses. HH: We typically view three primary categories associated with a cloud value proposition:

1. Server utilization: Many companies have server demands that change dramatically depending on the time of day or even the time of year (seasonal products, for example). When sizing on premise, you have to size for peak capacity. A cloud-based infrastructure can scale on-demand, therefore, cost is directly associated with business volume.
2. Direct versus indirect costs: Direct costs are easy to calculate (such as hardware, floor space, IT labor, and peripheral infrastructure), but indirect costs are a huge consideration point that gets swept under the rug — for instance, what is the efficiency of your IT department as opposed to a cloud provider’s IT department?
3. Capital expenditure versus operating expense: This category was just addressed in the previous question.

Q: What are the benefits of measuring the IaaS end state and the migration path?

EW: Let’s take an example of the use case of disaster recovery (DR) in the cloud. Not having to pay for a second data center is obviously a direct cost benefit, but being able to repetitively and systematically test DR in a cloud environment has significant benefit over a DR contract where you can only typically test your DR strategy once in a contract window with a 30-day notice to the provider. Cloud has definitely gone beyond just the benefits of cost, and in today’s digital age, the agility that comes with cloud has significant benefits like speed to market, ability to scale, agility in system lifecycle management, and how you execute on your development operations.

Q: Can you discuss any security concerns that are associated with virtualization?

HH: This is an open-ended question, as there are a number of angles by which this can be approached. A few considerations would be connectivity between your end users and your virtual system; data encryption both at rest and in transit; insider threat; and privilege escalation, among others.

Q: Do you see heavily customized SAP ERP, SAP Supply Chain Management, and SAP Business Warehouse systems ever going to a SaaS model? If so, how should organizations plan for it?

EW: Anytime there is a heavy amount of customization involved, a migration gets considerably trickier. You would have to evaluate if your customization is based on absolutely needed business functionality. If so, then it would possibly eliminate a move to SaaS. If the business can see value in a SaaS model outside of direct costs, it may make sense to start planning by going through a discovery phase and figuring out which elements of your current solution can be standardized as part of a migration. Alternatively, a hybrid solution may be the best fit based on your current state if you can identify compartmentalized processes or modules that would fit nicely into a SaaS offering. Ettienne Wilson is the director of SAP Cloud and Virtualization at Big Concepts, a multifaceted consulting firm that specializes in innovative SAP implementations. Ettienne is responsible for delivering agile on-premise, hybrid, full cloud, and virtualized solutions for clients. With more than 20 years’ experience, he has served in a variety of technical and leadership roles, including lead architect, project lead, and lead Basis consultant. In his current role, he researches, recommends, and implements individual solutions for clients while working with and juggling various department priorities, budgets, timelines, and resources. Harrison Holland worked with SAP as both a customer and a consultant for over a decade. His experience has given him the insight necessary to understand any SAP challenge and build an all-star team to fix it. It has also taught him that the consulting industry is full of preventable waste and inefficiency — which is why he has turned his sights toward pioneering change from within. Harrison has a gift for creating a project vision and inspiring others to see it realized.