So the headline, yes. Is they're implementing it in access management in the enterprise. So sweat bank is kind of enterprise, technically Nordic, and I pick free take away aha moments or gems from the under the hood of the system.
So from engineer and I picked selected them from freed areas, which made me think, or I wanted to highlight those are the data about the architecture and about the go live because the go live was especially interesting in this project, especially in project and just a small disclaimer that pictures are representing the live documents throughout a project to illustrate that there was something living, but thereby don't try to read the small letters there.
They are not meant to before we readable, but they're illustrative first three sentences about us, about the project and about our contributors.
Yes, bank is the major in European Nordic region. Probably not the largest in the world, of course, but still it gave some idea the scale. What is more significant is that sweat bank group. When I was also, when I was joined, joined sweat bank, then I didn't also realize the complexity of the, of the organizations, especially the fact which is given here that WeBank group collaborates ally with 58 savings banks.
And it's a very significant fact also in the identity and access management project, because we are offering the system and software, including the identity and access management for those banks. So we must be able not to cover just one enterprise, but actually more than 60 companies, because the list includes not only the savings bank and, but also the other companies who are offering services and 16,000 employees of the 2000 employees and savings bank gives the idea of the scale of the identity and access management project. The aim of our identity and access management project.
It's a nickname is Omar and it hides behind it free works, access management automation. The next sentence is actually from my document or one of the presentations, which made from stakeholders. And I still like those few buzzwords, which you can hear here, especially this is the multiplexing information, but this is, this were really the list of findings we had when we built the foundation for the project.
Repeated manual activities is probably well known when we ever talk about any automations, then we usually want to eliminate manual activities, but the other months, maybe a little bit confusing. I will not open the mold because it was quite long explanations, but they want the idea of this listing or buzzwords were really to give the picture or give the idea to the stakeholders, what they're dealing with, not just the automation part, but eliminating lot of more things. And our major external contributor to project for actually Analyst.
And to know the background, our system is implemented in point IQ myself. I'm working in software engineer since August 26. I discovered it just before I made this presentation that actually I have made now five years overall career started in 90, 96.
And I started as usual developer until the highlight of the career was I was working in few companies as CTO, but then I joined the sweat bank where most of all are actually software engineers to simplify their life.
My education back is mathematics and it, and I have been giving all lectures about software projects in universities, because I just like to share ideas and to give some idea about me as also that I'm still the human many people think, especially when they meet me first time that I'm not, then I'm giving also the group fitness trainings in something completely different, but let's go to them before we can proceeded games is the foundation for the project. This is the two illustrations, very significant ones.
The, we didn't start the project from the classic way, analyzing the workflows, but the rather started from completely different angle.
We wanted to, we described the how to be identity and access process model define the processes, how they should be. And then we selected, analyzed our system to our, according to this, what we have different, where we have to improve and what we have to change and what we have to create. And this is the live pictures, the contributor contribution from cooking on the left, it was quite long list the findings quite scary one.
And on the right side, there is the working document. When we from one of our discussion workshops about the sweat bank process model. So it showing it was not invented in a day, but it was actually the quite great work. The first highlight data and highlighted employment. There are three flights showing the progress of evolving this term. The first on top on the left side, coronary is more their defining or the discovering the problem or the scope of the identity access management.
This is very familiar picture probably for everybody who has working with IM that there is HR, there is the identity management or the enabler. It, and there are still two different world, which is actually quite understandable, I think because both of them, it and HR has their own scope of working and their own purpose. It's not probably possible that they are finally United, especially in enterprises. The HR is the vertical and it another vertical and they have some kind of caps between them. There are. So this was the realization of deals.
And the second slide was from another presentation, which we made when we are, we're already pinpointing the problem that what we have missing on the left side, we had objects which were existing in HR, the assignment persons, legal employers, very well known. And on the left side, there was the account, the target, which we going to implement. Of course our I access management project.
They was to automate creating the user accounts when people onboard leave and move, but there was something in between those which we didn't quite realized or quite they didn't fit in nature into the right side nature into the left side. And there was lot of policies, lot of conditions when and how the account should be created when they should be shut down and removed.
So this is the slide.
Second slide is from the presentation which we made when we explain to the stakeholders that we have, lot of things missing there, we have lot of things, conditions and data meetings, and it was basically some kind of complaint meeting. And then finally there was happy finding, which I wanted to talk about is that let's have the employment and the foundation was important here. We defined, we invented also besides the processes, lot of definitions. And one of the definition was that which concluded or included all of those missing policies.
And we said that let's have the employment, which is continuous period of time. When a person has work relationship with legal body in the same organizations, almost possible to say in one, one breath, but then it actually became simpler. It included all the main parts, which was not possible to employ into HR.
And doesn't, didn't make any sense to have there because the IM is covering the HR. And also what is significant. We don't have just one HR application. We have multiple, and we don't even have one source of identity. We have multiple.
So thereby it was also the purpose of the employment was to isolate the systems. And also the have the possibility that we can change the HR systems. This is usually the enterprise that systems have different lifetime. So the purpose of employment object was multitude. And the first slide actually describes. Then we get complex again, because now we, before to implementation, we had to actually how to say engineer it, how to Excel actually implement it then to describe all the rules we have. So this is the, just all the rules and explanations that you have on this.
But at some point of time, it was really simpler and it get things moving. So we had to invent something new. It wasn't sufficient to add something extra to the HR or add something extra to the it, we had really, really to find something new and to saved us.
So one new data object, which is the central. Then the second part of my presentation is about the third, which was original deferred one. And it's logically the last one it's go live.
We were so many, had so many struggles anticipations when we decided to go live because there was so many risks and we really were scared to press the buttons that we are now migrating the data, because it was kind of a Terminator feeling that or intelligence feeling or the day zero, we really didn't know what made wrong go wrong, or if something goes wrong, it was not really realistic to turn everything back.
And especially the reason when, because this is automation project, when something goes wrong, what the system will do really shut down all the accounts or really create 20,000 new accounts because it thinks that those users doesn't have accounts.
So if something is wrong in the system, then we have the complete disaster. And it took, there was many, many project meetings. When we tried to understand how it really, really looks like what really happens in details to every user account or every, every user or identity when we really go live this.
So the solution here was that we, when we realized it that it's not activity, it's not kind of even the week of the, of system shutdown for a week or days, it's a process it's last may last months, it, it must be designed into the system. So there was free design highlights into this, the go live. First of all, we started, we, we thought that naturally, you think about the identity process, like onboard move leave, but we realized that that it's much simpler to go live. When we start from the end, let's start from levers because those are guys or anywhere leaving.
If something goes wrong, let's then they get just one extra day off when their accounts is shut down purely. And we can fix them the accounts when they are not shut down timely, manually. So we started from levers detect levers from the HR and shutting down, down their accounts. So this is working and this, we got working, working. Then another decision was that let's have design into the system possibility to make one migrate one identity by one identity.
So it all the links or all the data should be universally shared between the new identities and, and old identities and designed it this way, that it was possible to just pick to any user and to create about, by the way about what is the new identity and old identity. This is what you see on the, on the left is that we have the old identities we named them legacy.
The problem was that we had to create two kind of identities. We had had to create personas and users because users are the one who are coming and going and having different accounts.
But the persons, the persons made join the sweat bank from time to time, I may come. I main go, I may join the SW bank into, from the different group organizations. I may leave the SW bank. I may start from sweat bank leasing and then so on. So there was a different legal entities who from UR point of view had different contracts and each contract by the law, at least in, by the security point of view must have different accounts not shared anymore. So we had to make architecture from, from one single user to the person and users. And we called them the old ones in legacy.
And we designed in the systems, the relationship between those and possibility to ingrate.
So links between users and legacy users were kept because it was not possible also technically to, to migrate all the data like for recognize the sale point here. Then they probably know that for example, the certifications or some other data is not transferrable very easy, but it's the similar probably for other IM systems that you can't really transfer something. So this was about the goal.
Live pre highlights and final highlights is about architecture, the fun finding which side we really don't have the final solution. It, but we realize it that you will have not what you draw, but how you draw it. This is our example of one process, and it continues in reality that multiple screens, my highlight is that when you draw the process, then you implement the workflows. But sometimes it's much easier to do. At least in management, find the policies and let the system implement it. System enforce the policies.
But so this is some kind of afterthought and we really don't have the solution for it. So it highly depends how you draw it. When you draw the boxes, then you get implemented as the boxes. When you draw policies, then you'd get the policies. It was one take away moment. So finally about the first things, sometimes it's not just enough to get the correct data. You may have to the fine existing entities. So we had to create employment and go live. Project is not just an activity. It's started in the spring and we are finishing just right now. And we succeeded to go live with this without risks.
Cause we design into the system and finally design features of platform and, and the system architecture must have harmony. So you not just get what to draw, but also how we draw it. And honestly, we have struggles yet here, but hopefully if you find it out.
