Hey, everyone, welcome back to the course.
So now we have gone through the core principles of blockchain architecture, and we have also seen the
different factors which will affect the design of our enterprise blockchain solutions.
In this lecture, we are going to take the learnings which we have done till now, and we are going
to employ those learnings to build up different view sets for our enterprise blockchain applications.
If you have previously worked with Enterprise Software Architecture Solution, you might remember that
there are different views which you can build for any system.
Let's say you have taken up the requirements from the customer or for the project which you are currently
building, and after analyzing the requirements, you come into designing the solution.
In the designing phase of the solution, you are going to build up different views to capsulate different
services which are going to be part of your solution with blockchain solutions.
Also, we are going to do the same.
We are going to build up different views which will help us to calculate the different services and
different interaction capabilities which are going to be present throughout our solution.
So the first major view which we are going to build up with our blockchain systems is going to be a
conceptual view.
A conceptual view is the representation of a system which shows the composition of concepts.
This view helps people know, understand and simulate the model subjects which are designed inside our
enterprise solutions.
The primary objective of this view is that it enhance the understanding of the system.
It also provides the efficient system details to different stakeholders.
It also act as a point of reference for designers, and it also helps in collaboration with different
teams across our project.
There are different techniques which you can use to build up the conceptual view.
One of the technique is data flow in data flow, conceptual view, you basically show the flow of data
between different services.
Then you can also have a entity relationship conceptual view which shows the relationship between different
entities regarding your system.
Then you can also create an event driven conceptual view which will help you to formulate the architecture
based upon events which are being triggered inside your solution.
And then you can also formulate this conceptual view as per your business or technical factors.
So now let's go and see a very generalized view of the conceptual view and let's understand what different
entities are going to be part of our enterprise blockchain solution.
So this is a very generalized solution for conceptual view regarding the enterprise blockchain application.
You can see here we have only labeled the concepts.
We have not defined different entities which are part of these concepts.
This is more of a view to understand what is happening inside the system.
So here we have labeled it as a node and an organization, and inside the organization we have a ID
which is identification manager, and this identification manager is going to provide identities to
different modules which are present here.
So we have a application module which will act as a front end for our services.
We have a blockchain module which is the core of the blockchain.
We also have a internal systems.
Internal systems are basically our logic based application or your core services, which are already
part of your enterprise.
Then we have integration module which will help us to integrate the internal systems with the blockchain
module.
Finally, we have the external service providers.
These could be related to any external data services or Oracle which are going to interact with our
enterprise applications.
And then we have blockchain peer nodes where we are going to replicate our complete blockchain module
at different computers throughout the geographical locations.
So this is a generalized view for conceptual.
Each module which is present here inside the conceptual view, you can take it as a separate concept
because this provides the architect or designers with a much more high level concept, and each single
architect or designer can take one part of the module and then enhance that module into different concepts
to showcase how different entities are working together.
So let's understand how this can be done.
So the first one, let's take the ID is the identification manager.
So identification manager, this is an important part of Enterprise Solutions Identification Manager
provides the secure keys and certificates to each entity inside our enterprise solution.
This is important because industries need to know their users or customers.
They cannot build up a solution where users or customers are anonymous.
They need to know their users or customers and fabricate their solution as per the customer base.
Moreover, identities can also be used by other participants to check across whether this user or a
customer is part of our enterprise solution or not.
If this is not part of our solution, then we can reject the customer.
Apart from this, several permissions and authorizations throughout the system will also be based upon
the identification which have been provided to entities.
It could be possible that one of the computer inside enterprise solution is labeled as a validator,
so that computer will have the access to the transactions and can see who is sending the transaction
and what are the different aspects of the transaction.
Similarly, other computers could be labeled as just the computer nodes.
Then they don't need to have the access in regards to the validator nodes.
So as per the idea, we will be providing the access permissions.
Also, this identification manager, which is part of the enterprise solution, could be related to
Ldap.
Ldap is a lightweight active directory which just stores the information of the users which are currently
being employed with the system.
It could also be related to the full Active Directory, which is employed with the enterprise applications.
Apart from this, many enterprise also take up the solution of creating their own certificate authority
and making those certificate authority as identification manager.
Some of the blockchain projects directly provides you the identification manager.
For example, if you work with Corda or Hyperledger, you can directly use the membership service providers
present there.
Hyperledger Fabric provides the option of putting up OpenSSL or Hyperledger Fabric Keys to act as identification
managers.
So this is another conceptual view for the identification manager.
So as I told you, that was the enterprise conceptual view, which is very high level and this is downgraded
to one single module.
So inside this module you can see we have divided into three parts.
One is identity applications, second is identity manager engine, and the third is identity manager
drivers.
The identities are stored in a data warehouse.
This data warehouse will act as a key and certificate storage.
Identity applications are basically the different applications who are going to use the identities.
It could be that you are provisioning APIs for the applications to call upon.
It could be a user self service, it could be some access control you have delivered, it could be related
to workflow.
So anything related to where your identities are being used will be present with the identity applications.
Then you have identity manager.
Engine identity manager engine is basically different rules and regulations and logics which are being
applied on the identity.
It could be possible that your identity is password protected.
It could also be that identity is part of a vault.
Apart from this, we can also employ policies or rule engine on top of the identities, and we can also
provision real time data synchronization processes for the identities.
The third important part of the identity manager are the identity manager drivers.
Identity manager drivers are basically the software suit, which helps you connect your identities with
different bases or applications which are going to be part of your system.
These drivers are acting basically as a connection between all the different applications and your identification
manager and thus provide the services through which these different applications will have the access
to the certificates.
There are different drivers which you can build up here.
These drivers could be related to applications, operating file systems, cloud SaaS, credential provisioning,
HR systems, ERP systems.
So all those different bases or all those different applications where we require our identities will
be managed through the identification manager drivers.
Finally, we can also include the identification management and reporting services through which we
can showcase that what different identities are being used at different locations throughout our enterprise
application and what kind of different permissions and access controls are provided by these identities
after Understanding Identity Manager.
Now let's go through the details about internal systems and what different concepts can be put across
with the internal systems.