Welcome to the 3rd blog in this series, this blog, continuing the journey which we have started with the previous two blogs, is going to bring the most important message and subject that we have discussed so far.
Let the Use Case find the Blockchain, instead of the Blockchain finding the Use Case
Before we get started, let's just recap on what we have been looking at so far.
The 1st blog jumped straight in with the clear message that we need to start looking at Blockchain as an Enterprise Technology, and the reason why. What are the reasons ? Basically, in a nustshell,
Blockchain is both a Secure Store and Secure Communication Channel
and what is so exciting about Blockchain is that out of the box, natively, it is the most resilient Secure Store and Secure Communication Channel due to the special characteristics of Blockchain, Immutable, Hash Mechanism, Distributed, Consensus Mechanism.
The 2nd blog in the series looked at Blockchain Databases and Enterprise Blockchain Platforms and discussed how to position the two as Te... in SAP Enterprise Architecture based upon the Level 1, Level 2, Level 3 Capabilities (including the Blockchain Capability Map).
So why are we doing this blog ? Why are we going to discuss, "Let the Use Case find the Blockchain, instead of the Blockchain finding the Use Case ?"
That should be obvious shouldn't it ? Yes it should, but the mistake a lot of us have been making over the recent years is to sit there scratching our heads trying to think of where we can use Blockchain in the Enterprise, that old Enterprise Architecture mistake of, Blockchain trying to Use Cases.
And this is all wrong, this is upside down. As Enterprise SAP Architects, we have a proven process for applying Technology Standards in the Enterprise, and that process revolves around understanding the idea or problem which needs solving, and then breaking that problem down until we get to the point where we can identify what Enabling Capabilities are required and therefore which of our Technology Standards are applicable and the most ideal for solving that idea or problem.
This should all be obvious to most people, but even myself included, going back to 2018, I remember being in a meeting and challenged to find a Use Case for Blockchain. Back then we didn't even properly understand what Blockchain is and we were sucked in to the hype of just trying to apply it to something, to a Use Case.
Fast forward 6 years, we now know what Blockchain Databases are, we know what Enterprise Blockchain Platforms are, we know their extraordinary security and resilience capabilities and how to position them as a Technology Standard, and now, we can follow the process and Let the Use Case find the Blockchain, instead of the Blockchain finding the Use Case.
In this blog we are going to walk through the Demand Process for a theoretical Demand, we will walk through all of the steps, and applying the Enterprise Architecture methods we will show how, by having established Blockchain Databases and Enterprise Blockchain Platform as Technology Standards, the idea and the problem aka the Use Case, will find the Blockchain.
The idea, the problem, which we will walk through, is Business Continuity Planning. In our theoretical scenario our Business have come to us with a Business Continuity Planning idea and problem for us to solve.
The idea, the problem, is, The Business want to be prepared for a Business Continuity Scenario, where the Company will be running in Emergency Mode, kind of like when a car goes in to Emergency Mode, the car drives, but the car does not perform to the full possibility. We are happy the car is running and we are happy that we can still use the car.
And this would be the same for Company in a Business Continuity Scenario, not everything in the Enterprise IT will be available, but, what needs to be available is the most basic foundational Business Master and Transactional Data. And that most basic foundational Business Master Data is the Business Partner Master Data, the Customers and Suppliers, the most basic Data which any Company depends on to operate, large or small, you need to know who your Customers are and who your Suppliers are.
[DISCLAIMER] Please note, this is a blog, the point is the blog is to walk through the Enterprise Architecture process for handling a Demand and following the process identify the most appropriate Technology Standard. The scenario we will use here is Business Continuity Planning, and to be clear, this blog is not a comprehensive solution to Business Continuity Planning, this is a very big subject and at the same time specific to every Company and we will focus here on one of the many pieces of a holistic Business Continuity Plan, but we are not solving the holistic Enterprise Business Continuity Planning here]
Ok, that said, let's get back to the blog and follow the Enterprise Architecture process and let the Use Case find the Blockchain.
The actual idea, demand, requirement from our Business is as follows, in the past, Business Continuity threats were considered to include, War, Acts of Nature, and others. Today Business Continuity is at risk from professional organised Cyber Attacks, Malware, Ransonware. As part of a strategic Business Continuity Planning Project, a solution is required to enable OCD Operationally Critical Data to be available to Key Users in the event of a Business Continuity Scenario.
What is Operational Critical Data? OCD is critical data required to execute to Key Business Processes as defined in BCP playbook. A Business Continuity Scenario would mean that the Company is without access to the S/4HANA for period of up to 4 weeks (or more), along with which there must be a guarantee of business continuity on the most critical operations and availability of the (OCD).
To sustain critical operations during a complete and prolonged IT outage, workarounds for key business processes have been identified and will be activated immediately after the incident has occurred.
SAP S/4HANA Master data should be available, Customer and Supplier. Subsequently Transactional Data such as Sales Order, Delivery, Invoices, Purchase, etc will be required. The Business Users require access to the OCD solution in order to ensure resumption and continuation of Business Operations.
The Demand, from the Business Lead is as follows:
Blockchain SAP Business Continuity Planning Requirements atkrypto.ioThe next step in the SAP Enterprise Architect Demand Process is to make an Architecture Review of the Demand from the Business Lead.
The first step of the Architecture Review takes the Business Lead's non-Functional requirements, and matches them to the Enabling Technology Capabilities:
Blockchain SAP Business Continuity Planning Requirements Technology Capabilities Analysis atkrypto.ioNow that we have the key Enabling Technology Capabilities we can look in our SAP Enterprise Technology Standards and see which of our Technology Standards would be the most appropriate to enable the non-Functional Requirements.
The required Enabling Technology Capabilities are as follows:
SAP Blockchain Required Enabling Technology Capabilities atkrypto.ioLooking through our Technology Standards we find 1 Technology Standard which meets the non-Functional Enabling Technology requirements, and that is, The Enterprise Blockchain Platform.
The Enterprise Blockchain Platform and the Enterprise Blockchain Database have all of these non-Functional requirements Enabling Technology Capabilities natively built in and out of the box.
We can consider potential alternatives, but, what is so special about Blockchain Databases and Enterprise Blockchain Platforms, and this was discussed in the previous blogs, is that, out of the box, natively, traditional Database Products do not have the characteristics that the Blockchain Databases have:
atkrypto.io what is a blockchainFor our Business Continuity Business Demand, the requirements are solved out of the box natively by the Enterprise Blockchain Platform.
Immutable, tick that box, the Blockchain Database has immutability built in.
Resilience and availability, tick that box, the Blockchain Database Platform is distributed and decentralised, again we have this requirement baked in to the capabilities of the platform.
Availability of data across three Continents, we can tick that box, we can install the Enterprise Blockchain Platform on SAP Business Technology Platform BTP Kyma Runtime Service on three separate SAP BTP Instances running in three different continents. We could install the SAP BTP on a Cloud Provider in the USA, we could install SAP BTP on a Cloud Provider in Europe, and we could install the SAP BTP on a Cloud Provider in Asia. And what's more, in each Continent we could use a different Cloud Provider, so we could for example have SAP BTP on AWS in the USA, SAP BTP on Azure in Europe, and SAP BTP on Google Cloud in Asia, this way we would take the resilience and diversification of Cloud Providers to an even higher level, and that's one of the beautiful flexibilities of the SAP BTP.
Let's just pause on that one, one of the most beautiful things about the SAP BTP is, it is so easy to set up, to spin up the SAP BTP, and when you are spinning up the SAP BTP, you get a list of Cloud Providers that you can set it up on, Google Cloud, Azure, AWS and others, and you just click the one you want and press go.
This is something very special, amazing, because, you are able to spin up your SAP BTP on pretty much any of the largest Cloud Providers, and...... without having to onboard that Cloud Provider as a Vendor ! Because SAP have done that bit for you, SAP have taken care of onboarding the Cloud Providers as a Vendor and you just select the one you want.
Anybody who has gone through, or has to go through, the process in the Large Enterprise of onboarding a new Vendor will know first hand how painful that is, and how elegant and nice it is that SAP have done that for you with the BTP.
That's one dimension, but in this Business Continuity Scenario it goes further than that. We have said we will spin up the SAP BTP in three Regions, three Continents, and by spinning up the SAP BTP on a different Cloud Provider in each Continent, each Region, and then running the Blockchain on the BTP across those Cloud Providers we build in even more resilience because we make our solution Multi-Cloud !
Regarding the Security requirement, the Data Store should be secured to the highest level possible, we can tick that box as well, Blockchain Databases out of the box are not only immutable, but also have the Hash Mechanism and the Consensus Mechanism, which no other Database Products on the planet have natively. The Consensus Mechanism and the Hash Mechanism of Blockchain Databases raises the bar of built in security hardening to a level never seen before natively in Enterprise Database Products.
And finally, the S/4HANA Data will be sent to the Enterprise Blockchain Platform which is running on SAP Business Technology Platform kyma Runtime Service because of the four dimensions which were discussed in the previous blog, why place the Enterprise Blockchain Platform in the SAP BTP ?
It's very very simple....
Proximity to the Data (of the Digital Core)
Ethnicity of the Data (in the Digital Core)
Proximity to the Process(es) (in the Digital Core)
Proximity to the Technology (of the Digital Core)
So, we're following our Company's Demand Process, we've taken the Business Demand, and the Requirements, we have processed them according to our Company's Enterprise Architecture Demand Process and we have identified by matching requirements to Enabling Technology capabilities that the Technology Standard which we have in the house to fulfill these Requirements is the Enterprise Blockchain Database Platform.
The next step is to design the Solution Architecture, the Technical Solution Architecture and show the options for fulfilling this requirement.
The basics of the Technical Solution Architecture are:
. SAP S/4HANA contains Business Partner Master Data
. Every time Business Partner Master Data changes we need to send it to the Enterprise Blockchain Database Platform
. The Enterprise Blockchain Platform Tenant will run on the SAP Business Technology Platform Kyma Runtime Service
. The Enterprise Blockchain Platform Tenants will be deployed in three SAP BTP locations around the world
. The Enterprise Blockchain Platform Tenants will be deployed in each location on the SAP BTP on a different Cloud Hyperscaler
In terms of SAP Enterprise Technical Architecture it is pretty clear what the Solution Options are, and we will draw all of the Solutions Options here in the blog, but one variable, one open question which we haven't solved yet, is how to get the Business Partner Master Data out of S/4HANA and to the Enterprise Blockchain Platform.
To solve this, to get the Data from the S/4HANA there are a number of options, and in this blog we will focus on:
. Events - Event Driven Blockchain [this will need the SAP Advanced Event Mesh]
. API's - API Driven [this will need CI to call the Business Partner API on S/4 and then call the API on the Blockchain]
we will now elaborate the Technical Solution Architecture of both alternatives, Event Driven Blockchain, and, API Driven Blockchain.
Business Continuity Planning Technical Solution Architecture SAP S/4HANA, Events, Enterprise Blockchain Platform
in this option, the SAP S/4HANA is connected to the SAP Advanced Event Mesh running on the SAP BTP. SAP S/4HANA publishes a Business Partner Event including the Data, the Payload of the Event to the SAP Advanced Event Mesh on the SAP BTP. The SAP Advanced Event Mesh on the SAP BTP has Topics and Queues created and puts the Business Partner Event and Data into one of the Queues. The Enterprise Blockchain Platform which is running on the SAP BTP Kyma Runtime Service is connected to the SAP Advanced Event Mesh Queue as a Subscriber and listens for new Business Partner Data arriving. As soon as the new Business Partner Data arrives in the Queue the Enterprise Blockchain Platform places that Data as a new Block in the Enterprise Blockchain Database.
S/4HANA on SAP RISE PCE on Azure in Europe -> SAP BTP Advanced Event Mesh Azure (Europe) ->
-> SAP BTP Advanced Event Mesh on SAP BTP on AWS Europe
-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on AWS Europe
-> SAP BTP Advanced Event Mesh on SAP BTP on Azure USA
-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on Azure USA
-> SAP BTP Advanced Event Mesh on SAP BTP on Google Cloud Platform Asia
-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on Google Cloud Platform Asia
SAP Event Driven Blockchain Advanced Event Mesh Multi Cloud Business Continuity Planning atkrypto.ioThe picture clearly shows the distributed Regional/Continental resilience of the solution, and the Multi-Cloud resilience of the solution.
Business Continuity Planning Technical Solution Architecture SAP S/4HANA, API's, Enterprise Blockchain Platform
in this option, the SAP S/4HANA is connected to the SAP BTP Cloud Integration running on the SAP BTP. A Periodic Job running on SAP Cloud Integration calls the Business Partner API on SAP S/4HANA and gets the latest Business Partner Data Changes. SAP BTP Cloud Integration then calls an API on the Enterprise Blockchain Platform which is running on the SAP BTP Kyma Runtime Service and puts the new Business Partner Data on to the Enterprise Blockchain.
SAP BTP Cloud Integration (Europe) calls an API on -> S/4HANA on SAP RISE PCE on Azure in Europe
SAP BTP Cloud Integration then calls an API on the Enterprise Blockchain Platform
-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on AWS Europe
-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on Azure USA
-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on Google Cloud Platform Asia
SAP API Driven Blockchain Integration Suite Cloud Integration Multi Cloud Business Continuity Planning atkrypto.ioThe picture clearly shows the distributed Regional/Continental resilience of the solution, and the Multi-Cloud resilience of the solution.
Wrapping up, the goal of this blog, was to remind us all, that if we happen to have fallen in to the bad habit of trying to find a Use Case for the Blockchain, not to worry, but at the same time, forget doing that, and get back to doing Enterprise IT Architecture the way we always have done and with proven Demand Evaluation Processes which will always lead the Business Demand to the most appropriate Enabling Technology Standard, and therefore, let the Use Case find the Blockchain instead of the Blockchain finding the Use Case.
There are many many Use Cases where Blockchain is the obvious choice for the Enabling Technology Standard.
In my opinion, Business Continuity Planning, is one of the many, a "no brainer" Use Case, for the Enterprise Blockchain Platform.
Business Continuity Planning is one of my favourite Use Cases for Enterprise Blockchain, it is so simple, so elegant, and everything is done for you. Less than 10 years ago, to achieve the same resilience and security as an Enterprise Blockchain Platform would have required a shopping list of software and procedures, some automated, some human. And this is the beauty of the Blockchain Technology.
In the next blogs, week by week I will be blogging Use Cases, the blogs will follow a template where the Business Demand, the Use Case is discussed, the Architecture Demand Process will be followed and the outcome will show, week by week, Use Case by Use Case, why Blockchain is the best Enabling Technology Standard for that Use Case and Demand. The blogs will also describe all of the Solution Architecture Options.
The next blog will be, "SAP Enterprise Architecture: Let the Business find the Blockchain - SAP, Oil, IoT, and Blockchain"
If you have a Use Case you would like illustrated, let me know in the comments and I will blog the Solution Architecture.
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, more use cases, ok, that will continue in 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.
- SAP Managed Tags:
1 Comment
