Yeah, and I'm actually gonna broaden it a little bit. So I'm gonna talk a little bit about feedback in general, not Oppa specific. The reason for that is that I sit on the experience what from the both Thesal side and Oppa side. So I spent two and a half years at Tyra implementing opa and I spent three and a half years before that at Amatic selling and implementing Segmental solutions. So between the time I've seen 50 to a hundred project going into production and not going into production and I'm gonna tell everybody why best practice dough, what you're gonna do, what you're gonna look for and what you're gonna avoid that study. So it's gonna map in a lot. I hope to what William has said, or sorry, Greg haven't said, that's ID at least, so we'll see if it comes to the same conclusions.
I'm mainly gonna stay here I think. So first of all, a little bit of on the market, if you look at the market up on the left, it's not really on the size of order or something, but normally I would say we should start with SML because we owe it. All that works in PKC to the sacrament guys. If Barbach and Eric wouldn't have sit in a small room somewhere at the Royal Institute of Technology for a few years writing the sacrament standard, we wouldn't have the feedback world have today. It says that. And then for a while, not much happened. I remember working with Sacl, a lot of the discussions you had and mainly on the I Dental and access management side was okay, what is the capital authorization, what is policy based? What's the benefits of it? So it was not really tailwind, it was really building a market for the first five, 10 years, I guess probably more five years.
And then commanders plays like next labs focusing on SAP and some plm, more verticals, plane ID and symphonic enter the market. To be honest, not much change. It was the same thing. We are talking to the same people. We are talking to people who have big companies, legacy applications and then Kapa and OPA was a game changer. Not that the technology is so much different. If you look at an architecture picture, it's similar. There have some differences, but the ID with UPA was that it was targeted on developers and that was the big game changer because when I was working for Tyra and talking about upa, I never explained what DEC capital authorization was. Was the benefit was for the policy was was the pep, was was the PDP one. Everything was more or less clear because everyone I talked to were already using more or less, but on a very tactical level and that's what I come to champion.
Normally when we talk swell, we talk more to identity people. During my time with opa, I have more or less not met an identity man. It is more that you're talking in the beginning to developers. The issue with that is, as I said, developer are tactical people, they have an issue, they solve that issue and in the next sprint they have another issue. So it's not that they're looking for consistent policies or code and things like that. And if you remember, if you go back three years, the ID was we gonna go, I we're gonna go DevOps, we're gonna give the developers every tool they want. So if you want to GitLab or someone wants gi, someone wants zpa, someone wants sbar, give them to it. Of course that didn't play out and that's what we've seen for the last two years as see is return of the enterprise architect, the secure architect, and they are the key players because you need to have consistency.
As Grahe said, consistency is the secret source to policy-based access control and you need to reuse. I'm gonna get back to that. We also see a couple of different purposes that are valid. There are different because compliance, in some cases, people don't have a choice. They need to implement some security roads. Normally it could be export control, compliance needs compliance like your regulated by the American defense or something like that. Or you have some GDP or open banking. Then you can take on rather complex things, rather complex project rather costly bank the project and still land them. But that's not the minority project I have seen there are less than 10%. The big thing is the people are looking for efficiency, reusing code automation, getting software outta the door faster, fixing fault the software faster. That's where we see the big use of policy based and that's the case I always look for.
And if that's what you're looking for, you should look at policy based access control because if will give significant gains. The other thing that comes of that is architecture. Of course when we all started with this, there were not cloud native. There were maybe some microservices, but in the beginning it was legacy applications and trying to retrofit a feedback solution to a legacy application is a little bit like open heart surgery, avoid it's the world and if you need to do it, you do it, but avoid it at all costs. If you can change your diet, if you can start exercise, do something else, do that first. That's that's main One of the most important I would say. Then comes to other thing, the architecture. Mm, okay. We have a legacy. Anna Graham said we're gonna move that to the cloud. We're gonna have a modernization project.
I've seen at least over 50 big modernization project in big banks, insurance companies everywhere around Europe. Very few of them actually are successful, is not due to the feedback. The good thing about them is they're extremely well funded. They have like 50 to a hundred million euros in budget. The issue is that when it comes, they always take time coming off the ground. They always take, run over the budget, even if it's a high budget, there are always the big assets involved and feedback is a small, small piece. So normally what you see is that they fail before they start or they take extremely long time. So moving something legacy, either you just take it as gram and move it to the cloud in a container and now it's cloud-based. It's the same thing but it's cloud-based so you can tick in the box, but if you're gonna break it up in microservices, I would re rewrite a software instead breaking air because breaking up an existing application in new microservices, I don't see as, I don't see that happen successfully. The other thing when you come to is also consistency is enforcement. You know the model that we talk about, we talk enforcement, we talk decision, the P2P and we talk data. The P enforcement is one of the key things that people spent too little time before. Everyone to our policies before you should talk enforcement because enforcement will happen in many places. And that comes the policy distribution. You need to figure that out and there is the tool helping you a lot.
The best way is of course if you can use a gateway, if you can use Eastern, all of these new technologies, then you can have consistency. Kong even have embedded paste today and I know other one have a corporation with matics and things like that. So all the gateway players are very, very good solutions. There are, I didn't write that up. Some applications are starting to have APIs for external authorization, not money, but they are a few ones. So if you have them, use them writing custom pips, avoid if you can. In some cases you can because you, you need, you need to do that. We go back to the compliance play, then you might need to do that. And also it's good if you come to a blank sheet, of course you never do that, but it's much easier to do it right from the beginning, then start cleaning up well after you have built a house more or less. So that's the other thing, when you're doing a blueprint, start to do this. The issue then is do you see the ROI from day one? No, the ROI comes a year or two later because the ROI is not based so much on build one reuse. It's come from cost of change and cost of audit is the big ones that we have seen.
Then comes policies. Everyone I talked to before said, okay, policies are complicated. Mm. I would say no. And yes, policies are complicated, but the complicated part is where the fist fight happened in Australia is getting them in plain English or Dutch or German or Swedish. Write the policies down. That's the complicated part. And agree on the policies. That's where you will spend more time than you have expected if you don't have them written down. Some people, okay, well we have their security or we have our compliance, fine. Normally people haven't done this job and think, well of course we have a lot of policies, yes, but they are conflicting. So that's why you would need to spend more time writing policies. Oh, rego is complicated. S I don't want to write that kind of policies or, or things like that. When you talk to people a year later, I said, okay, how hard was that?
Not at all. A good developer picks up rego in a week or two weeks. It takes a little bit long to master it, but we're talking weeks. No one actually want to code pure SACL or XML coding. But you don't know that you code alpha coding and it's on par more or less with Drago. And you also have UIs that can help you. That said introduction, I don't see so much as UIs being used for policy creation. I see more actually developer writing code and that's also that authorization. Is it an identity, is it an security or is it a development? And that's the hard part of authorization. It's everything. It's a combination of identity, security and development. And we all need to work together. So that's the thing. Don't think so much about policies. It will sort out, think about how you gonna write them in plain English and also think about the distribution because that's the key.
Because you will not probably have the same policies in all of your, in this case, OPA or PDPs in the microservice environment. So you need to have some automation there and here there are tooling that will help you, that tool. That's actually all the toolings are already good at that. I would say the other thing is lifecycle. C I C, the pipeline. You're gonna treat poli. This is policy as code, so you need to treat it as code. And they've been debates should you have this kind of tooling inside the ui, inside a tool. Everyone tells me no because we, everyone has a policy lifecycle and they want to reuse that one. But you need to have a tool that can integrate bid that has APIs that can integrate with the current pipeline. That's crucial because otherwise it'll never fly.
The other thing is policy. A standard I knows is standard UPA is not, people don't really care, to be honest. UPA has a larger adoption. But yeah, tomato, tomato I I, I wouldn't say is a big difference there to be honest. Then comes data that two type of people, one people don't really care about data, they should. Data is the complicated part. The other one says, well we can't do feedback because data quality is bad. We need to clean up our data. That's also the wrong id. You don't, don't clean the house before the party in this case because you don't know what kind of data you're gonna need. The policies need to dictate what kind of data and you need to start to work that way. And then implementing data and you're gonna spend much more time on the data side than you expected because you need to convert the data into the right format. You need to find the data, you might need to clean up the data or you might not have the data. You might need to create the data. Something like that. That's where people have told me they're spending more time. And Harold also is a, where I see a big difference between the two technologies between SMO and upa. UPA is greedy with memory.
Tyra has come out with a new paid version that is less greedy but still greedy. Everything you put in an UPA comes in as a file. That means if you put in 100 megabit of data, they'll probably grow to gig. And if you're gonna have it distributed, so you have 10 or 20 plus, it's gonna consume a lot of, a lot of memory. On the other side, SACL isn't really built to cash data. It's built to fetch data. So you get the downside of course, or more latency. So that's the game you have to play. That good part with Sacl is that it has more pre-built connectors. Upal doesn't really have that assert and permit are solving this permit with Opal and some other things. So there are solutions in open source that's due to the open source. There are other contributors as well, but that's one of my main message here.
Spend more time to prepare for the data side than expected ui. We all like nice ui. Is it important in the POC phase? Yes, very important because you can show people that are not real, understand how it works. You can do demonstrations. You, you can teach yourself in production. Not as important as you might think. Automation is much more, APIs in the UI is much more, if you can't automate the testing, the policy distribution and approval things, it'll not fly in a modern, in a modern organization. So that's the other thing. Use the UI to show the organization and there are better reversed UIs, even if I see everyone's coming up a little bit on pad there as well. But make sure you can automate, check the APIs before you start implementing a solution because this is what we have seen. People rather late in the process realize that they can't do that. And that's extremely costly for them.
That was the automation. V comes to adoption and as I say, UPA changed the world a little bit because before that we had, we had some people U using other technologies, but over a year or two, we say millions of downloads, thousands of people using upa. UPA is not only used for applications. I I talked to here mainly application access control. On the open source side, I would say 60, 70% is used more on the infrastructure side. Kubernetes submission control. Thanks for that. And less is used on the application side, but it's still, it's still a big, a big chunk of workload out there running. I see. The thing with adoption is not really, if you compare technology or something like that, the thing that I think stops us in adoption to adapt faster is the lack of expert services. Still a new way. Still hard to find you if you go to Accenture and say, I want an expert on sacl, I want an expert on upa.
They have, but they don't have money. And if you go to other companies, they might have won or two nowadays, a few years ago, they have none. So it's not like if I'm gonna say, oh, I want a PAM consultants, I want someone working at Okta or on for truck, they have hundreds. So this is real cash resource. And actually whereas seen large companies say, okay, we understand the technology, we understand the benefit, but we can't implement it by ourself. We need an SI and we need 20 people. And it's, they are, they are simple. Not that I see I'm running out time if you're gonna have some questions or my other plan was to leave all the questions to Jerry, who's much more wiser than me.
Super. Okay. Okay. Thanks Christa, really appreciate that question. Yes. In a regulated environment, yes. Is the UI in pro Well with the UI in production, not essential to allow auditors to see what's actually happening. Let me say it again. Yeah. Or you've got the drift. Yeah. What what, what access do we give to auditors? What, what I have seen is auditors, normally the orders I have seen is that you have a developer or someone else sitting with the auditor explaining a a little bit. Yes. And UI will help. It's not essential because the code, well, I usually said I haven't written a single line of code since I left the university 25 years ago. I can actually cheat in rego today. So you don't need that kind. It's not a central, but it helps a lot, I would say. And also I didn't have this panel, it was year ago bank when I said, well we have done this for five banks and and then I was him, what kind of policies do you want to implement? And he said, you tell me you have done it five times. Okay, you should have the packages. But again, the auditor would need that data though coming Yes. At that. Yeah. So So the tool needs to collect that for for the auditor. Absolutely. Yep. Okay. Any questions from the audience? We have a microphone.
You've done it. You've done it. No, there's, thank you.
No, there's a hand. There's a hand. Not
Yet. Oh, I missed it.
Not yet. Off the hook.
I'm not yet off the hook. Yeah.
So just a question around all of these tools, right? So also, and whatever you have AWS also having
Sank. Yeah.
And we also obviously have our own in-house that we built a long time. But is there any effort around having these tools talk to each other in some way? Right. Otherwise you have to. No,
No. Actually that question, I'm going to leave to Jerry because.
