Panel - Decentralizing the Enterprise: Getting Started

Thank you so much for your, for your remarks. It's great to have both of you here together. The first question I like to start off with is from an enterprise perspective, why is decentralization important for delivering services of our software? We can start off with tele first and then how you could follow up.

Yeah, I, I think the problem with dig digital platforms is that we tend to become highly concentrated. And if we have some kind of winner at all mentality, and I think collaboration is really difficult in that environment because no one would like to yeah, become a member of a platform of a, of a concentrated platform. And that's why I think decentralized software and systems can allow collaboration between different competitors and what you can see, especially in their identity stack in Germany. You have a lot of, yeah. Identities, schemes already, but there's not enough traction on it.

And I think the problem is that the companies do not trust each other. For example, commerce bank. If we would like to join an initiative that was started by, by DOR bank, it's difficult if, if we would rely on yeah.

On, on the platform, but is completely under control of our competitor. And in, in that sense, I think it's, it's, it's possible with a decentralized system to allow collaboration because you do not give to give away your, your customer data and you, you at least need little trust on the system. You do not need complete trust.

You need a little trust that the technique behind works, but whether it's broadly trust, whether it's working in that kind of system and where I think decentralized identity systems and software can help to collaborate between especially smaller companies, if you are not a hyperscaler and you can compete with a high hyperscalers with yeah. With collaborated and decentralized software systems. Right. Harry. Yeah.

So first of all, that's actually one of key benefits of decentralization that you can essentially switch the platform game from being a almost predatory centralized platform game to a more cooperative model. But if you look at it also from the market side now, in terms of the needs, PLA decentralized technologies, they don't work for everything. So where do, where do they really give you a bang for the buck is if you got fragmented ecosystems.

So if you got a lot of players and if the customers essentially is faced with similar offerings or complimentary offerings, for instance, in urban mobility would have such a case, but there's a lot of players here. And in order to deliver a seamless customer experience to your end customer, you would now want to combine the services and the capabilities of many players in this game. And if you think about how to do that, that is truly where decentralized technologies bring the value.

If you have a value chain that is vertically oriented and those still exist, so it's more or less one big or two big players, and they have most of the vertical value chain under their control. I would not recommend you to go decentralized. It's all a matter of what's the appropriate, what's the appropriate problem statement here, Right? So now that you have tackled the why, I think it's, it's it's time to, to move into the, how so, how can companies get projects associated with decentralized technologies off the ground? Is it by being part of a consortium? Is it going the independent route?

What's the best way to move forward, Harry? Well, it's, it should all of this because usually companies do not, you know, think about where do I join a consortium or do I do on my own? It depends on what is the need here. And so first of all, companies need to familiarize themselves with the concept of decentralized platforms. It's not an easy concept to understand if you haven't been socialized by working with it. So there's quite a steep internalization curve. First of all, wait a second. What are you telling me here? You're telling me here, I shouldn't onboard my own customer.

What I always thought my master data was my most valuable piece of information. And now you're telling me no, no, leave that to them. They do that better for you. They just sign off. That's all you need. Whoa. And then you telling me now I have to work together with my competitor and share supply and share customers with my competitor. What exactly are you talking about?

So that's, I believe right now still the mentality is the biggest problem. And then of course the technology stack is very, very new. It is actually from a software software man. So once you understand it, it's actually easier to program than existing stacks, but it's extremely hard to understand they're learning the entry curve is steep on the understanding the concept, right? It's much easier in programming, but you need to first go over the first bridge. So there is still also here. How do I adapt traditional business to a technology that was completely con invented with a different mindset?

And the one big advice I have is do not merge too much legacy with this new world. Start with Greenfield start where you can reinvent the world and start from scratch, do a segmentation or a charting of your customer segment of your market, whatever, but go in where you can really use the benefits and the efficiency and the leanness that these technologies bring. And don't contaminate it by forcing these very new, very powerful technologies to do something that legacy systems were built for, but that completely defeat the purpose of how these technologies are built.

So try to, if you piloting, still go Greenfield as much as you can, Right? Yeah. I completely, I completely agree. Maybe only a few sentence to that. What I would recommend everyone is to, to set up a dedicated team for it. So a DLT team and maybe separated from your main organization, but I think what Harry mean. Yeah. Do not build on legacy systems. So it should be somehow separated from your main organization from IQ organization, but somehow they connected to it so that you can give feedback how it works and everything, and yeah, you should start really early engage with the community.

So, and yeah, try to, to try to speak to as many decentralized identity specialists and companies through your competitors, maybe about potential use cases over technology itself and then yeah. Engage in a cons. I think it it's, it, it doesn't definitely make sense to, to engage in a cons and not build on, on your own media, on, in a, in a prototype it's okay. But if you come to a pilot or something like that, yeah, you, you should do it in a cons approach. Right. Great views there. I think that's synonymous to what we at coping a cold believe.

You know, we believe in even the starting line and we're trying to get as many people as possible to learn about decentralized identity and decentralized technologies moving forward. I think a common theme, which regarded the questions coming from the audience is centered around theor particip structure. So how can different parties come together? Competitors?

Like, for example, you just alluded to it. How can they all come together to engage in common activities and work together Ville? I think it's, it's mostly driven by yeah.

By, by centralized platforms, to be honest, because a lot of our coming back to our identity stack because I'm highly involved in, in, in that use case, the main reason why we come together as competitors is because we has a lot of pressure from yeah. Centralized platforms. So in the identity stack is Google it's Facebook, it's it's apple. And if we do not react, we build the, the identity centralized platform and we have to play where game.

And that's the reason why everyone say, okay, we have to stick together, find a way how we can compete because no one of us can compete with that kind of competitors. And that's the reason why we, we work together in, in the cons. And I think that applies for other use cases as well.

And other, other cos as well, Right, For me, coor is one possible manifestation of this. So as far as I see it, consortium is one nice approach. I do know the one or the other consortium where the incentives are set wrong. So if a consortium then starts to want to live off the membership fees and sees that as their prime source of income, you were setting the incentives wrong. And that consortium is ultimately probably not achieving that. What brings people into the thinking for consortium? So I would prefer calling it a community building rather than the specific legal structure.

Is it a consortium or is it whatever? And there's in essence, there's two levels to this, the easy one and the difficult one, the easy one is as long as you're developing joints, it's relatively easy to collaborate on the development side. As long as you keep in mind, one golden rule, any protocol and by protocol, I mean, exchange of data, any protocol must be open and democratized from the very beginning, you can all bring in your, your intellectual property. You close source, that's all, okay, that's all acceptable.

But if you start collaborating with other people, which means you got data being exchanged and that's, what's called the communication protocol, you need to make sure nothing in these protocols is proprietary. They may not be contaminated with patent licensing or whatever else. And as long as you stick to that rule, then in the development phase of your collaboration with the community, you have very little overhead, you've got very little fear because the entry barrier in the exit barrier is non-existent, it gets tricky. And I don't see a single consortium that has solved that problem.

Yet it gets strictly when you go into the operational mode, because then we in the money level of things, right? So now it's not, oh yes, we are friendly. We're collaborating now. It's I want it's money. It's legal. So how do you build an organization? Be it a foundation, be it a cooperative, the German word could be the, or be it a consortium, or be it a joint venture. And how you structure the governance for the actual operating entity. That is a much, much harder thing to do in Germany. Say it's a much thicker board to drill.

And again, that has not yet. I had, I do not see any successful approaches for that, but I do see things like the shifting. I do see things like cooperatives or things like, I don't know that are closely related to the German G Shafton emerging. And I see on the other side, that coor need to beware of one thing of closing the doors too early, or setting the bar too high, because I do know the one or the other consortium where that is being done. So they be, they are very open minded, very friendly in the beginning.

And then after a certain time, basically they start going to the enterprises and saying, we need higher membership fee, blah, blah, blah. And by the way, the standards that we're developing, we're not gonna publish those anymore. We keep them in the locked in the consortium, which defeats the purpose because you want this standard, whatever you're developing to obviously go out to the worldwide because essentially any of this game must be thought of as international and basically seamless. Absolutely.

I think, I think we can all agree that democratization of information is the key element for the success of consortium moving forward. Now that we have tackled the why and the how I think it's, it's, it'll be best to, to focus on the who. So who are these stakeholders that are to be involved in getting decentralized projects off the ground. And also if you could perhaps elaborate on the skill set required from a team perspective to get such projects running Harry.

Well, from my perspective here, you need you always in the market. So you always got very simply put, you got your supply and demand. So you need enough. If you're in the ecosystem world and in the decentralized world, you are more or less always dealing with ecosystem approaching, make sure your ecosystem has enough supply. Make sure your ecosystem has enough demand.

I mean, that's trivial from a platform economics perspective, but if you look at the capabilities that are needed, you need definitely to look at it. Not only from the corporate level, you need enough players from the corporate supply and demand, but you also need to bring in the tech community. So those people that actually fuel it with the creative power, because any of the technologies we're talking about here was developed essentially by very young hungry tech companies or tech people. It wasn't developed by corporations. Let's not forget that.

And then if you look at some of these consortiums, you know, you don't see that represented, especially then in the operating phase of things. So the advice is keep the community balanced that you make sure tech and open source community, bring those into your ecosystem because otherwise you will grow stale very soon.

So that's, that's a piece of advice that I would have. And the rest depends very much on your business case because let's not forget one thing. Identity is not primarily a product it's like your ID card. Nobody makes money of having an ID card or verifying the ID card. It's a necessity in order to make business, but it's not a business objective on its own. And that is also needs to be born in mind as we basically structure our ecosystems. Think of what's the value added service because it's except for very dedicated, very specific operators. The value added service is not in the identity.

The value added services need verified identities, Fascinating insights there, Helga. Yeah. Coming back to the skillset and maybe to add what I think is important to have a team that is open minded for new technologies, and it should not be your, maybe your it employee that works 20 years or, or more in yeah. Legacy system.

So it, it, it really should be a really a young open-minded team. Not saying that there isn't a 20 year developer, but in most cases, I think it's, it's, it's, it's more of a younger teams and team should not only comprises of software architects and software developers. You really need business developers and also legal experts because what, what we learned in, in the past is that the, the software, you can really quickly developed software, but to at the end of a day, to develop all the processes and to get it legally compliant, that is really the hard work. And that takes a long time.

And it's really, it's really important to have legal experts and regulatory teams in place where they're able to yeah. Evaluate solutions you create and that are yeah. And better open to yeah.

To, to find a solution for the regulatory part and with the business developers. What, what I observe is that sometimes our software developers are not so open when it comes to collaboration with others. So the business developers sometimes are more open to discuss with, with other companies, maybe with other sectors that you need someone who can really create this community approach. And that's where you, you definitely some, some business development. So when you set up a team, it should not only be a tech team, don't forget regulatory stuff and the business stuff. Perfect.

Harry, do you have something to say, yeah, Yes. I have something on the regulatory part, which is very, very important because rule of thumb, the moment you are a regulated entity, you become slower just by nature of obliging with the regulation. That's true. So as you build your platforms, try to segregate the regulated part from the non-regulated part. So as in payment, you basically outsource the regulation to your payment provider.

As in KYC, you outsource the regulation to your KYC provider, which allows you to go ahead much faster, because you're much freer in your execution, much freer in your decisions. So what you should do also, as you start dealing with decentralized ledgers or decentralized identifiers, make sure that your key business is segregated from that. And that's exactly the beauty of it, of the protocol economy.

You consume this regulated services based on very simple APIs, you keep your business system unregulated because the regulation is handled by the trust providers who provide the verification of identity, the verification of credential who provide you with the payment, with the access to the central bank systems, et cetera. And this is also a nice part about in the case of identity where leave the regulation to those that actually touch the identity and then consume it as a paper use service, pay them for having done the regulation.

And then you, as a business system, you can grow your system so much faster rather than because you are not obliged to fulfill the necessary reporting regulation, compliance rules that anybody who touches identity, anybody who touches payment will have to do. Right. So it's great that we, we address the elephant in the room, which is regulations and regulators on that note, I would like to thank you, Harry. And Helger for this fascinating panel discussion. I'm sure we're going to see a lot more decentralized initiatives running in the coming years.

And I hope to see a lot more of this happening. Yeah. Soon. Thank you so much for your time. And we look forward to hearing from you soon. Thank you, Raj. Thank you. Yeah. Thank you. Thank you. Bye-bye.