 So there's some more dad humor. The live stream is up, so you're welcome to kick it off. All right, thanks everyone for joining. Quick housekeeping items before we start. Our speaker of the day, Ken, has 35 years working in the insurance industry as an architect. And he's worked with large carriers, vendors, and now EIS, an advisory organization. It's a pleasure to be hosting this session today. Ken welcomes questions during these sessions. So if you would like to pause and ask, please unmute yourself. But if you're not speaking, please mute yourself through the session. And just a bit of introduction for this session today is so every time there's a natural catastrophe or a pandemic or a hurricane on an earthquake or something like this strikes, straight regulators require or ask for insurance carriers to send them the data about the effective properties. This data helps regulators model risk, monitor the market activity, predict consumers, and plan for future emergencies. And God knows that from since 1980, United States has suffered more than 250 extreme weather disasters, causing more than $1 billion in damage each. And but these are ad hoc reports that come on top of routine, quarterly, and annual statistics. And there is no good way to present that data. So when AIIS invited carriers and regulators to brainstorm, a solution was created. It's the blockchain network. So since 2018, AIIS has operated the first blockchain system used to gather the data from across the US insurance industry. So Ken, with that, I open the floor for you takeaway. OK, so as David mentioned, questions are welcome. We're an insurance industry. This is not just an insurance solution at the end of the day. So if I'm going in the wrong direction, just ask a question, get me going in the direction, answer any questions, make sure you're getting what you like out of this. I'm going to try to focus on we're using hyperledger fabric for solving a very important problem. So if I steer away from that, just let me know. OK, so OpenIDL, why are we doing OpenIDL? There's a couple of main use cases that you pointed out. There's this thing called a data call where a regulator in the insurance industry needs to get some information about what's going on out there, how many people are covered for different things so that they can put the proper precautions in place ahead of catastrophes, et cetera. So that's kind of an ad hoc need for data where a regulator, a Department of Insurance, is trying to find out what's out there. And they're asking the carriers to provide them information. Another one is statistical reporting. AIS, as you'll see in a minute, is a statistical reporter. We provide data to the departments of insurance about how much insurance is out there for different carriers. So as I mentioned, there's other applications that can be used. You'll see it's from at its base. It's hypoallergic fabric and can be used for a lot of different purposes. It's mainly, it's probably the biggest win to get out of OpenIDL is improved data privacy. And I'll hopefully that will be illustrated over the course of this discussion. So I'm going to show you from a high level what we're doing, why, do you a quick demo just to give you a sense of how it hangs together. And then we'll go in all to the bubble charts and things to show you some of the architecture decisions made and how hypoallergic fabric fits into this picture. So here's a couple of places that you can see what's going on with OpenIDL. There's the www.openidl.org. There's also the Wiki, where we're slowly putting more and more documentation on the system out there. And we have a GitHub repository on OpenIDL.org. So we are currently, we just transitioned to a Linux Foundation project. So it's all open source. While we're working with carriers, et cetera, the software itself is open source. The data is very much important to these customers and they don't want to share it. And that's why we're doing OpenIDL. We're using very stable technologies underneath and hypoallergic fabric is one of those. And the biggest takeaway from here is this true data privacy is what we're enabling is for carriers to provide data in a standard way as efficiently as possible without sharing data they don't want to share. So what you'll see today is set in the insurance world. The first scenario, I talked about the data call where a regulator is trying to look for information. So that's the backdrop for all of the demo, et cetera. I'm not sure you can see. So let's give you a quick introduction to AIS. A-A-I-S, which Jody, as everybody first trying to say it, stumbles a little bit. It's the American Association of Insurance Services. We're 80 years old, not probably 90 years old now. Been around for a while. We're a nationwide agency that does three main things. Statistical reporting, when carriers have to report their information to the regulators of how many claims and how much premium they've gathered for different lines of business. We do that on the behalf of also our rating bureau. We provide loss costs, which are the base number used to come up with premiums. We do that with data that we are given by our carriers and so that we can understand the kind of actuarial, we use the actuarial data to provide these loss costs. And then the advisory organization will provide forms and manuals and other information about these products. So for example, for an auto product, we provide all the forms, et cetera, that you might get on your auto policy. And the reason we do that is because some small carriers or brokers or whatever might not have the desire to do all of that work. We do that in a standard form. We have a lot of experience. We provide forms that they can use or they can change them, et cetera. So these are the three main things that we do. We're not for profit. Unlike our largest competitor, we're doing it on behalf of the insurance industry and we do it very efficiently. So what are the challenges that we're trying to solve with Open ADL? The recurring problems, the data owner, in this case, an insurance carrier wants to keep their data private and in their control. But if they have to constantly send data across to regulators, then they're losing control of that data. And they don't want to do that. They want to know that the data that they are sharing is managed properly. It's an auditable process. And they want to make sure that they understand what's going to be done with the data when they provide it. So why Open IDL ensures get that data privacy? Regulators get reliable and timely information that they're looking for. And AIS, we also get a big win. We're doing this for a reason, too. We currently store a bunch of this data in order to record it to the department's insurance. With this Open IDL model, the raw data never leaves the carrier. And so we don't have to have all of it on hand all the time. And that saves us a lot of cloud bills. So the Open IDL network, it is a network of four main purposes. There's the owner and a carrier will have data that is used as the source for something like a data call. There's the government agency that needs to get the information. And then the AIS, who provides support in this interaction. And so you can see, if you know Hyperledger Fabric, there's a couple of different connectivities between these different organizations. And as we mentioned later, we use channels for that. The Hyperledger Fabric is a really good fit for what we're trying to do. This was all stuff that Drummond would have done. We'll take in a little more time because he can go into more depth. But so let's talk quickly about the architecture of the system. And then I'll do a demo and then we'll get in some more details. Any questions of interest yet? Joati or David? No questions yet. But I have one Ken really quick from in a standard point of view, so every industry is struggling towards standardizing whether it is tokens or protocols or for interoperability for free production. So is the open idea also get towards implementing any standards? Or are you? Yes, I do have a slide for that. You're giving me a sort of a four slide segue, about four or five slides from now. I'll get to that. There is a data format that we rely upon and will become a standard over time because at some point you've got to agree on the format of the data in order to have multiple carriers participate in a common extraction of that data. So yeah, so the standard that we're developing right now, it's a data standard for what we call the harmonized data store and that'll become more apparent as we go. So absolutely those standards. And Dina, I don't know if Dina is on this call, but Dina is our person inside AIS responsible for that. And her information, I think, is later on in the presentation. OK, so let me give you a quick overview of what the architecture of the system is, what the different nodes are. So we use the term node to represent the full package of open IDL for a particular purpose. The three main purposes are for, I'll go through them individually, but you can see that there'll be many carrier nodes. There's usually one sort of what we call an AIS node and an analytics node. Multi-carrier node or the AIS node is used by possible multiple insurance companies who don't want to step up to having their own node. And also, AIS and regulators use this node to create and manage data calls and other requests for information. The carrier nodes are, and this is one of the most important aspects of the open IDL, this is a distributed network in that this node here is hosted by the carrier themselves. We provide them all of the scripts and start up to get a node started and connected into the network, provide them, create certificates, et cetera, necessary to create the organization and connect into the different channels. So they host that. And that's why data privacy is one of the main things we've accomplished here is the data that is there. Raw data is in their cloud, not visible outside of their cloud. And so each carrier will have their own node, and therefore their raw data will be managed only on their node. I got to speed this up a little bit. And then the last thing is in a data call, as we create data calls and the carriers respond to those data calls saying you can use their data, the regulator can see the results of their data. It all goes into this analytics node where it's combined and the report is created and sent out. That's all part of the standard data call process that we do today, where we aggregate all the information from across multiple carriers. So this is a very high level view of the system. Let me go into each type of node, give you a little sense of what's in there. So this is the diagram as it stands in IBM cloud right now. We're moving all of our stuff into the Amazon web services cloud with use of, I saw Isaac on the call. We're utilizing ChainYard to help us migrate this application and it's going really well so far. So thanks Isaac for joining. And just a quick call out that ChainYard and other vendors are part of the community and are available for carriers to utilize as they start to connect into this network as well. So carrier node is gonna have a couple of different things, a carrier and this multi-carrier node. They're gonna have a database where we capture the raw data. In the multi-carrier node, that's not nearly as private as when you have your own node but for small carriers, it might be fine. They put enough data here to get the job done. And then of course there's some cloud specific services that are required to make this all work. Like when you're connecting into an application and you need to be authenticated, you need some sort of authentication for that cloud. And because there's applications involved in here, right? These applications are running in a Kubernetes cluster. There's an application for loading data and there's an application for managing and responding to data calls. And that's all inside of Kubernetes cluster, as I mentioned, just JavaScript, Angular UI and JavaScript backend. And these applications, the API specifically have access to the network through the Hyperledger Fabric API. So Hyperledger Fabric is running its components for this particular node in another cluster and these APIs call to create transactions, put stuff into the ledger and get things out of the ledger, et cetera, and also interact with the private data collection. So the carrier node is very similar apps and data loading capabilities and local services for that cloud provider and jacking in again to the network through a cluster that's hosting the Hyperledger Fabric components. So the last type of node, which is different than the other ones is the recipient of the process when all the data is consented and I'll discuss that in a minute, the details of that. It's aggregated here. There's some listeners to the ledger that say, we just got some data in, you can do your report, it runs the report, puts it somewhere. This is representative, not, each analytics node may work this slightly differently. So we've talked about the three kinds of nodes, one for multiple carriers and one used by AIS and the regulators. That's the multi carrier node, a carrier node, which is one per carrier and those are all hosted by the carriers themselves, carrier being an insurance company, sorry, use the insurance lingo. And then the analytics node, which can be hosted by anybody and for now, we're hosting that AISs. So the life of a data call is a regulator creates a data call and puts it out onto the ledger, the different carriers see that call and then do something to say, I'm good with responding to that data call, I'll provide you an extract of my data and that'll be put onto the analytics node and reported. So, okay. So let me go through the scenario real quick, then I'll do a demo and then we'll get into the architecture, how we support this functionality. So the first step in a data call is for the carriers to load their data, right? So this harmonized data store inside their cloud is gonna hold all of the raw data that includes much more than they really want to share, but it's put into a format, as you mentioned, Joachim, this is the format for this is the standard that we are established, so that when a carrier puts their data in there, it's in a format that when we need to report on it, we know exactly how it's organized. So we describe this standard and there's a working group in the Linux Foundation for managing that standard. And if anybody wants to contribute to the standard, more than welcome to participate in that, some contact information at the end. So regularly, weekly, monthly, quarterly, the carriers are loading their data from the transactions that happen, right? New people create new policies, they have planes, et cetera, this gets loaded into here over time. And then a regulator using the AIS node will come in and create a data call, says I'd like to see how much insurance we have for hurricanes in South Carolina, creates the data call and that gets put on to the ledger, right? So we hadn't put anything on the ledger except the knowledge that data was loaded in this first step, but in the second step, the data call itself is just a simple JSON document that has text about what we want to get out of this data call that gets put on to the ledger. So I'll show later, it's hard to show too much on the right amount on a single screen, but there's two channels happening here. Right now we're using what's called the default channel where all of the carriers and the AIS node are all in the same default channel and therefore they're sharing a ledger and the data call is put onto that ledger. So at this point, once it's on here, this UI, which is very similar, will show all of the data calls that are currently in the ledger and the carriers have a chance to read, what is it you're asking me for? You're asking me for hurricane coverage and such and such, what data fields do you want me to share, those kinds of things? And at that point they'll say they like or unlike it, meaning that this is something they could respond to or if they unlike it, they might send a note over to the regulator and say, that's crazy, we can't reshare that data, we need to change this a little bit and we'll go through this process of creating new drafts of the data call until everybody's happy. So once there's enough carriers that say this is a good data call, we'll do an issue of the data call, the regulator will see that everybody likes it, they'll issue the data call and now the request itself is not changeable, but it's not quite executable yet, because what a data call in the end of the day wants to do is access this data base, this private data, turn it into some sort of shareable data that we can get over to the analytics node. So let's see how that happens. When the regulator issues the data call, it goes into a state where we can create an extraction pattern and attach it to that. The extraction pattern right now is a MapReduce, right? So in Mongo, there's the ability to do a MapReduce, you give it two JavaScript functions, it converts it into a different collection and the results are there's some aggregation and some keys created. So all the extraction pattern is two functions, a map and a reduce. That, those two functions are stringified and put into the data call and put onto the ledger. So now on the ledger, we not only have the data call verbiage, but we have the actual code that will execute should a carrier consent. So this is a real important aspect of this that the carrier when they consent will have a chance to see the data call, what's gonna be executed against the database. They have actual code, the MapReduce functions, they can pull that, download that, they can test it, make sure it will do everything they expect and nothing they don't expect. And if it's true that they're happy with it, it represents the data call, they can then consent. That's an event that goes onto the ledger so that there's evidence of who's consented. And as a result, a listener will say, how they consented, I'm gonna now run the extraction pattern. And the execution of the extraction pattern is basically on every consenting node, that extraction pattern is loaded up into a program, sent to Mongo, it runs the extraction pattern and the results of the extraction pattern are put into the private data collection. So we're again, depending on hyperledger fabric, share the data. The private data collection is on a channel that's connected to the analytics node for each carrier node. And so the data shows up here and then the report can run. I have diagrams in a little while that illustrate all this again. So hopefully that's not too vague, but that's what's going on from a high level. So the actual extraction pattern itself, when the carrier consents to the data call, the extraction pattern is retrieved from the ledger, I would put it in the ledger and then the extraction pattern is run against the harmonized data store. And at the time this is run, it has the ability because it's on the carrier node to correlate private data with other data. So in this case, we did a proof of concept to show some carriers how this could be done. We wanted to correlate the address with PPP data so that we could tell how many of these policies are for people who need a PPP data. So do they need coverage? If they've got a loan, they may not need coverage. So this is possible with this architecture because the time we're correlating this data, we have access to the address because we're on the carrier node. If we were to run this in some other part of the architecture, we wouldn't have access to the address because carriers will not share the address. So because we're running it on their node, we have access to the address, we can correlate the PPP data and we can share the PPP correlated data in an aggregated fashion and the address is never shared. So we're able to use the address without sharing it. So that's a superpower that this provides. Previous to this, every carrier would have to do all that themselves in their own way, right? But now we're providing a consistent way to do it and in a private way where they don't have to share data that they don't wanna share. Okay, so the results of the extraction pattern are put into the private data collection and that's on the channel that's connected to the analytics node and because the way your hyper legit fabric works, it automatically gets put onto the analytics node in a private data collection over there and analytics tools have access to that data to run reports. Any questions so far? We're halfway through when we go through a quick demo and then we can go into the details. Hey Ken, there are a few questions in the chat if you're gonna, I'll read them out to you. Okay, let's see. Winston asks, are there any smart contract examples published standards such as ERC-20 tokens kind of look? So are, yeah. Okay, so let me just answer the smart contracts are all crud here, right? Most of the secret sauce to this application is outside the smart contracts. We update and read from the ledger and push to the private data collection but those are just very simple smart contracts. We haven't actually changed the smart contracts in a year and a half. All right, Sanket asks, is there only one channel and you're using private data collections or multi channels and then private data collections? Yeah, there's two kinds of channels. There's the default channel that connects pretty much everybody on the network and then there's a peer to peer channel for every carrier to the analytics node so that when they actually get their data extracted it's on a private channel with the analytics node. Sounds good. And is managed service being used for this? So we're moving over to Amazon. We're not using a managed service. We are considering creating some managed service for these things. We know that the Amazon Kubernetes managed service doesn't go cross-cloud and they need to do multi-cloud. So right now we're not doing any managed services. We probably will provide a marketplace component as we make this available in a more open way. As of now, we've been building with infrastructure as code but it's more sort of as we go building each node in its own way without managed services but we've looked to get there and ChainYard will be helping with that among other vendors as we go. Great. And the next question comes from Vladin. Have you considered IPFS interplanetary file system? I would have to say that's a question for ChainYard. As of now, we don't, I don't know where we would use that so I'm happy to have a follow-up conversation. We've used S3 a little bit but that's a work, so one of the tenets of this architecture is to be cloud, multi-cloud and therefore as agnostic of the cloud as possible. And so we're trying not to use S3 per se as a place for files but IPFS, where that would fit in your architecture? I'm not sure. I'd have to have a separate discussion so sorry I couldn't answer that one. Okay, this question from Isaac. He asks, did you harmonize data standards get developed as part of the OpenIDL project or did they exist prior to the project? Yeah, prior to this project we had something called statistical plans which is how we would capture data from our customers that are very old. We wanted to modernize those and as part of the modernization we're defining those standards as we go as part of the OpenIDL. Yeah, we do try to base it on other standards and point to other standards but there's all kinds of things that are outside my sort of expertise as to why and what for is it how those standards will be developed? That's good. Shashank asks, what's the compelling reason for using hyperliter? Or could we use something like EOS as Vincent? It's a follow-up. Yeah, so I had an earlier call where one of the carrier architects like why are we using blockchain? We just wanna use the term, right? And the answer is it looks funny I was that person inside AIS, right? And I was like, why are we using blockchain? We could do this ourselves. So blockchain has some inherent trust associated with it that if a carrier comes along and then here's the word blockchain they know there's something going on there about privacy and trust, et cetera. Hyperledge of fabric is an open source, well-known thing that it does this pretty well. I'm not gonna tell you that there's not a better option for what we're doing here, it fits well and we're not, I don't think we're overusing it and as we get into the diagrams I'd be happy to get feedback on all what you didn't really need hyperledge of fabric for that. And the answer is clearly we didn't need to use hyperledge of fabric but if we built it ourselves then that would be a red flag for a lot of people but some of the other technologies there's a history to any project to the people who initially built the system they use hyperledge of fabric and we haven't seen a reason to change course on that. But so if that's in the chat I'll wanna look up that particular I don't think I'm familiar with that particular framework mentioned there. There are a few more questions but maybe we can table that towards the end. Yeah, we'll get into more detailed pictures which we don't like to see. So let me do a quick walkthrough. I'm not gonna do the full flow it's like a 10, 15 minutes flow but I'll give you a sense of what's going on at any one time, right? So the first step in the process is for a regulator to create a data call. So this is the AIS node we mentioned before. Sorry, AIS node, right? So the name is indicative up here. So I'm gonna log in as a regulator, right? So I have credentials, part of an organization I'm looking in the default channel now and I see these data calls these are the draft data calls and then there's some issued data calls. These are all things that are on the ledger, right? So I am getting these from the ledger there's some room for some UI improvement here but basically a regulator comes along creates a draft data call and now this is visible to all the carriers, right? So when a carrier logs in, I will log in as this carrier here. Again, carrier is an insurance company. I just use that. So they see these same draft data calls they can go in, take a peek at it and say, yeah, I see what you're trying to do, right? This is all verbiage at this point, right? There's no code to run but this is something that's been put onto the blockchain and I as a carrier can say, I do or don't like it I can put this like to like the data call and then when the regulator comes back in and looks at that, I know there's a little bug here they'll see that lights increase and eventually they'll say that's good and the regulator at one point will say, I'm gonna issue this, right? So there's a few functions here available to the regulator because of their role that are available to a carrier that can create new data calls they can issue, et cetera, right? So this here, while we're running it in our own cloud right now for a proper concept purpose this is the code and the whole node that would be running inside a carrier's cloud, right? This would be on Amazon or Google or Azure and maybe the IBM cloud we don't get a lot of calls for IBM cloud but this will be running on their cloud. So once enough carriers are happy with it the data call is issued and once issued, the data calls are available for consent, right? So up to now a carrier hasn't done anything to say, I want you to use my data they have to look at the extraction pattern so here's the extraction pattern I can look at what the code was written to implement the language that we saw let me just say this real quick so the code it can be very complex but it's really just like I said a map reduce function so this is just a way to share as a string so a carrier can take this and say I see the map function I see the reduce function is down in here too and take this code, put it into their development environment point to their database, run it, see what would result because it's just a standard way of executing something against Mongo and they can basically test it and verify that it is what they expect and once they agree that it is what they expect then there's a consent, I've already consented to this there's a consent button over here that says I consented that and at that point the consent will run the extraction pattern against their Mongo database so let me give you a quick look at what the Mongo database looks like so this is just a little test database that I used but so this is the insurance carrier's data this is what they actually have provided in here so let me just expand this guy so here's information that is private for the carrier for this particular policy they have provided an address that they don't want to share with the regulators but when we run the data call we do want to use that address to see if there's a PPP loan associated with that so when the extraction pattern ran it results in another collection and that's what this collection is it's basically taking that input data running that code you just saw and then giving results and the results of those are there's no address in these results there's some some key information and some aggregated information but there is evidence of what the address was used for which is this PPP information you can see here that we were able to use the address we don't share the address itself now on the output but we use the address to find the PPP loan we can get the loan number etc but we can get how much the loan was for some race information all kinds of extra information that the address was used for but didn't share the address and so it's really important so then what happens is one of the components in the carrier node will then take this collection and put that into a private data collection private data collection goes over to the analytics node and then the report can be executed and then after a certain period of time we throw away the data on the analytics node so I know that's not the full fledged start to finish demo it's too long for this purpose but you get the idea that there's different roles there's carriers there's AIS role there's a regulator role so the AIS role was we were the ones who put the data call the extraction pattern into the data call and then the carrier's consent and like and the regulator creates and issues the data call okay so sorry about the quick demo but I would do want to show why we're using hypoallergic fabric because I know that is the main purpose we're together so you know it's not all about hypoallergic fabric this has got a lot of basic requirements architectural requirements that we need to cover off so I'm just going to throw those out real quick and try to answer how we hit these after I go through the diagrams so trust immutability right it's very important that the the carriers trust that their data is not going to be messed with and if they if they do something that nobody can change that like when they consent to something somebody can't say they didn't consent it needs to be performed of course needs to be secured it's got to be permission we need to know who's in this blockchain network that's why we're using hypoallergic fabric permission network needs to be distributed we're going to have nodes that are not running in our cloud and that other cloud could be AWS could be Azure could be Google it might not even be a cloud we're not sure we want to support the non-cloud sort of running on on-prem model but it's definitely a possibility and it needs to be manageable so when I talked about the PPP aggregation there's a lot of different data sources that might be pointed to maybe it's just a call to a URI maybe it's a whole data set maybe it's a component that needs to be added we need to be able to manage nodes that are distributed we need to be able to go to that carrier and say we need to give you a new version of OpenIDL that gets installed in your cloud and runs the way we expect right so it's a very important part of this process too it needs to be transparent so that when we tell a carrier that we want to install new things they need to be able to know what's being installed they need to know what so not only on the provisioning of the infrastructure but also all of the different aspects of the interaction it's all in the ledger and nobody's hiding anything there's no secret things going on as far as the correspondence between the different people on the network and then the keeping the data in places is really one of the main reasons we started looking at OpenIDL how does how can a carrier keep their address but make it usable for connecting to other data and how can we keep that from going data from going across the network that shouldn't that doesn't need to right we don't they don't we don't want carriers to have to trust us not to use their data for other purposes or or have some sort of breach we don't want the data at all right so keep the data that's private in their world and never share it okay so the application architecture kind of gone through a little bit of this right it's it's using distributed ledger technology the hydrologic fabric so that anything we're doing with other carriers and nodes is all managed and evident on the the ledger itself and any data that goes across to the analytics node or etc we'll be using private data collection so this is not code we wrote right we're just building on top of hyperlogic fabric we know everybody on the network is has is permissioned and has the right certificates and everything the the code themselves where it is running in a Kubernetes cluster it's just an angular JavaScript UIs with some express JavaScript services those services are do have access to the hyperlogic fabric services sorry api and they also have access to the harmonized data store that's local and what other cloud services might be necessary to keep things cognito other things in amazon and the extraction pattern as i mentioned is is run by this data call processor and it's basically just a map reduced function for for mongo so how does the data flow the carrier data is something that we don't control right so this the harmonized data store is the data in the format that we understand this carrier data we don't know where that comes from where they keep it but we help them to build the mapping layer right so we're going to provide we provide the scaffolding for creating this output but we don't know what the input is so the carrier is responsible for doing the mapping into the harmonized data store from their carrier data so this is unknown format this is known format they use the the api to load that data into the harmonized data store they would the as i mentioned before the data calls etc are all captured in the ledger itself using simple crud chain code put get state in the world on the ledger and that's on the default channel and the when the extraction pattern runs it's going to access the harmonized data store put data into the private data collection which is shared across the analytics dash carrier channel what right one private channel for each carrier with the analytics node and if there's multiple analytics node there'll be multiple carrier analytics channels so that ledger is not visible to the default at all and the day private data collection pushes across to this node and then the the data whatever has to happen on that data to create a proper report it's basically different for every application the data calls it'll be one thing for start reporting it'll be another so that's the application pieces that's a bigger picture of that so technical architecture so we need to be multi-cloud we're using kubernetes and mongo and then there's some services specific to the cloud this is kind of an in-depth look a little bit in more in-depth there's an even deeper level of course when we're talking about all the different pieces of amazon web services that we're using to provide that but these are all the different nodes and the different channels that they contribute to and how that application so so the interaction between the nodes is all hyperlinked fabric right there's no no open check channel or anything like that if that what that's happening that's outside our application on slack or something else but no data is going across any other way than through hyperlinked fabric and here's a sort of a detailed picture of how the architecture is getting mapped into amazon this is one of the deliverables from chain yard helping us define how the amazon web services are used to to provide this to support the system okay so devbox is something we're working out as we go and a question earlier do we use managed services or just having a conversation earlier where we might create a we might decide to create a an amazon managed product right that is the open idl which includes the terraform etc so our current process is for all of the applications we're building them pushing them out to a github container registry the github actions we'll build those and make sure that they're there and versioned then terraform is used to set up the infrastructure pieces in whatever cloud is is being used we've got a bunch of credentials that need to be kept somewhere we're looking at vault for that purpose trying to stay cloud agnostic with the management of the secrets and then one of the things provisioned is there's two kubernetes clusters provisioned as part of terraform the publishing of the pieces into those clusters is done with helm and helm charts that you know get get those public images and put them into the kubernetes cluster and we're thinking thinking about using githops so we're in analysis right now and working with chain yard to decide what's the best way to make this manageable so that as we need to provide new components or updates to components what's the best way to provide that to our distributed nodes so that's the devops picture so how do we how are we addressing these particular things right we're using hygrologic fabric because it's kind of a trusted network kubernetes and auto scaling etc and and it's yeah it's very robust architecture right it's resilient recreates pods and they go down all those kind of things so kubernetes is we're depending on kubernetes for a lot of that a lot of security is built into the fact that we have distributed nodes right we don't we don't need to worry about cordoning off data for carrier one because we can't even see that database right all we have to do is make sure that they agree that none of that data has any way to get outside of their node permission right so everybody on the system has to have the appropriate permissions as defined by hygrologic fabric to even contribute to the network and of course hygrologic fabric is the only way we're getting data across the wires it's distributed hygrologic fabric supports that and that's one of the big decisions you know back to earlier question about managed services managed kubernetes service and amazon doesn't support other clouds maybe that's changed since we had that discussion but this is a very important aspect of the of the architecture we need to be multi-cloud as wherever possible cloud agnostic but if we have to do authentication differently on each cloud then we'll just have to do different infrastructure as code for different clouds and provide a way to deploy that correctly manageable as I mentioned we're going to be pushing changes to remote clouds so it we need to put in place something to do that and then of course transparent everybody who's going to use the systems you know exactly what's being put into their cloud because because we're not hosting it we need they need to know exactly what's going on in their cloud so the infrastructure as code is self documenting and then they keep that data in place again because it's a carrier node we never get to handle their data right now a couple more quick slides we provided a reference implementation running on mini cubes so you can kind of get the tires and get a sense of how things work without committing to the cloud and we'll also have a reference implementation in AWS as a result of our work with chain yard so that somebody using AWS can immediately get up other clouds are later on in the in the road now so as you question asked before maybe there's more than five slides right what is the standard the harmonized data store is not one standard but it's a standard for every use right if you have a data call that's for auto a data call that's for a different line of business they can probably use the same basic standard but there may be different ways to get the data in there and they may need slightly different things but if we're using this for different purposes like for regulatory reporting the format of the data could change so each use of this system could lead to a different standard and as I mentioned Dean Burgess is our director of BI or AIS and in charge of the data standards for OpenIDL and she'll be on a one of the steering committees for the the hydrologic fabric sorry for the OpenIDL project in Linux Foundation so that there'll there'll be a conversation about all of that over there so now we talked about the harmonized data store so how can you contribute the data models right we'll need and want very much the input of everybody using this network to share data to participate in these these use cases those data models are going to need help from everybody to make sure that they're robust and include everything you need the architecture right as we go into new clouds we'll need help building the different cloud footprints implementations of application components as they come along access and ppt access and census data the there is some technical debt in the system course that that will need somebody to do AIS course doesn't want to be the only one contributing to this chain yard is an example of an external vendor that's helping out and other vendors have agreed to participate as we get new components or if we get new organizations wanting to be part of the network those will need contributors contributors to help them get on board and of course support documentation testing all things that that we can use help this is a totally open source project all the codes available in in github and and available for for viewing etc so so what are we doing right now we're migrating from my bivn cloud aws and again with the chain yards help we're creating the reference implementations establishing those property and casualty hd harmonized data stores standards and we're building regulatory reporting we currently have an internal system that does regulatory reporting we're building pushing that over the open idl so that we can improve our footprint to make this more open the way that works all right uh okay i think that is yeah wait i want to go on on back well yeah there we go so here's some urls for um we're getting involved open idl dot org uh don't have the github the github account is to it real quick is open idl org open idl main and all of the code for all of this stuff is out there and we also have a slack channel if anybody's interested you can contact me um ken s at as online dot com and and or truman and you can go out to the open idl org to see more information about the system um and you can become a linux foundation uh part of linux foundation probably most of you guys are already so with that i'll open it up for questions last time i was hoping but um so do you have some more questions deep are you needed or uh i think she's needed we lost all right let me see if i can see the chat i'm gonna go from the bottom up hey sorry ken i'm having a bit of a technical issues here so um sorry about that um yes there were a few questions but i guess we are almost at the top of the hour so if anyone has any pressing question i would request for them to unmute themselves and ask hi uh this is raj sigamani uh excellent presentation great work um i think we are making big progress with the linux foundation slash high college fabric uh also i guess with ibm donating all of those as free open source it's really excellent i had quick question for you uh in terms of the private data collection versus channel data where and how are you using them differently right so the um the default channel actually um we don't put anything on that private data collection but i can think of the private data collection is used for the analytics channel when we're trying to share data across for reporting um so we establish a peer-to-peer channel between the the data provider and the reporting node and then the the data provider puts the results of the extraction pattern into the private data collection and that automatically goes over to the analytics node and the analytics node sees the event and then processes it that's your question uh yes it does but definitely clarify that the pdc is going on a different channel okay all right just turn the integrate uh the it's going on the the peer-to-peer channel okay thank you hi this is angel great job real quick can you just give us a little high level what what type of what does your team look like before you started this project what does it look like today and from a technical skill set or upscaling standpoint what are the areas that you had to invest in or bring in new people sure we start with ibm ibm being there i believe the originator of pipe allergic fabric can't correct me if i'm wrong i don't know the whole history i think they contributed it to the Alliance Foundation um we engaged with them before my tenure on this project to build the application uh i think they they went through a couple of iterations found out you know you don't put too much data on the on the ledger and the private data collection came on online as part during the process we started using private data collections but we had a big ibm presence for a while we've separated from ibm because certain different reasons and uh we are now um us we're it's me and a couple other folks in ais shepherding this into aws with the help of chain yard you know i mentioned them more than that i think probably could have hoped for but uh they're they're experts in and all the technologies that we're using we have also engaged with other vendors so our our model going forward is to have a very small footprint inside ais and depend on vendor partners and the open source community to build this out all right um if there are no other questions we are at the top of the hour um ken thank you so much for your presentation today um as i said in the beginning of the live um uh this session is being recorded on youtube hyperledger's youtube channel and it's available for viewing after thank you ken again for your time thank you thanks everybody for attending thanks everyone right giordi is that is that chat available um just for me to see later yes uh i have made the copy of the chat and i will be sending it to you shortly okay fantastic well thanks for hosting this was uh it was a good session yes it was a wonderful session thank you so much for your time thank you bye bye