Yes, I'm here.
Great to have you, maybe you could say a few words who you are and then please, the stage is yours. Thank you for joining us.
Hello, I'm engineer from last years, but before it, I was working several companies. I had one company for my own, and I was invited to flip bank, the topic to, and to build identity management service. I struggled it for years. I decided that it would be investing to share something from, with you
Looking forward to your presentation.
Oh yes. So this is the, it's not the, the, I have one in my hands and this is actually the one of my hobbies.
I, I didn't mean to make some dramatic here, but I rather want to around to, because, because maybe make some wrong expectations, two things, which I don't try to do here is similar, like to, which is way of drawing forward. I don't try to define holistic management cause Martin Martin have made a great work here by defining fabrics.
So this defines printed, there are a lot more materials like capabilities of data management, and then it wouldn't be possible to, and it doesn't make any sense to repeat those things because those excellents I'm not trying to, there is hope to teach you to use the ITTO in 20 minutes because it's, there are many schools produce. What they rather to do is, but there are some still some details.
When you go to the school which teach the, or any martial arts, there are some things which you have to figure yourself.
Some things may, may help you way, but has to find their, for some particular moves, you want to just put, there are things or find yourself. Those teachers are not taught similar, like ways of implement, like safe or any other methods and fabrics fabrics. There are things as an engineer you should know, or which may be beneficial for you. And let's go to this Porwal to actual topics, leave the yet on the screen, by my opinion, there are two ways to implement services.
One, I call it's operator and another one, which I call developer, they are not direct opposite. I didn't want to draw them as a jungle or something like black and white or going to different directions.
But they, they, because their intent is the same.
They finally, we must launch the service or run the service. Just developer stock run the service or operations launch. Something operator comes usually from the managers or from the, this Guild developers comes.
Of course, as me as a programmer. What I want to say is that we handle things a little bit differently, and this may lead to a little bit lean service to one or another direction. And our operators, the managers usually identify requirements. They compare the features and they launch the services. And I would say that this is many times it's the feature lean services because they usually don't. In first hand, they don't implement or define something. They go destroy. And then there is developer team.
We, as the developers, we define usually entities. Then we implement usually processes and then we run them and there is common points, but we may end up to the lean to the one after another one.
And what is the issue?
Is that, so me as a developers are pretty much concentrated on entities. And the issue may be that if we don't think about the features, then the entities may not really make up the sound feature. So it the same bolt, but meant for wood and not data just doesn't perfect to fit same time the managers find the features, but it may not fit to all situations.
So I, and the tool, even if it looks more capable, doesn't mean that fit for the purpose. So it, I can't really up the paper for it. So it doesn't mean necessarily more powerful tool is better. So this is the first thing, which I wanted to emphasize that first of all, different ways, same intent, but please look at it. When you look at your team, when you are the manager of team or program owner or product owner, how the team is set up, whether it's more operator or developer regime, then you may have to pay attention to different tittles, how they implement things.
The next thing, which is the role, by my opinion, the real core of the identity as a identity management service. When I onboarded Swedbank, then I had black paper, literally at my hand, and I had to draw something on it as a service. The blueprint of the service, the thing was that this is how usually people think they tend to start from definitions. And especially developers start from definitions of entities.
And it took some years to understand that when after talking and after implementing something, what they really need and what is the core objects of the IM, especially IM a service, why the I identity and index management is a little bit different from other technical services. By my opinion, there are three core objects which interact very rapidly are the states events and values, values, or attribute values, which each of them interact each, each other.
And those are the things which stakeholders and service consumers want us most. This is what they're asking for.
They don't really care about the definition of what is the definition of identical or what is the definition of the bolt, whether it's the metrics, whether it's the, what is the dimensions. They really care about how to use it, whether it's the wood or metal and how they can consume it, and which are the applications and in which conditions it work, which conditions doesn't work. So similarly for identity management, they care about the states.
They want to get events when the states changes and they want to get events when the value changes and the value is when they change, the value is then how the state states are changing. So this is the things, the description and valid description of the changes of the state's events and values are really the ones, the core objects, which I should have been drawing from the beginning and implementing from the beginning, because also the core objects, core processes of identity management as a service is really the engine, which just drives those states.
And the process identity management process to join a reliever mover are the really ones which are needed to run the service. But this is not the ones which objects, which rarely the users are, or other engineers are not interested. So when I would start from the beginning, I, or draw next service in the framework of I fabrics and in the, in the process, in, in the, in the, in the way, how safe it does still, those would be the core objects, which I would pay much more attention and draw this exactly how the, how those are interacting. Then the next things could be used as a tool.
It doesn't compete anyhow, it's safe, or how those, how you, how you actually do this, how, how actually implement this. But I would use this as an aid or illustrations and why not even to use it in actual situations to describe how do you build the service as a manager, it's easy to find today's different requirements for the services, the requirement categories. There are plenty of them. And for example, they're saying identity fabrics have define list long list of them. And it's thereby it's much easier today is to define the identity management of service.
But what, what is important here is that how to get the balance here, how to implement in the way that it makes the stable and sustainable services, I would use this kind of real. My phone is one. When I dig in my yard just this weekend and this illustrate the same thing, right?
It was happy finding.
So when you, you want to have the balance at one and you can build it incrementally, as soon as you remove or cut off one of them, or one of them doesn't work, then you get the unbalance feel and this kind of tool would help me to place the different requirements and show the, how they be inter implemented in iterations. So each of them should be in balance. You must add each iterations in the safe language is the program increment in some other language iterations, but you want to have tool to demonstrate that how you add each of them in time to manner.
So I would really maybe even use it in the, in the life. So it's kind of, I would call the service delivery, DevOps feel. And each of the points is that some parts of the requirements of formations and then the last and most important thing as me as an engineer, I found it and I tried to implement it.
I tried to apply this pattern of triple of typically things everywhere.
I, every time when I implement something, whether it's the process model or it's a coding, I try to find the two layers of obstructions and some in variance between them. It's not just, it's important. What is important here that this layers contains of three things. It's the implementation layer somewhere layer one and implementation layer two. And the in variance depends. So three things. This allows me to move things in time and start changing, start changing in the components in the layer, one component, a with the layer component B, but keeping the components in layer two intact.
It's not just, you may say that those are things like programming languages have their interface definitions, but what is important here is that you just can't, it's not enough to have two components, two, two parts of the layer interface, and the code would make two parts only.
So you would have in variance and you would have the implementation in one of the layers, but you, how you should do is the, you should really think how the another layer would, would look like, like the, for example services like, like the most, the one of examples is the APIs.
The protocol is not the in variance in variance is the, how we define the methods. They must be abstract enough, but same time particular. The one good sampler of the pretty heavy to coupling the coupling of the process is the recipes in the cooking book, which is one sample of heavy, the heavy coupling of things. You have list of ingredients and exact way to how to cook it.
So you cannot change anything there, but sometime, but another example which I could use is that good sample of is the, this battery and this tool I can, I don't mean that I can change this tool for something else, but I can still that at some point of time modernize this tool, I can buy a new one at some point of time, some extent, of course I cannot change buy by continue this indefinitely, but that for years it works.
And then I have some abstract, which abstracts me the power source still same, but I can use it also in many tools and it works for years so I can plug it in and change them a little bit, just enough to have some flexibility. And this would illustrate to me those kind of abstracts. So the charger battery and the drill would be the free components, which I need.
I, I need to know how to build the charger. I need to know the standards of batteries and the drill, but, and they must work together. I cannot really design them indefinitely, abstract way and same things, same similar layers.
I, I look for from everywhere. When I program, when I design the processes, when I design APIs, then those triples, I try to establish everywhere. So those would be the, this was the four, four things fit into the 20 minutes.
