tl;dr
As part of S/4HANA Transformation Programs, Security, Accessibility, Resilience are being re-imagined.
The going in position for a lot of S/4HANA Transformation Programs includes the Cyber Security principles:
- Only Employees will have direct access to the Digital Core as End Users
- There will be no direct access to the Digital Core by 3rd Party Applications
The first principle, 'Only Employees will have direct access to the Digital Core as Users', decoupling the SAP system for External Users has been an architectural design pattern for more than a decade. For example, due to the extremely sensitive and confidential nature of Product LifeCycle Management Data, 13 years ago SAP were advocating, building an empty SAP PLM system in the DMZ which would use RFC's to communicate with the actual SAP PLM system in the Secure Network Zone:
The beauty of this design is that it decouples End User Access from the core SAP PLM system, therefore enhancing the security protection of the SAP PLM system.
Today's equivalent of that is to put the SAP Build Work Zone Launchpad in front of the S/4HANA Digital Core.
That is fine, that means the Digital Core is digitally decoupled for End Users, but what about Machine to Machine, Application to Application, 3rd Party Applications which want to get Data from the S/4HANA ?
When a 3rd Party Company calls an API on your S/4HANA Digital Core, you are replicating your Data to that 3rd Party Company.
How can the S/4HANA Digital Core be decoupled when 3rd Party Applications need to get Data from the S/4HANA, how can the S/4HANA Digital Core be architected in such a way that there are no Machine to Machine calls directly to the S/4HANA for the purpose of getting Data ?
As elaborated in more detail in a previous blog, API's enable your Data to be replicated to 3rd Party Applications which can also be in 3rd Party Partner Companies, and this brings a set of problems centered around:
Trust between Partners: The more Partners in a Business Transaction or Business Process, the less trust there is between Partners. This is a very simple graph, as the number of Partners in a Business Transaction or Business Process goes up, so the trust between the Partners goes down. What is trust in a Business Transaction or Business Process, doing what you said you would, data, instruction, confirmation. I will deliver the parcel to the address you gave me, but what if somebody in my Team changes the delivery address for their own benefit ?
Protect the Originality & Integrity of the Data - When your S/4HANA sends the Data to your Business Partner's System we need to make sure that the Data cannot be modified or destroyed and therefore protect the originality and integrity of the Data
Replicating & Integrating the Data from your S/4HANA to your Business Partner's System and at the same time Protect the Originality & Integrity of the Data - we need to get the Data from the S/4HANA to the Business Partner's System and we need to be sure, to have surety that the Data which arrives at the Business Partner's System is the same Data as was sent from your S/4HANA. If this Data can be changed in any way, we won't be able to trust the Business Processes and Insights which are depending on that Data. And so, in the activity of moving the Data we need to make sure that that piece of Data cannot be modified or destroyed and therefore protect the originality and integrity of the Data
and it doesn't end there, it's often the case that a 3rd Party Organisation will be getting Data directly from your S/4HANA (as the Source) or posting Data to your S/4HANA (as the Target), in both cases it could be an API which through your Integration Technologies is ultimately exposed to the Internet and where the system calling the API needs to have a User on your S/4HANA.
As ever, the pattern is the same, the theme is the same,
it's all about the Data
what are the security, sensitivity, confidentiality, availability, criticality requirements of the Data
Ring Fencing S/4HANA raises the Cyber Security by reducing the attack surface.
The most secure way is with Enterprise Blockchain as a Data Ring Fence around the S/4HANA Digital Core, therefore digitally decoupling access and integration of the S/4HANA Data from other Applications.
The Enterprise Blockchain is:
. Ring Fencing of the S/4HANA
. S/4HANA does not expose API's directly to any 3rd Party Companies
. A Secure Store of Data
. A Secure Communication Channel for Data
. A Common Shared Single Source of Truth in your Organisation and across Organisations
. The next generation Data Integration is about having a Common Shared Single Source of Truth
The S/4HANA Ring Fencing with Enterprise Blockchain as a shared single source of truth could involve the Enterprise Blockchain running on your SAP BTP Kyma Runtime and at the same time running on Kubernetes Servers in your Business Partner's Data Center:
Or alternatively the S/4HANA Ring Fencing with Enterprise Blockchain could be where the Enterprise Blockchain is running on your SAP BTP Kyma Runtime and your 3rd Party Business Partner Company reads the Data from your Enterprise Blockchain on your SAP BTP Kyma Runtime as a shared common single source of truth for the Data:
Read on for the full story... π
Introduction
The reason I am so interested in this is I have been securing availability and accessibility of SAP systems for the last 25 years, and back in 2013 I wrote this blog about "Alternatives for Securing Internet Facing Applications".
There is so much to talk about on this subject, let's get in to it. Back in 2013 at a Customer, we were looking at Ring Fencing critical systems.
Back then the focus was on DeCoupling the SAP system where End User access was required from people coming in from the Internet, infact the reasons for the RingFencing were centered around:
- Access - Authentication & Authorisation
- Storage of Data
- Communication Channels
- DeCoupling especially for Internet Collaboration
The DeCoupling for Internet Collaboration was based around SAP's SAP PLM Reference Architecture,
and the SAP PLM Technical System Landscape recommendation:
Fast forward to today, and SAP Customers have the luxury that the worry of securing End User Internet Access to their SAP systems is outsourced to SAP through the implementation of the SAP BTP Build Work Zone Launchpad. It should not go unnoticed that when you implement the SAP BTP Build Work Zone Launchpad Service, you also don't have to care for Web Access Firewalls and the Security of Internet Access.
But what about API's, what about System to System, Machine to Machine ? What about Integrations ? What about when Non-SAP Applications in your Company or other Companies need data from the S/4HANA ?
S/4HANA has a rich collection of API's which is always growing, but, should Applications from your Partner Companies call API end points on the S/4HANA Digital Core ?
Should 3rd Party Applications, and 3rd Party Partner's Applications be directly accessing the Digital Core S/4HANA API's ?
Regardless of whether the S/4HANA is an [Any]OnPremise, S/4HANA RISE Private Cloud Edition, S/4HANA Public Cloud Edition, should 3rd Party Applications be allowed to directly call API's on your S/4HANA ?
Let's take the S/4HANA Business Partner API, should Applications from your Partner Companies be allowed/able to call this API on your Digital Core S/4HANA to retrieve changes to Business Partner Data ?
If you have doubts or think the answer is no, then read on, there is a solution, it is very nice, and very easy, and very secure.
One of the biggest Cyber Security threats to your Data and therefore your Operations and therefore your Business, is allowing 3rd Party Applications from 3rd Party Companies to call Data from API's on your S/4HANA Digital Core, and then, replicate your Data to Servers in their Company.
As ever, the pattern is the same, the theme is the same,
it's all about the Data
what are the security, sensitivity, confidentiality, availability, criticality requirements of the Data
Like the other blogs in this series, this blog is going to break the subject down in to three sections:
Section 1.0: The What is it of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain
Section 2.0: The Why is it, of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain
Section 3.0: The How is it, of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain
In case you missed them, the previous blogs in this series are here:
Why I love SAP and Blockchain Databases and why you should too π
SAP Enterprise Architecture: Let the Use Case find the Blockchain π
Oil & Gas - Ultimate Data Security - Blockchain Data Backbone from OT to SAP IT π
The What Is... The Why To... The How To... of: ESG & SAP & Enterprise Blockchain π
BCP: Business Continuity Planning for SAP S/4HANA - made easy with Enterprise Blockchain π
Trustable AI thanks to - SAP AI Core & SAP HANA Cloud & SAP S/4HANA & Enterprise Blockchain π
IoT - Ultimate Data Cyber Security - with Enterprise Blockchain and SAP BTP π
B2B Business Processes - Ultimate Cyber Data Security - with Blockchain and SAP BTP π
Section 1.0: The What is it of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain
What is RingFencing ? There is a very nice description here:
RingFencing is about isolating Data, away from the most important SAP system, the S/4HANA Digital Core.
DeCoupling, the word DeCoupling has a number of meanings in Enterprise IT. What we are talking about here in the case of the S/4HANA Digital Core and Data access by 3rd Party Company Applications is that we are DeCoupling the Data access away from directly on the S/4HANA, by DeCoupling we are making the S/4HANA Data indirectly accessible.
It can be thought that if we are RingFencing, or Isolating, or DeCoupling the S/4HANA Data away from the S/4HANA then we are creating another copy of the Data, another Replica of the Data, which is true, we are, and that is the same as when Data is replicated to 3rd Party Systems via API, whichever way you look at it, the ultimate goal is a Replica of the S/4HANA Data which is available and accessible to the 3rd Party Company Application for the reasons of that Application of Business Transaction.
We can replicate the Data using an S/4HANA API to the 3rd Party Company Application and lose all control of the Data and also have to deal with how to secure Authentication and Authorisation and Network Access to the API, or we can replicate to our own RingFenced isolated trusted location.
What about the Enterprise Blockchain, what is Enterprise Blockchain ?
Enterprise Blockchain is:
. a Secure Store
. a Secure Communication Channel
. A Common Shared Single Source of Truth in your Organisation and across Organisations
. The next generation Data Integration is about having a Common Shared Single Source of Truth
McKinsey & Company, in their December 2023 Featured Insights Publication, gave a beautiful description of what is unique and special about Blockchain, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time". If we just pause for a moment and let that sink in, and think about what that means, to Business Processes, to Collaboration, to System Resilience, we start to see what is so special about Blockchain Databases and Distributed Ledger Technology.
In these previous blogs, I made a deep dive in to what Enterprise Blockchain is and why we should be positioning it in our Enterprise Architecture:
Why I love SAP and Blockchain Databases and why you should too π
SAP Enterprise Architecture: Let the Use Case find the Blockchain π
and in a nutshell, Enterprise Blockchain is:
. The Digital Transformation of Information Security into Cyber Security
. The Next Generation Data Integrity, Originality, Confidentiality Protection
. Re-imagining Information Security
. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product
To wrap up this section:
. RingFencing is about isolating and protecting Data
. Enterprise Blockchain is about Cyber Security of Data
Section 2.0: The Why is it, of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain
Why would we want to RingFence and DeCouple S/4HANA, the Digital Core from 3rd Party systems which legitimately need S/4HANA Data ?
The answer is simple, Cyber Security, Cyber Threats.
Not so long ago, the focus was on High Availability and Disaster Recovery, the biggest threat was the system going down and not coming back.
Today, things have changed, and the biggest threat is a malicious actor rendering our business Data unusable.
Today we know we can buy new servers, we know we can get a Data Center up and running, but how do we repair Data which has been maliciously rendered unusable ? Think about the Ransomware attack.
So what is ring fencing and why do we need to do it ?
Ring Fencing is about reducing exposure to Cyber Threats.
What are the biggest easiest ways that we can reduce exposure to Cyber Threat ?
Stop 3rd Party Companies from calling API's on the S/4HANA Digital Core.
Stop publishing API's for 3rd Party Application access on the S/4HANA Digital Core.
Stop doing this:
And what's the solution ?
The solution is the Enterprise Blockchain as the Common Data Back Bone across Companies.
Instead of replicating and sending the Data to your Business Partner, you write the S/4HANA Data to the Enterprise Blockchain.
This is like pick your own strawberries, instead of sending your Partners the strawberries, you tell your Partner the strawberries are ready and which field they are in and you let your Partners pick the strawberries themselves from the Enterprise Blockchain.
S/4HANA Data Events write the Data to the Enterprise Blockchain and S/4HANA Notification Events notify the Partner that something has happened, then, instead of calling an API on your SAP S/4HANA, the Partner then calls the API of the Enterprise Blockchain and Reads the Data from there.
The Enterprise Blockchain Database software is running on your SAP BTP Kyma Runtime and in your Partner's Servers, therefore, creating natively, out of the box, the most secure and resilient common shared single source of truth. Your have a Distributed Ledger running from your SAP BTP to the Partner's Servers.
Therefore, S/4HANA Data Event Writes to the Enterprise Blockchain as the Common Shared Single Source of Truth across the Organisations, and the S/4HANA Notification Event notifies the Partner that something has happened and that they should call the Enterprise Blockchain API to get the Data of what has happened.
And as will be explained later in the blog, it's not only about the Enterprise Blockchain being a common shared source of truth across organisations, it's about digitally decoupling the S/4HANA from 3rd Party System Integrations and gradually ring fencing the S/4HANA away from being directly accessed by 3rd Party Systems as it is today with API's.
Imagine, as described in the previous blog, when we let the Use Case find the Enterprise Blockchain, we have a Business Requirement, a Business Demand, to make Data for B2B Business Process the safest it can be, the most trustable that it can be.
When we look in our Enterprise Technology Standards, and we look for the Technology Standard in our Enterprise Portfolio which is positioned to bring the strongest protection to Data, we find the Enterprise Blockchain.
In the previous blogs, we have discussed in detail about the special characteristics of Enterprise Blockchain and just why it natively out of the box protects the integrity of data to a level that legacy database products cannot do, in a nutshell....
B2B Business Processes are about Data
B2B Business Processes are about the Data that goes from your S/4HANA outside the boundaries of your Company and your Network and to Partner Company's Applications and Networks and Databases.
This means B2B Business Processes are about Data and the Data depends on a Database or a Datastore
What kind of Database do B2B Business Processes Data need ? What capabilities does the Database for the B2B Business Processes Data need to have ?
1. It must not be possible to modify the Data in the Database ]- the Database needs to be immutable
2. The Data in the Database, the integrity and originality of that Data must be protected to the highest level that is technically possible
3. The Data must be available with the highest availability, the Database must be resilient to attack
4. The Database must be running simutaneously in your DataCenter and your Business Partner's DataCenter
5. S/4HANA must not expose any API's to Business Partner Companies
When we look in our Enterprise Technology Standards we find 1 Technology Standard in the Enterprise which has those capabilities, and that is..... Enterprise Blockchain
Enterprise Blockchain ticks those boxes...
Immutable - tick that box
Integrity must be protected to the highest level - tick that box, thanks to the Enterprise Blockchain Hash Mechanism and the Enterprise Blockchain Consensus Mechanism
Highest level of resilience and availability - tick that box thanks to the Distributed and Decentralised nature of the Enterprise Blockchain DeCouples S/4HANA from the process, no need to S/4HANA API's to be exposed to 3rd Party Business Partner's Applications
This is why, Enterprise Blockchain is the enabler of trustable outcomes from Enterprise B2B Business Processes.
But there's more than that, B2B Business Processes can produce a lot of data, and the volumes of data can be big.
And this is why, in this blog we take the Enterprise Blockchain Technology story one level further and we introduce the:
Enterprise Blockchain Wallet
Off-Chain Data Storage
In the Enterprise Blockchain Platforms, the Enterprise Blockchain Wallet is used for Off-Chain storage of big data and in the following paragraphs we will explain why.
What is the Enterprise Blockchain Wallet, and what is Off-Chain Data Storage and why would we use them and why do we need them ?
As we have explained in a previous blog, the Enterprise Blockchain Database, the Distributed Ledger, can be looked at simply as a Database Table (which is replicated and synchronised across multiple Servers) and in principle it stores the Data like this:
This is fine, and suited to what we call Structured Data, and as AWS nicely describe, Structured Data is information like words and numbers. This kind of data is perfectly suited to being stored in an Enterprise Blockchain Database and also a legacy Database. Examples of the data would Names, Addresses, Phone Numbers, Product Information etc.
But, Payroll can produce a lot of Data, and in large volumes which would be too big to be stored on the Enterprise Blockchain Database itself.
And that's ok, Enterprise Blockchain Platforms are ready for that, and have been designed to store both Structured Data and Data which is in files which are so big that they cannot be stored in the Enterprise Blockchain Database itself, for example the photographs from a Waste Truck's onboard camera proving that waste was responsibly tipped in the correct location and taken at the same time as recording GPS location coordinates proving the location of the Waste Truck.
So, if we can't store the large photographs files in large quantities to the Enterprise Blockchain Database, then how, in an Enterprise Blockchain Platform do we store large files of Data ?
Voila.... bring in the Enterprise Blockchain Platform Wallet. The best Enterprise Blockchain Platform products include what is called the Enterprise Blockchain Platform Wallet, or to make it shorter, the Enterprise Blockchain Wallet.
The Enterprise Blockchain Wallet enables us to store large Data, like large Files safely and securely off the chain, or 'Off-Chain'.
But if we store the large Data files Off-Chain in the Enterprise Blockchain Wallet, then how do we also have them some how on the Enterprise Blockchain Database ?
The way this works is elegant, in any decent Enterprise Blockchain Platform, the Enterprise Blockchain Wallet location is completely configurable, and could be anywhere from SAP HANA Cloud (Data Lake), or for example multiple hyperscaler object stores, such as Amazon S3, OSS (Alicloud Object Storage
Service), SAP HANA Cloud, Data Lake, and Azure Blob Storage.
The configurable Enterprise Blockchain Wallet of the Enterprise Blockchain Platform looks like this:
Ok, so we've got the large volumes of Data stored in the (configurable) Enterprise Blockchain Wallet, but what about securing the Data ? Obviously the Enterprise Blockchain Wallet storage location has built in security, for example the SAP HANA Cloud, the AWS S3 Buckets, but we need more than the out of the box security of these products, the reason we are using the Enterprise Blockchain Database is because of the amazing security strengths that it natively out of the box has, and so, what about the Enterprise Blockchain Wallet, doesn't the Enterprise Blockchain Platform have some cool super hard way of protecting the data in the Enterprise Blockchain Wallet ?
Well yes it does, this is the magic of Enterprise Blockchain Database 'Off-Chain' storage in the Enterprise Blockchain Wallet. This is so unique to Blockchain Technologies.
What happens is this, when store data in the Enterprise Blockchain Wallet, the Enterprise Blockchain Platform software runs a hash algorithm over the data that we have stored and the data, and the large file gets hashed:
The data or the file in the Enterprise Blockchain Wallet gets hashed, and then, that hash is stored in the Enterprise Blockchain Database.
This means we now have a unique hash of that data or file, and if anybody or anything makes even the tiniest teeniest change to that data or file, next time we run a hash over that data or file the result will be different that the original hash which is safely stored in the Enterprise Blockchain Database and this is how we will know that the data has been changed and we cannot trust the Data and therefore we cannot use it for our Enterprise Business Processes.
On the other hand, if just before we load the data in to the SAP Enterprise Applications, eg SAP Asset Performance Management and SAP S/4HANA, from the Enterprise Blockchain Wallet, if we run a hash over the data and the hash result is the same as we have in the Enterprise Blockchain Database, then we will know we can trust the Data and we can use it in our SAP Applications and we will have trustable Data.
And this is why, for all of these reasons,
Ring Fencing S/4HANA Digital Core depends on Data being stored in the Enterprise Blockchain
But that's not the end of the Ring Fencing need Enterprise Blockchain.
As we showed at the beginning of the blog in this picture:
As the picture shows, we have an Enterprise Blockchain Database Tenant installed on a Server Host at the in your DataCenter, in your Network on your SAP BTP Kyma Service AND we have an Enterprise Blockchain Database Tenant installed on your B2B Business Partner's Network, if they are a SAP Customer then like you they can put it on the SAP BTP Kyma Service, if not they can run it on Kubernetes.
The consequence of this is that we have a distributed Enterprise Blockchain Database table which stretches from your DataCenter and Network where your S/4HANA is writing Data to it and stretches all the way across the Network to your Business Partner's DataCenter.
This means we have Ring Fenced S/4HANA with Enterprise Blockchain Data Protection from the source from your S/4HANA to the target your B2B Business Partner's It infrastructure enabling the trusted resilient reliable Business Processes to be completed.
At the same time, we are not exposing S/4HANA or the API's on the S/4HANA to any 3rd Party Applications.
We have Ring Fenced and digitally decoupled the S/4HANA Data and Access from the Business Process.
And this is why we say, Enterprise Blockchain is a Secure Communication Channel, because instead of integrating Applications sending and replicating Data across Networks, we are sharing the Data across the Enterprise Blockchain and the Enterprise Blockchain is the Secure Communication Channel.
To conclude this section, the Why to, B2B Ring Fencing S/4HANA and Enterprise Blockchain, B2B Business Process Data needs to safely replicated and trustable.
Enterprise Blockchain, due to its native super strong security strength when used as a store of Data enables B2B Business Processes to be both Secure, and Trustable.
And as we will see in the next section, it's not only about the Enterprise Blockchain being a common shared source of truth across Organisations, it's about Ring Fencing and digitally decoupling the S/4HANA and removing the attack surface from 3rd Party System Integrations and gradually ring fencing the S/4HANA away from being directly accessed by 3rd Party Systems as it is today with API's.
Section 3.0: The How is it, of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain
The goal of this blog was to show how instead of using the legacy fire and forget approach of replicating data to 3rd Party Business Partners, the Enterprise Blockchain can be deployed as a common shared single source of truth running, with an Enterprise Blockchain Tenant running close to your S/4HANA and another Enterprise Blockchain Tenant running close to your Business Partner's Application. Thus Ring Fencing and Digitally DeCoupling S/4HANA Digital Core and bringing the highest level of Cyber Security and attacked surface reduction.
In this section of the blog we will show all of the possible potential Technical Solution Architectures which will enable you to implement this next generation approach to sharing Data with the highest level of Cyber Security already today.
As described above one of the many beauties of this approach is your S/4HANA writes to the Enterprise Blockchain and your Business Partner's Application reads from the same Enterprise Blockchain. This achieves a number of things including:
. Total Control - you have total control over the Data you are sharing with the Business Partner, and you know that as long as your Business Partner's Application reads the Data from the common shared source, the Enterprise Blockchain
. Ultimate Cyber Security - then you know the maximum has been done to minimise the S/4HANA attack surface and the chance for Cyber Security risks and the maximum has been done to protect originality, integrity, and confidentiality of the Data
. S/4HANA Ring Fenced and Digitally DeCoupled from the Business Process - and on top of this, the S/4HANA has been digitally disconnected from the Business Process, because no longer do any 3rd Party Applications directly call API's on the S/4HANA
In the Technical Solution Archecture there would be two main ways for getting the data from the S/4HANA and writing it to the Enterprise Blockchain, these would be:
. API's
. Events
In these Technical Solution Architecture examples we will prioritise using S/4HANA Events to write the Data to the Enterprise Blockchain, we will be sending the Event Notification and the Event Payload, we could of course draw the same Technical Solution Architecture with API's, but we prefer the Events for the simplicity and reduced call backs to the S/4HANA and therefore making the S/4HANA more Ring Fenced and Digitally DeCoupled and therefore, enabling the S/4HANA to be protected to the higher security level and exposed to less Cyber Security risk.
S/4HANA Data Events write the Data to the Enterprise Blockchain and S/4HANA Notification Events notify the Partner that something has happened, then, instead of calling an API on your SAP S/4HANA, the Partner then calls the API of the Enterprise Blockchain and Reads the Data from there.
The Enterprise Blockchain Database software is running on your SAP BTP Kyma Runtime and in your Partner's Servers, therefore, creating natively, out of the box, the most secure and resilient common shared single source of truth. Your have a Distributed Ledger running from your SAP BTP to the Partner's Servers.
Ok, let's go with the Technical Solution Architectures, in these examples we will focus on the OutSourced Payroll as the integration and B2B Business Process Example.
What do we have and what do we need:
Your Company will need:
. S/4HANA
. SAP EM and preferably SAP AEM since it has richer Security and Event Payload size capabilities and can Publish Events from Non-SAP Enterprise Applications and connect to your Enterprise Event Mesh
. SAP BTP
. SAP BTP Kyma Runtime Service - this is where the Enterprise Blockchain Container will run
. Enterprise Blockchain Platform Software which can run on Kubernetes
. If there will be larger Data objects then you will need Large Storage for Large Data and the Enterprise Blockchain Wallet in the form of SAP HANA Cloud (Data Lake)
Your Business Partner will need:
. Obviously their Payroll Application
. Either SAP BTP with Kyma Runtime, or Servers which can run Kubernetes Containers
. n.b. there is an Optional Technical Solution Architecture where you simply allow your Business Partner to read data from your Enterprise Blockchain where the Enterprise Blockchain Platform is running exclusively on your BTP, we will show that Option as well
Technical Reference Solution Architecture for SAP S/4HANA and SAP SuccessFactors and OutSourced 3rd Party Payroll Provider using Enterprise Blockchain as a Common Shared Single Source of Truth for Data and the Ultimate Cyber Data Security for B2B Business Processes...
In the next example, we have the same basic Technical Solution Architecture as the previous example, except, this Reference Use Case is ready for the Enterprise Blockchain needed to be able to handle large volumes of data and brings the Enterprise Wallet in to the picture. In the Enterprise Blockchain Platform the Enterprise Wallet storage is configurable and therefore could be SAP HANA Cloud (DataLake) or AWS S3 Buckets or other HyperScaler Data stores.
All of the other Cyber Security characteristics remain the same, S/4 is ring fenced and digitally decoupled from the Business Partner, Enterprise Blockchain is used as a common shared single source of truth for Master and Transactional Data, and the Enterprise Blockchain Tenants are running in both your DataCenter (AnyPremise) and the Business Partner's DataCenter (AnyPremise):
The next example Reference Technical Solution Architecture is a little bit different, let's assume, for their own reasons, your Business Partner is not going to run an Enterprise Blockchain Tenant in their (AnyPremise) DataCenter.
This is still fine, you will set up the Enterprise Blockchain Platform in your DataCenter(s) (AnyPremise) and your B2B Business Partner, in this case the outsourced 3rd Party Payroll Vendor will simply use API's to read and write to and from your Enterprise Blockchain.
All of the other benefits of the design remain the same, all of the other next generation Data sharing Cyber Security characteristics are still there, S/4 is ring fenced and digitally decoupled from the Business Partner, Enterprise Blockchain is used as a common shared single source of truth for Master and Transactional Data.
Here it is:
Finally, we have the same Reference Technical Architecture as above, but to be able to cater for large volumes of Data we include the Enterprise Wallet in the design.
Ok let's wrap this up, the conclusions:
Ring Fencing the S/4HANA Digital Core substantially raises the Cyber Security and reduces the attack surface for 3rd Party Attackers, Ultimate Cyber Security for Ring Fencing S/4HANA is the Enterprise Blockchain, where the Enterprise Blockchain acts a common shared single source of truth for Data across Organisations
Enterprise Blockchain is:
. Ring Fencing and Digitally DeCoupling the S/4HANA Digital Core
. A Secure Store of Data
. A Secure Communication Channel for Data
. A Common Shared Single Source of Truth in your Organisation and across Organisations
. The next generation Data Integration is about having a Common Shared Single Source of Truth
The next generation Integrations don't allow direct access to API's published in the S/4HANA and replicate Data, that's legacy, the next generation Integrations use Enterprise Blockchain as a common shared single source of truth.
The configurable Enterprise Blockchain Wallet enables you to store Big Data 'Off-Chain' and the hashes of the Data are stored safely and securely on the Enterprise Blockchain Database.
The good news is, as we discussed in the previous blog, this is no longer hype, we can do all of this today, and now, within the SAP Partner Edge Open EcoSystem there are enabling technology Blockchain Products designed and built by SAP Experts specifically for the needs of SAP Customers to make doing Blockchain and SAP easy, and so you can do SAP and Blockchain, today it's real and there's nothing stopping you.
So what are we waiting for ? Oh yeah, deep dive in to more use cases, ok, that will be the next blog.
What do you think, are the words Blockchain, Web3, Distributed Ledger Technology, starting to appear in your Company's visions and technology visions ? What use cases are you looking at ? Let's chat about it in the comments.
For now, over and out.
Andy Silvey.
Independent SAP Technical Architect and CEO of atkrypto.io
Author Bio:
Andy Silvey is a 25 years SAP Technology veteran [15 years SAP Basis and 10 years SAP Tech Arch including Tech, Integration, Security, Data from 3.1H to S/4HANA PCE on RISE and the BTP and everything in between, and former SCN Moderator and Mentor alumni].
Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.
atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.
The atkrypto Enterprise Blockchain Platform for SAP has been designed by SAP Independent Experts for the needs of SAP Customers and to be deployed on the SAP BTP Kyma Runtime Service and leverage native integration to SAP Products.
atkrypto Enterprise Blockchain Platform for SAP has a number of unique qualities, including being the only Blockchain software in the world which has a DataCenter version and a light mobile version which can run on Edge/IoT/Mobile devices and enables data to be written to the Blockchain at the Edge where that same Blockchain is running on a Server in the DataCenter, protecting the integrity and originality of data from the Edge to Insights. Taking Blockchain to the Data at the Edge instead of taking the Data to the Blockchain.
All of this makes atkrypto,io the DePIN Decentralised Physical Infrastructure Network solution for Enterprise.
atkrypto is one of the Next20 startups being featured at TM Forum's DTW Ignite in Copenhagen in June
If you will be at DTW24 come and talk to us about Cyber Security of SAP Data with Enterprise Blockchain.
- SAP Managed Tags:
