 Yeah, you're all set Daniel, feel free to get started. So, awesome. So, hi everybody. Let me just slowly start. This is Daniel and this is Hyperledger Meetup. We're gonna talk today about like little bit on IT service management, ITSM for Hyperledger Fabric or for consortium blockchain at all. This is gonna be like more like kind of a presentation at the beginning from me. And after that, we can have like community discussion based on that. I won't share like, you know, best practice experience or probably not even like, you know, ready to go solutions. So, you might as well... Disappointed at the end a little bit. It's just actually an initial consideration or an initial presentation, how Hyperledger Fabric should be considered. Especially if you just, you know, I mean consider professional IT service management somehow with consortium blockchains at the end. So first, let me just sorry a little bit. My network is not very stable. Usually I try to slow down sometimes, especially if I feel like that my network is getting a little bit buggy and it might as well happen that I just go for 20 seconds. Usually it won't take longer than 20 seconds. So I come back and then I am pretty, I got to routine a little bit so I can continue variables. But again, so today the topic is supposing we get Hyperledger Fabric somewhere and we want to integrate somehow with professional IT service management, which are the topics that should be considered. And again, I'm not gonna give sometimes, you know, ready to go solutions, rather just raise questions. So that's gonna be the agenda for today. And I will start with the level and art of decentralization as usual. It might be boring, but I mean, I would say it's just important always to have somehow the roadmap, always to have the point of view of what we are talking about. It's just much easier to position ourselves basically in the world with that. So even if it might be boring, I just start with level of decentralization, some overview of decentralization, and then just a couple of slides on IT service management or ITIR, which is one way of doing like professional information service management, professional IT service manager. Then I get one slide on consortium blockchain applications and then I will have a couple of slides like on general management practices and service management practices of ITIL, which are, I mean, more like technical oriented and not so much holistic than other ITIL approaches. I'm more like a technical guy basically. So during my presentation, I just try to stay close basically on technology and not go very much into the direction of the holistic point of view of like ITIL for instance. So let me start the usual picture, the usual slide. It's centralized, decentralized, distributed and stuff like that. And basically as usual, so we can consider something which is a level of decentralization. So like a system can be centralized or fully centralized, something which is fully decentralized, fully trustless. And basically at Hyperledger, most of the technologies are somewhere in between. So usually they are like semi-decentralized or semi-trusted systems. But perhaps one important point of view is that so usually there are like two dimensions. We can usually if we speak about like decentralization, we think of the business logic, the application itself. So that's the first idea. If we get like a fully decentralized business application or is it like semi-decentralized or is it like fully centralized. But there are other aspects as well that we can consider. So for instance, one less well-known but despite the important topic is governance. Governance means something if you get like a decentralized network, how do we change, like the app and some parts of this app or some parameters of this app can change then how we can change it practically. So it's important to point out that if we speak about like decentralization, business logic or application itself can be decentralized or semi-decentralized or centralized as well but totally independently from that, the governance of that app, of that network can be again centralized, decentralized or semi-decentralized or semi-semitrusted basically. And this can be like two different dimensions, not necessarily totally independent but I mean theoretically, they might as well be considered as totally independent dimensions as well. Which is usually not regarded very much in like blockchain system that's operation that system operation. And I would like to point out that basically governance is not necessarily the same as operation. So like operating the system has like a lot of like very practical things. So one practical thing is like analyzing the log. So governance is usually something which is changing the parameters. It's sometimes much more on the theoretical basis. For operation we got a lot of practical stuff as well. So I would say governance is like subset of operation because of course, I mean for operation I would consider basically the changing parts of the system is part of governance as well. But if we speak about like operation or system operation there are many very, very practical and pragmatic stuffs and things that should be carried out. Again, analyzing log, taking look on monitoring and deciding if the system is okay or if it's running or not running and other things as well. So that's operation. And then it's important to point out that basically if we speak about like decent operation essentially like decent operation we can have many variation even if that is decentralized. So even if you like have like a governance in a decentralized way we can do it totally independently from blockchain or from any IT system. So just like I mean consider basically it's like a business network of like 10 universities. And then if they want to decide something in a totally decentralized way then they might just set up call for instance. So it can be something which is totally off chain. We can consider like off chain governance or perhaps even off IT or offline governance as well and operation as well. And we can consider something which is like on chain governance or on chain supported governance as well. So if you speak about like decentralization especially of governance and operation decentralization the thing is on chain governance or operation we can have something else automated or manual governance as well. So like if you got a change in a system and practically it can be carried out in a manual way it can be carried out or executed in a more automated way. And if your governance model is fully decentralized it can be even carried out in an automated and decentralized way as well. So these are all possibilities. And again, so we usually speak about like the decentralization of business logic but especially if you want to operate maintain such a business network or such a decentralized network what's even more important is the art of decentralization or the level of decentralization of governance and operation and the support, the automation which has basically for this operation. So I just slide basically to collect a couple of system based on these two dimensions. So we got here on this picture, we got two dimensions. On the one hand, we got the application level which is pretty much the business logic. So we got like centralized application on one end and decentralized applications on the other end. And we get where the, let me say business network so business blockchain network which is kind of a semi-trusted semi-descentralized way of idea. And on the other dimension I got something which is the governance or the operation. Again, I mean governance and operation are not exactly the same but for the sake of easiest, I just have one dimension. So we got here something which is a decentralized governance or decentralized operation. And on the other hand we have something which is a centralized governance and centralized operation. So I got to sell a couple of examples here. And so usually you might as well say, hey, if we got like a decentralized business logic then we need like decentralized governance or decentralized operation as well. But this is not a must. So this usually happens that way but it shouldn't work always that way especially not with consortium blockchains. So I got several examples here. We got the public blockchains for instance here. So like Bitcoin is very, very decentralized. That's an application. But if you just consider the governance and operation it is very decentralized but it's difficult. It's difficult to get the consensus on the people running notes. For instance, there's always a very tough discussion if like a hard fork should be carried out and so on. And for instance in Bitcoin this whole decentralized governance and operation is not supported by the Bitcoin itself. It should be done by, I don't know, different chats or other IT instruments or other stuff like that. If you consider like Tezos Tezos is certainly not so decentralized as Bitcoin but for instance in terms of governance and operations Tezos practically got something which is an on-chain governance. So it supports certain activities, certain changes of the network with like on-chain voting and basically on-chain kind of a change mechanism practically. So for this reason I just put basically Tezos in terms of governance and operation in a little bit like more decentralized than Bitcoin. Then we got ETU, Metidium is a little bit less decentralized as Bitcoin basically and it doesn't have something which is like I mean on-chain governance and operation and I just have one more example that's EOS. EOS, if I'm not mistaken EOS has like 21 nodes which are voted by the related groups of state. So basically I would say it's not as much decentralized as ETU or Tezos and so on. And we got somewhere here, the consortium blockchains. And of course, I mean, if you speak about like consortium blockchains then they are like semi-trusted networks. So somewhere in between. And usually the main idea is that here, I mean, we got semi-trusted business applications and then we got like semi-trusted governance or operation model. But this is not necessarily the case. I mean, if you consider the classical examples like Hyperledger Fabric or another one is like Blockchain and Identity or R3 Corda, these are actually platforms with which you can build many different platforms, many different scanners. So you can have like platforms even with Hyperledger Fabric in a more decentralized, more semi-trusted level but you can basically go and centralize several components. You can have like hybrid networks in a way that part of your network is like semi-decentralized and there are some points which are fully centralized and so on and so on. So I got to a lot of publics because I mean, usually if you have a consortium blockchain the more requirement that you would need like something which is at least a semi-trusted network for your business application but it is not necessarily the case that you need the governance or operation as well in a fully, I mean, not fully but at least a semi-decentralized way. It might happen for instance that in a business cooperation, there are, the business law is decentralized but the operational governance shouldn't be actually such so decentralized. So it makes things easier. Just giving one example which is not a blockchain example it's like the chips network if I'm not mistaken among US banks basically. So I think Daniel is just having some audio or network issues. I think he had said that he will be back in a minute or two if he does drop. So let's just give him a minute. Yeah, that was my 20 second break actually. So what I wanted to point out that basically, I mean, even if you say blockchain and that's decentralized, I speak about like business corporations but then not necessarily all aspects should be equally decentralized especially like governance and operation. It might be just simpler to getting like more in a centralized world. So that's the overview of decentralization. And again, so practically if you speak about like professional IT service management for a consortium blockchain, it is always important to decide if we want to realize as decentralized as possible or if we say for certain items, certain elements, hey, we don't necessarily, I mean, we need the decentralization for the business application for the business logic itself but we don't necessarily need the fully decentralized way of thinking for the management for the IT service management for the operation itself. Just going back like if you did, I mean, two more aspects. So things getting more complicated, of course, if we start to speak about like hybrid blockchain solutions then it's gonna be even more complicated. That's for sure. So we will see how the world's gonna develop if we have like hybrid blockchain solutions. So I just want to slide on the IT service management. So IT service management is practically a built-in that operate control, information technology, piece of softwares and hardware is practically two customers. And there are like many methodologies for IT service management. There's an evolution as well perhaps a competition as well in different IT service management technologies. So one way it's practically probably a little bit more classical that's ITIL or IT information technology, infrastructure, library, but there are other methodologies as well like the business process framework or control, objective or the co-beats that's for telecom companies probably. And then especially lately, we got a lot of like, I mean, which are partly IT service management methodologies. It's like doing everything agile, doing more like DevOps or secure DevOps, DevSecOps, if I'm not mistaken or lean and so on and so on and so on. So I just hear ITIL, which is, again, I'm not quite sure it's like more classical, but my experience with IT service management is that like hyper-ledger fabric, it's much better to think of a little bit like classical IT service management technology or methodology like ITIL and it's more difficult to integrate everything like into DevOps. So DevOps work pretty well if you get one company, couple of fronts and databases and so on and so on, but having like a multi-organization setup, then my experience that these old-fashioned methodologies suit a little bit better. But again, that's just my experience. So if you think like, hey, hyper-ledger fabric and DevOps and their journey is the best way of doing things that, I mean, just share the experience. So don't worry. So ITIL Information Technology Infrastructure Library that has many versions, it started like in 2000 if I'm not mistaken. So we got like the version one, two and three and four. And so version three was pretty compact. Version three is a little bit like more holistic and value-centric methodology. It's a lot of things which are, I mean, very important. It's more like, you know, on a holistic and philosophical level, it's a lot of things like value, value creations, value stream, how organizations should behave, how people should actually collaborate and be educated in the organization. And a lot of stuff like cost-trink, risk and utility of the service and so on and so on, which are very much important. Again, they are not so technical for me. So what I'm gonna focus on basically in the next couple of slides, these are the management practices. And I think these management practices can be found actually in any other methodologies as well. So I hope it's, they gonna like act as a good, I mean, core understanding if we speak about like, like operation or professional IT management and hyperledger family. One thing to consider and then let's just say it's usually overseen. So we speak about like, I mean, I mean, operating or maintaining or doing like professional IT service management for hyperledger fabric or for a consortium blockchain. But usually, I mean, that's not the scope because I mean, like, let's just have hyperledger fabric. Hyperledger fabric usually doesn't stay like alone in the company. You, I mean, fabric won't be enough alone for you to build up complex application. For a complex application, there are a couple of other things that should be considered. And then I just have like two other things here. So first, I mean, we got the infrastructure because I mean, fabric should run somewhere. And then if we speak of like infrastructure, we got network, storage, virtualization. It's actually like, very modern way of having infrastructure. So probably we need something as orchestration below hyperledger fabric. And I just put like local compost to virtual machine or kind of a microservice architecture. But nevertheless, I mean, this infrastructure part is pretty complex and simply it is required that we have hyperledger fabric up and running. And for a full scale application, we need usually other services as well. So let me just imagine kind of an application which has users, I mean, just directly communicating somehow with the network. So in the simplest case, we get kind of a user experience which might have like, I mean, components as UI, front end, perhaps centralized business logic or centralized business logic services, perhaps centralized APIs and other way of communicating stuff. So what I want to point out basically is that usually if we speak of like IT service management and hyperledger fabric, we should consider that and that's probably a full application that should be up and running, not just fabric. So it's much better to speak of IT service management for an application that has hyperledger fabric somewhere in between as well, which is of course probably the most difficult part, but despite it shouldn't be forgotten that we got some other components as well, below on the infrastructure side and upper, I would say upper on the user side as well. So let me just consider some management practices and again in the next like six slides, I'm just gonna list a couple of like management practices and some considerations. So from the general management practices, one thing is usually the continual improvement. We generate from the theoretical side, it is usually not so easy to realize from the practical point of view. I mean, that's my experience. So this usually means if you get like an application that should be practically somehow improved. And then if we get like very DevOps methodologies, usually DevOps say that, hey, I mean, we can even change, we can even deploy, use something practically on a daily basis. That's not such a problem. So a continual improvement is something which is, I mean, if we speak of an application side, it's something which is develop and deploy. So I would say changing the business logic or something which is more infrastructure-centric is like plan, roll out and operate, for instance. So if we speak of like hyperledger fabric, my experience is that we should somehow split, get a component like the chain code itself. I mean, that's the smart contract for hyperledger fabric that behaves more like an application, like a business application. You know, it contains the business logic. At the business logic, so I must say, I mean, business logic shouldn't actually change very often in blockchain. So it's certainly not a good idea to realize like even chain code or smart contract on a daily basis. But in a consortium blockchain, it might change more frequently basically. So the chain code part is something which is more similar to an application basically. And I would say on my experiences that at the other part of fabric, which is like, you know, the peers, the order error, the certificate authorities, the coach database and stuff like that, they behave more like an infrastructure. So even if you consider an infrastructure, that should be actually somehow refreshed or continually improved, can be a good idea to keep like hyperledger fabric on the latest release. So you got like in every three months, basically a new release, a new minor release. So if you, you know, I mean, want to do it in a very professional way, then even if like, that's a kind of fabric infrastructure, it's a good idea to just, you know, I mean, release or deploy the new fabric release, which is again around three months. And I must say, so yeah, sometimes, I mean, really then it's necessary too difficult to upgrade your fabric. But I mean, there are usually like major releases as well. So if you just want to upgrade to a major release, that can be actually painful. So these are my two considerations. And what's important actually to note that if we speak about like continual improvement, I mean, everywhere if we speak about these management practices, again, it's just important to ask ourself how much it should be decentralized. And sometimes it's not just our choice. Sometimes we can configure. So like if we have like a chain called deployment, for instance, up to a certain point, we can configure how much it should be decentralized. But like, you know, if you just want to deploy your infrastructure, it's usually the good idea if you release your new peers, for instance, for your whole consortium and not just practically for one company. So overall, if we speak of like management practices and overall if you have a point here, the question always raises how much it should be decentralized, how much it can be decentralized and how much, you know, like how much cross-organizational communication is and coordination is needed for a certain anything, for a certain something. So that's one thing. The other thing that can be considered by continual improvement, we don't just want to, you know, upgrade fabric itself. But again, this is like an application which has some other components as well. So it's a pretty good question how we can upgrade fabric with the infrastructure, with the underlying infrastructure and with other components as well, like with user interface. It is, it might be a very complicated question because like, you know, I mean, practically like network is run by many different companies. So you usually can't coordinate of the individual continual improvement processes or individual deployment processes or application as well. Another general management practice is information security. And in information security, I would practically consider two points. One is privacy and the second one is data consistency. And it's a very simple model. I would say we got privacy. I mean, we got a couple of categories. First, like in privacy, we got physical privacy, which is the channel itself. Or you can use like private data collection and it gives some physical privacy as well, apart from the fact that your hash is written into the chain which is disabled to everybody. But that's like physical privacy. We can speak of like cryptographic privacy. And if we speak of cryptographic privacy, then I mean, already there are two categories that should be considered. One is classical privacy or classical encryption. And the other one is something which is quantum secure, which is still in standardization. But I mean, my experience is that, so usually, I mean, customers ask, hey, what's gonna happen in like the 10 years with this whole blockchain system if we need like quantum secure algorithms? Can we just, I mean, is there gonna be the possibility to change or do we need a new system and basically migrate everything and so on and so on? And we got one category as well, that's privacy by policy. There's no like cryptographic or physical guarantee. People are not allowed to see certain parts of the system. And that's like, you know, I mean, hidden by the user interface or something similar. The other thing that should be considered an information security management, that's like data consistency. And again, here I mean, again, the same category. So we can have like something which is physical consistency. So there are like physical guarantees. You know, I mean, one channel basically is one big block of storing something which is not mixed by anything else. So it might be considered as kind of a physical consistency as well. We get the blockchain, a lot of cryptographic consistency. And it's, you know, I mean, it's usually the digital signing and the hash algorithms for the first run. And usually we can consider the two big categories as well, like classical or quantum secure. So for instance, in hyper ledger fabric, you use like the ECDA, that's the elliptic curve digital signature algorithm. You can even consider that there are like three, three size of key, three key size. But that's for instance, not quantum secure. That's for sure. If you consider like the classical hash functions, it's more quantum secure. So I mean, I'm not quite sure if the SHE 200 like, but like in a cryptographic hash function, you can just increase the size basically or the size of the keys. And then it's gonna be more quantum secure. That's not the case. Like for instance, by digital signature algorithms. So it's a good question or what happens if we need like, you know, the possibility for quantum secure algorithms like in 10 years, what can we say actually for the customers? And there's other, the other topic as well. I mean, consistency can be done actually by kind of a policy as well. So, you know, I mean, you get database which is right in information. And then if you guarantee that only the administrators can basically access them, then probably it's not such a problem. And what's important here in terms of information security management, which parts are basically supported by Hyperledger Fabric. So which is like an out of the box functionality and which needs some development or even perhaps research and development. So these are the information security management aspects of Hyperledger Fabric. And it's again, it's sometimes not easy just to set up basically an architecture which fits for the customer requirements. Sometimes even collecting the customer requirements is something which is difficult. So let me just continue. And that's like more, so less theoretical aspects. It's again a general management practice which is kind of a relationship management, supplier management, supplier management or even service level agreement. These are actually three different general management practices. I just put it everything in one slide. So again, I mean here the question is what is the level of decentralization in terms of governance operation and maintenance? It might happen actually that there's like one company maintaining the oil network. I mean, even if your business application is decentralized there's one selected company in your business network which maintains your network. So which creates the releases, which deploys new software which collects the log, which monitors the system. And it means basically that it's from a maintenance perspective it's gonna be just much easier. More like a classical management, service management. But it might happen that, I mean, your maintenance is fully decentralized. And then yeah, so it's usually a question how much coordination effort is required for the different processes. So if you speak about like any points here always the question is for a certain point how much coordination effort do we need? Which are the organizations that should be affected? And if there's any support how they can coordinate on chain, off chain and so on and so on and so. So one thing is always to consider like if we need coordination, how much coordination do we need? And if there's like a structured way of coordination. So like we can say like there's the ad hoc coordination we can say like we have kind of structured cross-organizational structured coordination. We can have like automated coordination but still independent from blockchain from hyper-legion fabric. And we can have something as on chain automated coordination. So for instance, if you release a new chain code there's a process for releasing your new chain code in fabric version too. That's kind of coordinated automated on chain way of delivering a change which is a new business logic in your network in a way. But that's for chain code and it can be customized as well. There can be many activities for that. There's no on chain support. There's no even automated support. It should be coordinated ad hoc and it might have actually a lot of efforts. And one question that I actually I don't know if it's possible or how it's possible if there's a way of define a service level agreement. I mean, sure if we just change back to this topic yeah sure so we can have like service level agreement for the individual infrastructure but especially this part which is hyper-legion fabric this is like multi-organizational. So I mean, there might be like ideas that I mean each is in one order. Note for instance and defining kind of service level agreement for that ordering note because otherwise the system stops but it's difficult. So I would say especially for this part defining like service level agreement can be challenging and the problem is that basically this is like core component of your business application. So as core components I mean for the core component you can't define the service level agreement. It is questionable how you can do the same for the whole application. So again, this was like a question if service level agreement can be defined at all in a meaningful way. Let's have the next slide. So again, it's like the change management. So the classical way of thinking like change management we get like items that's called configurable items that can be somehow configured and then we just change these elements. So like we got the router, we got the new settings on our router then our configurable item is the router and if we just I don't know install a new firewall rule to our router then that's a change on our router practically. And then so usually if we have like containerized application this is like partly automated because I mean if you have like Docker then the part I mean part of our code, part of our infrastructure is already coded, so already programmed. So it's just different and it is usually not so much considered that we have like changeable items or configurable items that should be changed actually somewhere. And in change management the other thing so basically we get like configurable item that is subject to change and then if we change this item then usually we should consider something which is an impact. So if you get one like negative rule on our firewall for instance which is a change then practically it might happen that the whole application goes down which is actually a pretty serious impact. So the question is how like such a change management can be defined in Hyperledger Fabric and again the question is if it's like centralized or decentralized user usually it is decentralized and then the question is how much it is decentralized. Usually it requires a multi organizational coordination effort for a change and it's question how much it should be actually decentralized or not decentralized. And I would say it's important practically if you just list actually make a list on all of our configurable items, all of the items that are subject to change and then just identify which are the items that need actually some multi organizational coordination effort. So for instance if you have like your channel and you want to upgrade basically your channel properties like you want to have new blocks not in every two seconds but in every three seconds it is certainly a change that requires multi organizational coordination and if you have like several channels, the same channel practically. So that's I mean that's simple or it's simple to see that you need the multi organizational coordination. For instance if there's like I don't know 11 companies and each company is running at order or let me say we have like three companies and then each company is running like one order at node then basically if you want to just restart your orderer at your company that would require some organizational coordination as well because if you just shut off your order service, sorry, if your order service is decentralized and if you shut off your orderer then practically the whole system hold on. So this is something that should coordinate with other companies as well. And again I mean the level of automation is pretty much questionable if you get like on chain or off chain support or if you get some other support as well. So the next one is something which is identity and problem management or incident and sorry incident and problem management. So usually it means that something goes wrong with your system. You get an error which should be somehow identified for instance by monitoring. There's usually kind of an analysis which might be a root cause analysis that there's some solution that solves somehow this problem. This is usually the change management. So on the left side and it's a good idea to have somewhere database on such incidents. So like if it happens again then it will be much easier to solve. It's kind of knowledge database on different incidents. So that's like incident and problem management. And again, so it raises several questions if you want to realize in a decentralized way. So the first question is how do you want to, I mean monitor your system basically. You can monitor the individual organizations but then it's gonna be tough to coordinate and collect the monitoring result or you might as well say here we just want the dedicated company that monitors everything. But then practically you centralize your whole operation. And again, the question is analysis that requires some coordination effort as well. We just covered change management in the last slide. And again, I mean this knowledge database is usually a good idea. If you want to do your maintenance or operation in a decentralized way then this knowledge database should be decentralized and build up in a way that like no secure information is shared with other companies. So it might... Looks like Daniel dropped again. If we give him just a minute or so, I think he'll be back. So this was my 20 seconds break. This 20 seconds break, but let me just continue. So again, if you have like independent companies and the independent companies having like it's on IT service management best practices then it's a little bit questionable how this whole process can be integrated with them. So let me just go through a little bit more faster or a little bit faster on other aspects as well. So in terms of IT asset management, IT asset management, that's usually your components. It's important to constantly like individual components. Usually you have something which is a shared component. In Hyperledger Fabric, you don't have like shared components. So shared component is for instance, if you have an infrastructure which is used by many different companies. So you don't have like the classical shared component. Components what you have that's, I would say it's called replicated components. So these are like independent components but they are strongly dependent with each other even if they are physically different. So again, like you got free companies, free not ordering service, then of course the one order and all this runs only at your company, but despite that's like very strongly dependent on other ordering service as well. And it should be maintained and released and upgraded together with the other orders or orders as well. And one big question is, I mean who's responsible for which part of your system or application that's again something similar as service level environment and it can be actually tough. So in terms of IT asset management, what's an important thing and it can be actually planned that's your component lifecycle. So I would say these are the topics that should be considered like the lifecycle of your chain code, which is more like actually, I mean business oriented. So it's the business logic. So basically business will drive somehow the changes of your chain code, but you can consider the lifecycle of your fabric components, which are the major and minor upgrades of hyper ledger fabric. One thing which is challenging a little bit as well, that's like the lifecycle of cryptographic elements like at the moment, we got like keys and certificates in hyper ledger fabric, but perhaps in a future, we got like decentralized identities and I don't know, zero knowledge proofs and other things as well. So it might be even more complicated in the long run. And of course, I mean one asset that can be considered in the lifecycle model. Again, these are the like the cryptographic protocols and I especially mean on the one two thread, which is again, not relevant at the moment, but perhaps in 10 years, it's something that should be considered basically. And of course, last but not least, there are some other components in your application as well besides hyper ledger fabric. So let me continue. That's the next one is monitoring and even management. So we got like good monitoring tools, basically for like containerized applications, you can very easily integrate with hyper ledger fabric, it's like Prometheus, Grafana, Kibana, with some effort, you can even bring like Nagyos up and running and so on. So we got good tooling support or what's missing practically, I think I would say that these are two things. One is there's no like community best practice, what to do with certain logs and metrics. So there's no like proposition that, hey, you see this log in your ordering service, then that should be an alert and then there should be an email to an operator because then something very wide is going on. And if you see the other event or other log, then nothing should be done basically. So what is missing a little bit, I would say such a community best practice, it's certainly something that can be done on the long run. And of course, I mean, the question is here as well, these are tools which are, which work very good at long company, non-organization, but certainly speak of the organization setup here, if we want to do monitoring and even management in a decentralized way. So then how do we integrate like the different independent Prometheus, Grafana and Kibana stuff in a decentralized way with several organizations? How do we collect logs in a decentralized way, for instance? How do we manage alerts, for instance, or events, or who's gets the email is if something wrong happens if we speak of like a fully decentralized or semi-decentralized maintenance operation. So these are hard questions basically. Or for me at least. Then we get something which is like release management and deployment management. I spoke, I covered these topics. So I'm just covering very fast. Again, here is, I mean, I would consider that we get like chain code, which is like a replication. You might as well have some client components as well, especially that are communicating with gateway, for instance, these are more like applications. So they having like the release management and deployment management ideas, similarly as an application, apart from the fact that usually we like a multi-organizational coordination for this one as well. And other stuffs like PRCS, orders and code TVs, these are more like infrastructure oriented parts. And of course the question is, I mean, we don't want to release hyper-legend fabric. We want to release the application basically. So how do we release, how do we create a deployment and release management in a way that both fabric and non-fabric components are covered with that? And of course, last but not least, the question is, if there's like five companies, each having basically a general release management and deployment management process that are different, then they're different from each other. Then how do we put actually hyper-legend fabric in the middle and define a meaningless release and deployment management process in the middle? So the next one is configuration management. I just covered a little bit. It's practically the change management. I would say what's important in configuration management, apart from the change management perspective, that's kind of a CMDB. It's a configuration management database. And I mean, lately we got all of our infrastructure or most of our infrastructure practically in code. So this process or this CMDB is usually overseen, but I would say that's kind of an important thing, especially if you have like a big infrastructure. I mean, even if like in Kubernetes, you don't necessarily get everything from POT history, especially not if you work like with hyper-legend fabric, because you get a lot of changes which are like, if you just change, for instance, the channel property, like increase the channel timing from two seconds to three seconds, it's not such a change that is mirrored, like this is manifested, for instance, in your DevOps environment very easily. So I would say it should be an important thing to like have a history of the configuration items that's changed basically. And then it can be like local shared or replicated CIs based on the impact as well. What's practically important to consider that this CMDB partly should be available for other companies, for other organizations as well, because for efficient error handling, you just need to see what happened in the other companies' blockchain network as well. And that might actually raise some serious privacy concerns as well. And one more thing is like, I mean, that's the most user-friendly part, that's like service desk. So it's a good question if you get like a consortium blockchain application. It's definitely just for hyper-legend fabric. Then how do you, the two easiest approaches or logical approach, you get the several organizations and then each organization having like a service desk probably for other applications as well. So practically each organization having its own individual and independent service desk. That's one way of doing such a thing. Another way might be that we got like, I don't know, food supply chain application, which is run by several organizations, but despite we just want to define one interface for the end customer. So we got one service desk practically, even if under the hood, there are several organizations in the network practically. So these are the two easiest examples. Things are certainly more complicated if you get like classical service management, because usually you don't get like just the service desk and the fabric network, but you got like the people usually like service desk that's kind of first level support. There might be like second and third level support as well. So at each stage basically you can decide if you do it like in a decentralized way like this one or a more centralized way like this one. So since can be actually pretty messy, there can be many combinations and then it's usually, I think it's usually the best idea just to consider the possibilities and choose one because if you don't consider these things and everything is running like in a network way, then there's gonna be chaos at the end. So I got one slide that's conclusions basically, and then I finished my presentation. So my conclusion is the professional consortium blockchain like hyperledger fabric, operation maintenance and governance can be basically challenging due to several factors. I mean, one is icing the service and the application complexity. That's certainly one issue. I mean these systems are only one hand open source on the other hand evolving very, very fast. So they are usually much, much more complex than very classical applications. Then we got a lot of cryptography and this money is, I mean, it's moving fast. So I mean, the next wave is zero knowledge proofs and I don't know ZK rollups gonna appear practically probably in systems like in a couple of years time then these systems gonna be even more complicated and complex for maintaining. So there's a very fast moving cryptographic research and development then what's making situation very problematic or very, very difficult is that we get a multi organizational setup. And especially if these organizations are enterprises with different standards, with different best practices, with different management IT service management practices, then things can be really challenging. One thing is that usually there's, I mean in most of the blockchain systems, I mean, the design goal of simplicity or simple operability is not a design goal. I mean, I've never seen such a system where like, yeah, let me do a blockchain that can be operated or maintained in a simple way. That's usually not a design goal. That's like priority 20 or something. And of course, still there's no industry or community best practices. It might be evolving on the long term. So actually, I think as a conclusion, but I mean, again, you can disagree with me. I mean, it's not a problem for me. More community best practices and share experience would be needed for hyperledger fabric and actually for other consortium blockchains or distributed applications as well in terms of like professional operation and maintenance. So that was my presentation. And I just finished it. So I'm open for questions or I mean, for discussion as well. And let me just actually go through all the questions if you have like question, I will try to answer. But in the meantime, if you have question, I mean, just or comments or practically, you know, I mean best practice experience to share. I mean, you can just unmute yourself and just go ahead. So basically, it's like, I did meant something which is ready and industry best practice. I meant it basically as an initial presentation to raise awareness and then have like more, you know, community call below the YouTube screening as well. I think we're gonna email every participant with the slides as well. Yeah, so it's a good question how you can get like more information on the topic. So you can have like IT experience basically. Okay, so I've chosen like IT as one example for professional IT service management. It might not be the best, but it's my experience that it's like better in terms of fabric like that another like, you know, very DevOps approaches. But again, you can argue with me. So if you're interested in IT then basically you can just browse on the internet. There are tons of books, a lot of like, you know, freely available, you can download them and so on. I covered from IT, the management practices which is like more technical oriented or not so far from the technology. But in IT there are like a lot of, you know, I mean, holistic approaches how your service should be defined, how the value of your service should be defined, how people should cooperate basically in your organization to have like the most value for and customers and so on and so on. I just didn't cover these things. I tried to be, try to, and in terms of hyperlegia, I'm not quite sure if there's like, you know, so there are a lot of meetups focusing on how to install your hyperlegia fabric for instance or how to set up in an easy way like for a development environment. I'm not quite sure how much, you can find some meetups online recording as well for like planning something more professional as well. Yeah, yeah, exactly. I find this as a good example. I mean, I usually say that basically if it goes that direction then, you know, I mean, such a consortium blockchain system or even hyperlegia fabric can be as complex on the long run as SAP. I mean, at the moment you don't have so much business logic inside, but I mean, if you consider that you have a lot of like cryptography as well, so on the long run it might happen that basically, you know, I mean, I mean, fabric is basically a framework with which you can build up many different structures and networks. So on the long run it might reach the same complexity as SAP. And then of course, yeah, you need a lot of like best practices, how you can do it easy in an easy way, in a professional way, in a more professional way. And of course, yeah, it's a lot of complexity, of course. So again, if you have like anything, any questions, any ideas or best practices or even if you, I mean, disagree with me, I mean, it's not a problem, just go ahead. I mean, use the chat or you can unmute yourself and just go ahead and ask it. So I'm just reading the comments. If you want to, I mean, if you don't have experience with hyperlegia fabric, then of course, my presentation was practically not necessary, very useful for you. But so if you want to run your first network in a development mode, there are a lot of good articles, basically a lot of good tutorials. So it's not so challenging. If you plan to go live with like five, 10 organizations and then maintain for the next 20 years in a professional way, that's the way that I was more like considering in this presentation. So if there's no more question or anything that you would share, then I would say, I would thank you very much for your attention. And then this presentation will be available on YouTube. Again, this slide's gonna be your participation and attention and then, well, see you next time in the next meetup. Bye-bye.