So hi everyone. Please join me as I embark on this I Am Evolution journey. My name is Jan Slots, I work at IF insurance. And today I'll deep dive the answer.
Detect, migrate, adapt, repeat. So before we get into the main part, let's start with some definitions. Let's start with the definition to Barb Inheimer. So combining two completely unrelated things, yet the world needs both of them. How about we do to Barb Inheimer together? How about we embark on this journey as we were, as you were all standing here and I would be sitting there. So let's Barb Heimer together on the Barbie side, let's put business. It's just be Barbie, be business. It's just it seems fit. And on the Oppenheimer side, the heavy side, let's put technology.
So let's see if we, we can heimer the business and technology together. So if we think from the business perspective, there are a lot of things they focus on, what is their scope?
But usually unfortunately they tend to put too much scope on the budget, the sales, and only on the happy path. But if we are thinking about everything, what does identity and X management technology offer? There are so much things to do. If you are starting from beginning, you didn't even know where to begin.
There's so much features, things, functionality, processes, technology development, power, manpower, legal, so much things. And yet the business is worrying about the ca happy path. So let's try to maybe put out all of this together and how does it make a successful evolution? So every business, every company you have worked for, we all want to work with this magic equation, business plus technology. But there is one thing still missing if we want to end up with happy users, happy and customers. And that is trust.
Business has to trust the technology side and we the technology side have to trust the business has their best interests.
It's about the collaboration, it's about the ratio of this trust. So a really long time ago, 12 years to be exact, and if we had this relationship management project, so it was very simple. Some websites in the same code based repository were able to log in and that's it. Identities were stored in a customly written database. They were imitating a federation. At least that's what they wanted to call for the business.
It wasn't actually federation and there was complex authorization customly built in the database. It wasn't scalable, it wasn't future proof, it was unmaintainable. As the years go by, right now we have more than 8,000 employees, more than 4 million customers, and we are very strongly a digital first company. We are leading in the north area and we are working our way up in the Baltic area. So there's a lot of business to cover, there's a lot of customers to satisfy a lot of identities and technologies to link together.
And throughout the years we have done most of the work, right?
We know how to access, manage, identify, and do a lot of these things. One of the central combining element of this is an identity server called curity. We handle more than half billion requests throughout last year. More than 20 million unique user authentications and roughly 100 million million issued access tokens. So there's a lot of things happening. A lot of things are combined. So we are finally here for the main question, how do you go from this to this in 12 years? How do you start from something customly built and suddenly you have an empire of IM technologies?
So the answer was in the title slide, detect, migrate, adapt, repeat. Well that's the expectation. That's how it written in the books and that's how it should work. In reality, when you embark on each of these step, there are some couple of questions.
Do you know who is asking all of these questions? It's the business. So do we really need these features? Do we really need to improve? What about costs? We don't have any budget for that. Why are we fixing something which was working a year ago and now we need to revamp and to rebuild rescale update and do all of those things.
And once you go through the first cycle of this, these steps and you get to the repeat part, you don't even want to think about that. That's just an explosion of this fight. How can we create this ratio that both parts are satisfied? So I would like to define this. Im evolution Infinity loop. So the most important part is communication. Without communication, we have exactly nothing. When we want to build upon communication, then a lot of businesses don't care about IAM, just as at some point ours didn't as well.
So IAM awareness is a thing. Non-existing.
In some companies I would say we are on our journey in our company, but it's still a battle. You have to keep fighting, you have to raise awareness. It's not about developers. Developers also need to care about, but the users, the business, the end customer, the legal, everybody, all parties, producer, consumer, legal, you name it, have to be in involved because everybody is kind of involved from some matter in some way. You have to follow the trends.
You have to know what's going on, what is suddenly outdated and what is suddenly hip now and all the regulations and every process happening in the Europe. So at the end, I'm very proud to say that our, our company, I have a hand few of people with lots of passion because when you ask those questions, when you request those things, you get a lot of nos.
But you have to turn those nos into a yes. So without passion, there's basically nothing. Another core question is, is there a centralized slice for everybody?
Everybody wants something, but can we make it centralized so that if we cut a slice, everybody's satisfied? So we have to start defining flavors, the existing use cases, the potential use cases, and of course, what kind of development do we have? Do we have any manpower? So how are we going to actually take it to the next step one at a time? So we combine all of these flavors into recipes and these recipes cost something and it costs to the budget to the business. So you have to start with smaller recipes and build your way up because the recipes get more costly as time goes by.
So the first cake, the first cake, which was many years ago, it was simple single layer yet very delicious.
So the relationship manager project, well it did it. It did its job, but there was no future. It wasn't maintainable. So we wanted something where everybody could get a piece of cake, enter a DFS Active Directory federation services. So we can enable username and password accounts to all customers websites and internal applications. So suddenly we have our first centralized cake. So that's great.
But at some point, as technology grows and everything evolves, people start asking questions. Can we connect these two machines together? Can we connect these devices, these servers? What about APIs? What about if we want to give our authentication to some broker or to some other identity provider? You start building complexity, you start building the layers of the cake. So enter a new project which we called Pluto. Pluto is based. Pluto is an identity provider based on the identity server, which is an open source solution at the time.
Seemed great.
So suddenly we were able to connect APIs through all clients. We were able to federate A DFS federate our internal Azure ad, and we even built a communication with an authentication broker called signate. Thus enabling bank IDs for all of the countries we work in. So everything works, everything everyone is satisfied. Why isn't this the last slide of the presentation? Because at some point we have to continue asking the right questions. If the business doesn't ask the questions, we have to ask the questions from the IAM side.
So we have to think about the future before the future is here because then it's a bit too late then it wasn't planned in this year's budget, then it wasn't planned of five new new hires then there was no plan for a new development team. You have to think about the future before it comes.
So we started out with the vision. We started out to plan, which we ended up consuming an identity server called purity. We had this vision initially it was just for our partners. So there was no centralized way. Our partners repair shops and travel agencies, you name it.
Everyone who uses insurance could integrate to our APIs and use our data. There was no way. So we found Curity, it seemed great, but then we thought, wait, curity is miles better than identity server three, which was an open source and at the time there was no support for it as well. So we combined the vision and the existing solution so that all of our internal and external needs can be satisfied by Acuity. But here comes the most painful part. We have two IDPs at the same time. What do you do? You migrate. But how do you do it?
There is no tutorial, there is no description, there is no book how to do it. Suddenly we are forced by legacy technology to enable innovation in all different sorts of way. So we have to suddenly group applications for them to migrate together because everything is kind of connected. Suddenly you have to understand the big picture of your whole company, which covers more than 4 million customers. So we have to force stop building legacy flows. 10 years ago, implicit flow was a great idea. Nowadays it's a joke. You have to be on your toes, you have to follow the trends.
So it wasn't about building more layers to the cake, it was about everything else. We had to change the way we have processes and we deal with them. So we established a global IAM guidelines, all new projects. And the ones who aren't limited by their list technology, legacy technology framework had to comply.
They had to change their legacy flows, their legacy way of communication. They had to change a lot of things.
We established a new process called production approval, production assessment process, POP with pop, all new applications going to production, have to go to serious events, series of events where they ha they are regulated, they are governed in all different sort of way, which also includes IAM review. So specific review just to understand if your IM solution, the code, the communication, the configuration, the data storage, the cloud, the infrastructure, everything is that up to date. And of course another series of events for data. GDPR and Architecture Cloud, you name it.
We also designed authentication instruction. My colleague Michas is having a great session there. He is a great session tomorrow while he deep dive that a little as well. So we understood that yes, it's both mastering the layers, but it's also mastering everything else.
Once your K gets thick enough, you have to think about how are you going to serve it. Is this slice actually for everybody? Should you start building more cakes? What about the frosting? What about the way you serve it or how often you serve it? You have to think about your processes.
The only way you can improve is by tearing down everything exists and creating new things and using the previous ones. The best there way there is to use. So we had an instant situation, which I wanted to explain. So we had a problem authentication, broker instability. There was nothing to use, there was nothing to purchase. So we built it from scratch. Project resilient authenticator. What does it do when an authentication broker who enables US banker the authentication to one of the countries suddenly has instability, has some issues. We don't know why.
We just know there are issues.
We can make a seamless to the end customer switch from using through Signate and Lia, so we can switch it on the go. The customer A wouldn't even know that customer is using one authentication broker and then the next second customer B is going through a different authentication broker. So we kind of put everything in a seamless way, seamless to the end user, but requires work. It requires manpower, it requires development. So you have to look at your problems and think if there is nothing to purchase, maybe we can build it. Can we plan it in our next sprint?
Super sprint planning budget, everything. So when everybody gets hungry and there are a lot of things to cover, the cake gets complicated, it thickens, it's quite hard to do these sorts of things without getting your house in order.
You have to understand what are you delivering, what are your services and how do you even serve your customer in all different sort of ways. Each business team is focused on their business product. They don't even know their identity and access management solutions. Team A uses and team B uses. So you always have to get your house in order.
As we close up on this journey, one of the final things which has to be there for all of these steps is self-evaluation. You have to look yourself into the mirror. You have to look in the mirror of your technology, of your solutions. You have to look at yourself even if everything is great, because few years later if you change nothing, some of the flows, the communication types or anything can be outdated and you always have to adapt with self evaluation. You always are some steps ahead. So to work with business and technology, there's a lot of ways how you can do it.
There have been successful attempts and some bad attempts, but in the end you have to find the best ratio of trust, collaboration, and passion. Thank you.
Thank you very much, Giannis. This was very insightful and I believe it's probably has been speaking to the heart of many people in the audience that have experienced somewhat similar journeys. So it's insightful. The only probably open questions, how can we get back to a simple cake at some point, which might be great, but I think it's probably one of the challenges you're always facing. So thank you very much.
We don't have much time for questions, but you always can reach out to younes via the app. So use the app, you can message other people. It's really a very helpful tool. Thank you for all the insights. Thank you. And.
