Welcome to the 3rd Thread in this series, this Thread, continuing the journey which we have started with the previous two Thread, 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.
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.
So why are we doing this Thread ? 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 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 Thread 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 Thread, the point is the Thread 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 Thread 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 Thread 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.
BSS Business Support System 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 Business Continuity Planning Requirements atkrypto.io
The next step in the 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 Business Continuity Planning Requirements Technology Capabilities Analysis atkrypto.io
Now that we have the key Enabling Technology Capabilities we can look in our 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:
Blockchain Required Enabling Technology Capabilities atkrypto.io
Looking 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 Threads, 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 blockchain
For 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 Kubernetes on three separate HyperScalers running in three different continents. We could install the Kubernetes on a Cloud Provider in the USA, we could install Kubernetes on a Cloud Provider in Europe, and we could install the Kubernetes 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 Kubernetes on AWS in the USA, Kubernetes on Azure in Europe, and Kubernetes 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 Kubernetes.
That's one dimension, but in this Business Continuity Scenario it goes further than that. We have said we will spin up the Kubernetes in three Regions, three Continents, and by spinning up the Kubernetes on a different Cloud Provider in each Continent, each Region, and then running the Blockchain on the Kubernetes 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 BSS Data will be sent to the Enterprise Blockchain Platform which is running on Kubernetes because of the four dimensions which were discussed in the previous Thread, why place the Enterprise Blockchain Platform on the Kubernetes near the BSS ?
It's very very simple....
Proximity to the Data (of the BSS)
Ethnicity of the Data (in the BSS)
Proximity to the Process(es) (in the BSS)
Proximity to the Technology (of the BSS)
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:
. BSS 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 Kubernetes
. The Enterprise Blockchain Platform Tenants will be deployed in three Kubernetes locations around the world
. The Enterprise Blockchain Platform Tenants will be deployed in each location on the Kubernetes on a different Cloud Hyperscaler
In terms of Enterprise Technical Architecture it is pretty clear what the Solution Options are, and we will draw all of the Solutions Options here in the Thread, but one variable, one open question which we haven't solved yet, is how to get the Business Partner Master Data out of the BSS and to the Enterprise Blockchain Platform.
To solve this, to get the Data from the BSS there are a number of options, and in this Thread we will focus on:
. API's - API Driven [this will need CI to call the Business Partner API on the BSS and then call the API on the Blockchain]
we will now elaborate the Technical Solution Architecture of the API Driven Blockchain.
Business Continuity Planning Technical Solution Architecture BSS Business Support System, API's, Enterprise Blockchain Platform
in this option, the BSS is connected to the Enterprise Blockchain running on 3 different HyperScalers in 3 different geographies. A Periodic Job running on the BSS sends the Business Partner API Data via API to the Enterprise Blockchain Platform which is running on the Kubernetes and puts the new Business Partner Data on to the Enterprise Blockchain.
Integration Broker calls an API on -> BSS and fetches the Data
Integration Broker then calls an API on the Enterprise Blockchain Platform and writes the Data to the Blockchain
-> Enterprise Blockchain Platform on Kubernetes on AWS Europe
-> Enterprise Blockchain Platform on Kubernetes on Azure USA
-> Enterprise Blockchain Platform on Kubernetes on Google Cloud Platform Asia
API Driven Blockchain Integration to Multi Cloud Business Continuity Planning atkrypto.io
The 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 Thread, 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 Threads, week by week I will be discussing Use Cases, the Threads 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 Threads will also describe all of the Solution Architecture Options.
The next Thread will be, "Enterprise Architecture: Enterprise Blockchain Business Capability Map 🚀" where we will be talking about this:
If you have a Use Case you would like illustrated, put it in the comments, let's discuss it, and I will make a Thread for the Solution Architecture.
The good news is, as we discussed in the previous Thread, this is no longer hype, we can do all of this today, and now, and Blockchain, today it's real and there's nothing stopping you.
I am from a DTW24 Next20 Startup, and our product is available to be download as a free trial on Docker, and I can only encourage everybody to start looking at Enterprise Blockchain and getting familiar with the capabilities and opportunities, regardless of which product you go for.
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.
CEO of atkrypto.io
Exhibitors Information | DTW25 Ignite TM Forum
atkrypto Enterprise Blockchain Platform 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.
#AIandData
#Blockchain
#OpenDigitalArchitecture
#Blockchain
------------------------------
andrew silvey
atkrypto.io
------------------------------