How Samsung Electronics scales SAP systems for Black Friday

Good morning, everyone. Welcome to Session 223. As many of you know, thousands of customers are already learning SAP on AWS. However, we still get questions from customers and partners asking "Can a SAP system that handles large traffic volumes run well in AWS cloud?" If you are asking similar questions about your SAP systems, then this session is for you.

My name is Sargent Kim and I am a Senior SAP Solutions Architect. I'm honored to be co-presenting today with my customer, Yong Gong Kim, and Bong Kim. YG is the Head of Digital Marketing at Samsung SDS and Bong is the leader in charge of Samsung Electronics GCCRM.

Today, we will share the story of Samsung Electronics with you, specifically. We will discuss some of the challenges Samsung Electronics faced, especially when dealing with large traffic spikes around major shopping events like Black Friday. So we will provide an overview and unpack how they were able to solve this issue by migrating to AWS cloud.

The key theme I want to focus on in this session is SAP modernization architecture. First, I will explain exactly what SAP modernization architecture is. Then, Yong Gong Kim will discuss how Samsung Electronics leveraged SAP modernization architecture in their global CRM system to handle large scale events like Black Friday. After that, Bong Kim will provide a technical dive into how SAP modernization architecture was implemented on AWS utilizing various AWS services. If time permits, we will open up the floor for a Q&A session to address any questions or concerns you may have at the end.

Now, we will dive into the details of Samsung Electronics' modernization journey. To start, let's review what exactly we mean by SAP modernization architecture. I want to explore one question: Can a modernization architecture be implemented for SAP? If you are familiar with cloud computing, you've likely heard a lot about application modernization architecture. However, you may find it difficult to easily answer if this can be achieved with SAP. So this part of our session aims to answer this key question.

Migrating apps to the cloud via re-hosting does not automatically provide the full benefits - elasticity, agility, and flexibility. Application modernization means transforming monolithic architecture into something more agile, elastic, and highly available. The underlying core may be a microservices architecture. However, the SAP solution does not yet support microservices architecture. So what is the solution AWS customers and partners have taken on the path to modernization? They have taken it by implementing some workloads as cloud services to solve pinpoint issues. You can create a more flexible architecture, which we will refer to as a modernization architecture in this session.

Let's explore some real world examples of customers and partners innovating their business with SAP modernization architecture. One example is intelligent document processing. You can imagine manually entering data from invoices or purchase orders into an SAP system is time consuming and error prone. So in that case, you can use Amazon Textract. Textract is a machine learning optical character recognition service. When you use Amazon Textract, you can automatically extract text and input it to the SAP system, saving time and improving accuracy.

Another example is language translation. Employees at a global company often use shared SAP and related systems, but the problem is they speak different languages. So in that case, you can use Amazon Translate. Translate enables cost effective localization and multilingual communication.

The next example is implementing event driven architecture. When a business event occurs in SAP systems, they can trigger AWS services like AWS Lambda. This can start new business processes and update data automatically to improve responsiveness and customer experience.

These examples showcase the innovation unlocked by SAP modernization. I think some of you may be wondering, how do we connect AWS services to SAP systems when integrating AWS services with SAP systems for SAP modernization? The cornerstone technology is the AWS SDK for SAP ABAP.

The AWS SDK for SAP provides access to over 200 AWS services and supports both self-managed and SAP-hosted SAP environments by connecting via HTTPS. It also integrates securely with the AWS SDK. With this, developers can easily leverage AWS services using their existing ABAP skills. So this makes it simpler for developers to harness the power of AWS to easily scale and innovate on top of SAP.

Now, let's take a close look at where the AWS SDK for SAP ABAP sits within an SAP environment. At the low level, we have the operating system with the database layer on top. And on top of SAP NetWeaver, we have ABAP as the programming language. Within this stack are various SAP standard modules that you use in your ABAP programs. In many cases, these modules can be extended by custom ABAP programs. This is where the AWS SDK for SAP ABAP comes in - by integrating with custom programs. The AWS SDK for SAP ABAP enables communication with and use of all 200+ AWS services via APIs.

Additionally, I know many of you are excited about the new Amazon SageMaker service. SageMaker makes it easier for developers to build generative AI applications. It's a fully managed service that provides access to a range of powerful foundation models from Amazon and leading AI companies like Anthropic, Cohere, and Hugging Face. The great news is the AWS SDK for SAP ABAP now supports SageMaker as of late 2021.

To summarize what we have covered so far: You can now easily leverage the AWS SDK for SAP ABAP to create a SAP modernization architecture that helps your business innovate by linking your SAP system with powerful AWS services. By integrating AWS SDK into your SAP system, you can call over 200 AWS services with just a few lines of ABAP code.

Next up, my customer will share Samsung Electronics' story and how they implemented a SAP modernization architecture approach. Thank you for your time and I will now hand it over to YG.

YG: Hello everyone. My name is Yong Kim, Head of the Marketing Group at Samsung SDS here. I would like to explain how and why we decided to collaborate with AWS to modernize our architecture and meet customer requirements. But before we go further, let me brief you on our company first.

Samsung SDS is one of the affiliate companies of Samsung Group. We have 38 years of industry experience as an IT service provider and we have been adjusting our business focus to "Own Cloud" strategy first, along with the slogan "Cloud Simply Fit." Our cloud strategy consists of 3 main parts:

• Our own cloud platform named CCP Enterprise Cloud
• Managed service provider
• Samsung SDS is also one of AWS's MSP partners holding several solid qualifications. For example, we are the first MSP partner who acquired AWS Competency in Korea and we hold 2,100 AWS certifications, which is the greatest number among the Korean MSP ecosystem.

Samsung SDS will continue to provide our customers with an end-to-end managed cloud service from consulting, to migration, modernization, and maintenance service in alignment with our company’s mission.

My team specializes in managed service tailored for digital marketing and we operate the global CRM system for one of our largest clients, Samsung Electronics. In general, CRM stands for Customer Relationship Management. But here we use a slightly different definition: Customer Relationship Marketing. As a core platform of Samsung Electronics’ global marketing activity, the objective of the CRM system is to provide 1.4 billion loyal customers with a variety of membership benefits and rewards. Furthermore, we are aiming to provide the same user experience through both online and offline channels.

The CRM system consists of 4 main parts:

1. Managing customer information effectively, because all the marketing campaigns start from the customer data
2. Loyalty and point management. All benefits are provided based upon membership program and point balances
3. Marketing campaigns itself. We continue to create beneficial marketing campaigns through owned and Samsung Electronics’ own channels. This is a core part of the CRM.
4. Business intelligence. We keep improving the efficiency of the CRM activities via high data analysis and tracking in order to support the global scale of Samsung Electronics’ business.

In implementing a robust and scalable system using AWS, we adopted SAP CRM in Korea and China in 2014 for the first time, and we gradually expanded our system to 9 regions where Samsung Electronics had major business presence. During the gradual expansion process, we made a priority for system performance through distributed systems, and we also considered global compliance like GDPR, GPDR, and CCPA.

This is the right point to explain what made us drive cloud migration. Although we made our best effort to design our own on-premises architecture as custom expectations and requirements kept growing and getting complicated, we encountered several challenges:

• Fixed computing capacity didn't manage proper resource requirements in peak seasons
• Maintaining high availability and low cost became more and more difficult
• We couldn't continue to drive architectural innovation. We felt like we had reached a limit.

So we took a bold step towards cloud migration to overcome our challenges, and it paid off very well. Cloud migration brought significant advantages:

• We could secure the API performance to connect with the diverse internal systems
• We could move away from expensive scale-up infrastructure for database performance
• Furthermore, by improving reliability and agility, we could secure better system stability and data credibility
• Finally, we could save our operational costs significantly, by over 20%

When it comes to cloud partner selection, we were confident in choosing AWS as our face-to-face partner for several reasons:

• AWS is recognized as SAP HANA infrastructure service leader for the 5th straight year
• Each high memory instance, for example the u-type instance, was the perfect fit for our customer’s requirements
• More than 200 diverse services enabled us to achieve continuous modernization
• AWS's financial program like MAP for SAP helped us save costs
• AWS SDK for SAP accelerated our innovation

Therefore, it was the most optimal option for our client’s needs. Let me walk you through some of the details of what we've done for cloud migration and modernization with AWS, and what we learned.

Let's look at the migration details. This diagram shows the pre-architecture before migrating to AWS. You can easily find this is a kind of stereotypical architecture – majority of SAP applications used to take a non-microservices, non-modernized approach. SAP CRM and Hybris are connected with a single database. We normally call it MCOD to support the diverse reporting requirements. We operate the SAP CRM service separately. Furthermore, a separate web system is also a key part of the CRM system to enable API support.

This legacy system was built in 2014 and it was based upon a 4 terabyte HA database, which was the largest database size HANA DB supported among Korean customers. Definitely disaster recovery and high availability was implemented, and 4 terabyte disaster recovery was the 4th reference in Korea.

The main purpose of the CRM system is to provide the data related to customers, membership points, or membership grades. So the CRM system is designed to get a huge amount of data requests from many different internal channels such as Samsung Account, Klax Store, and others. However, as the traffic amount has been continuously growing, the CRM system faced serious capacity limitations to handle all the traffic, particularly when traffic spikes happened around special events such as Black Friday promotions.

We experienced slow response times, even system failures or hangs, which significantly impacted our service quality. We analyzed that all the risks started from the high CPU and memory utilization of SAP App and HANA DB many times, causing performance degradation or system hangs.

The most important point was the SAP App was unable to control transactions. This was the key pain point we faced, and it motivated us to pursue AWS migration.

From now on, let's dive deep into how we modernized our legacy architecture to resolve problems and pinpoints. 4 major pillars were mainly targeted:

1. We applied read enablement to distribute HANA databases
2. To secure better high availability, we switched from multi-tier to multi-target system landscape
3. We adopted Amazon API Gateway to control traffic
4. Last but not least, we optimized our system by adopting the newly released AWS SDK for SAP

First, I'm going to go through #1 and #2, explaining how we could build a more robust and stable HANA environment on AWS.

The first one I'd like to share is SAP HANA read enablement. This is a standard feature in a HANA system landscape, although the primary database is designed to handle all types of transactions. The read enablement feature allows secondary databases to handle read transactions to lessen the primary database's load.

This feature can be deployed in two different ways - connection-based and query-based. As you can see in the diagram, in query-based connection, it uses hint-based routing. By adding a hint at the end of the HANA SQL for read transactions, while connection-based is enabled by direct connection to secondary databases for those transactions.

Samsung Electronics had been doing a lot of thinking on these two and finally decided to go with query-based connection with the hint. Every read transaction is requested after ensuring secondary database availability, and the transaction is processed based on whether or not a hint is added in the SQL. SQL without a hint will be routed to the primary database. For SQL with a hint, the client checks the availability of the secondary database first, and if it is OK, the SQL will be routed to the secondary database.

The CRM system had some custom segmentation jobs which required running heavy SELECT and JOIN SQL statements. We successfully leveraged query-based enablement and it is working very well.

This slide shows how our read enablement load works. Samsung Electronics’ internal legacy systems like Samsung Account and Samsung Pay send a lot of real-time transactions. SELECT or JOIN SQLs are requested - secondary databases handle the SELECT or JOIN SQLs while the primary database immediately responds to real-time transactions. This helped improve operational stability and resource utilization.

The next thing I'd like to share is switching from multi-tier to multi-target HANA system landscape. The CRM system handles Samsung Electronics’ mission-critical workloads and it should be running under any types of unexpected situations. So a robust DR implementation is as important as architecture modernization.

As you can see here, on top of spreading primary and secondary nodes across multiple Availability Zones in a whole region, we installed a separate DR node in another region. Having said that, how to configure HSR between each node and how to design auto-failover when the primary node fails are additional considerations we had to think through slowly.

We lost some benefits of our on-premises HANA DR architecture. It was a traditional DR replication of HDB - the primary database is replicated to the secondary database, and the secondary database is replicated to the DR database, in order. However, this approach gave us two problems:

1. When the secondary database takes over the primary role, the original backup database becomes useless until the primary database recovers.
2. We have to do manual work for DR configuration between the recovered primary database and DR database.

This is the new architecture - we switched it to multi-target replication. As you can see, the primary database is replicated to the secondary database, DR database, and another DR database at the same time. Also we added another DR node with this architecture. Although the secondary database takes over the primary database role, the DR database plays the backup database role, meaning high availability is maintained. Another advantage is we don't need manual reconfiguration - it's done automatically in a couple of minutes.

This diagram summarizes the entire architectural changes. I will not take too much time to repeat. From now on our engineer Bong Kim will dive deeper into the latter parts of the pillars and present how we upgraded our system with AWS. Let me introduce my team lead developer Bong Kim.

Bong Kim: Thank you. Hello, my name is Bong Kim from Samsung SDS. I'm looking forward to sharing the optimization details from this point forward. I will continue to explain the real use cases on system modernization using AWS services.

Let me start from Amazon API Gateway. Samsung Electronics' global CRM system is connected with more than 1 billion global clients through API calling. API traffic is very much unpredictable. So during big event seasons, like Black Friday, the system used to receive much higher API traffic and many times it caused slowness or failure.

Black Friday promotion should be an opportunity to increase our sales. However, if we don't control the traffic really well, it can be a risk to lose our customers. Please imagine how horrible it is.

Amazon API Gateway helped us a lot to solve this problem. As you can see here, the current architecture is redesigned so that API Gateway receives client API calling in front of the CRM endpoint, and it plays the gateway role as its name, between client and CRM. With this new architecture, we were able to distribute and control the API traffic. And if necessary, throttle the traffic to maintain stable system operation.

With Amazon API Gateway, we could operate our system without any critical issues during big event seasons. Here you can see the details of how API Gateway works in the CRM system. We implemented a combination of AWS Lambda and Amazon CloudWatch on top of API Gateway.

If the CPU utilization of the CRM App or HANA DB is more than 95% due to unexpected API traffic spikes, CloudWatch is supposed to sense the signal first and trigger the API Gateway to control the maximum number of transactions to AWS Lambda. All the actions are designed to run automatically without any manual operation.

And finally, we could successfully manage our system and operations with this architecture.

The last thing we implemented is adapting AWS SDK for SAP. Here I am going to share 3 main use cases of ABAP SDK to integrate AWS services into CRM.

The first example shows how we adapted the newly released ABAP SDK for Amazon Simple Queue Service into our system. Customer data loss happened many times if it was requested when the CRM App was not available. In this situation, it was big damage for us. So we changed the order request flow to be sent to Amazon SQS for queuing, and the CRM App is supposed to get data from Amazon SQS when it is available again. By adopting SQS service, we could significantly reduce the risk of data loss even though heavy traffic is requested.

Next is our case of using ABAP SDK for Amazon Simple Storage Service. Before the ABAP SDK was released, we had to maintain a separate file server to exchange data files. The file server had to be placed in between S3 and CRM App. Additional EC2 instances were required. However it's hard to say that was an optimized architecture because the file server was redundant and caused additional costs.

So we changed the CRM App to directly access and process data from S3 storage through ABAP SDK. We could gain significant performance improvement by simplifying the data processing steps and removing the redundant resources.

Lastly, this diagram shows how we could simplify our campaign channel management through Amazon Simple Notification Service. The objective is to attract maximum customer traffic, so we have been operating diverse campaign channels such as email, SMS, push, social media, and mobile messengers like WeChat or WhatsApp. But our trouble was that each channel had to be managed individually, so it gave us a lot of operational burden.

So we changed it so that all campaign channels are consolidated with Amazon SNS using ABAP SDK. No matter what type of campaign channel it is, the CRM App is able to send out campaign activity with the same logic to Amazon SNS. This enabled the marketing organization to drive marketing execution without unnecessary operational burden.

This slide summarizes the modernization journey we explained today. For traffic control and data protection, Amazon API Gateway and Amazon SQS were leveraged. And for read distribution and system stability, multi-target and read enablement database features were used. Also by launching ABAP SDK, we could leverage diverse AWS services like AWS Lambda, Amazon SNS, SQS, S3 on top of CRM.

On top of this modernization effort, we implemented ZIA to prevent data attacks, and Splunk + SignalFX for comprehensive monitoring with Amazon CloudWatch.

This is our last slide, explaining the results of our innovation. I'm afraid I can't share specific numbers here, but we could increase transactions per second by over 300%. This is huge improvement, and we could improve system reliability by implementing traffic control features. Also we could save total cost of ownership significantly.

Another indirect benefit is we could prevent the risk of data loss as protected data is a great asset for Samsung Electronics to modernize their marketing execution. We like this innovation path we took with AWS, and we can say for sure our innovation will be continued.

Ok thank you for listening to our innovation journey, and now let me invite Sargent Kim again.

Sargent Kim: Thank you gentlemen. I hope you enjoyed our session. Before we start the Q&A session, I want to give you another good piece of information. For your next steps to start your SAP modernization journey, I recommend you reserve your 1:1 session. You can get to it by scanning this QR code, and when you leave your interest at that page, after that we will reach out to you. There are various AWS for SAP sessions we have prepared this spring, so I hope after this session you are continuously interested in our SAP sessions.

If anyone else needs to take a picture, I'll give it another couple seconds.

Lastly, I would like to ask you one very important favor. AWS is a data driven company. As such, your opinions matter greatly to help implement improvements. So please take a moment to fill out a short session survey in your mobile app so that we can continue to deliver the content that you need to be successful.

Our workshop session is now complete. I really appreciate your time, and now we will open up the floor for any questions or answers. Thank you.