Good afternoon, ladies and gentleman, welcome to our Ko call webinar. I am projects done right. This webinar is supported by IC consult group. And the speakers today are Onri who is C of IC consult. And me Martin Ko. I'm principal Analyst at Ko call Analyst Analyst. Before we start with our webinar, just some quick housekeeping information.
So for, for the housekeeping audio control, you are muted centrally. So we are controlling these features and there's no need or to mute our unmute yourself. We will run two poles during the webinar one, right after that slide. And one towards the end of my, part of the presentation, we will do a Q and a, the more questions we have, the more interactive, the more likely it is. And it's your opportunity to raise your questions to entre and me. So if you have questions, feel free to enter them at any time in the go to webinar control panel, it's usually is at the right side of your screen.
And finally, we are recording the webinar and we are providing the webinar, recording the podcast and the slides soon after the webinar for you, so that you can review we again and look at the slides and whatever you want to do. So that's it in a, in a natural. And before we look at the agenda, I'd like to, to raise one poll. And I highly appreciate if you take time to answer that.
And so, so the first question I I'd like to raise is what is, from your perspective, the number one reason for IM projects is stalling or even failing. So it's a lack of budget. Is it insufficient stakeholder management, insufficient requirements gathering two strong focus on technology or lack of proper expectation management. So looking forward to get your perspectives on that, I'll leave it open for some 20, 30 or 30 seconds.
So, so another 10 seconds come on.
Okay. Thank you. We'll look at these results later on when we do the Q and a, so part one part of the Q and a, we will give it a, a look. And with that, we come to the agenda of today and in, in the agenda as usually split to three parts in the first part, I'll talk a little bit about common pitfalls and the need for Tom for a target operating model, which is one of the things I put some emphasis on.
And during this webinar, the second part, then on today, we'll talk about one, stop shopping for success and IM projects, and also how to bring different parties work together. And, and to ensure that everyone knows what to do and is clear about responsibilities, all that stuff. And then on the third part, during the Q and a, we will answer your questions and also have a look at a poll result.
I want to start with a little bit of a wrap up from a previous webinar, Andrea and media, a while ago in this previous webinar, we talked about success factors for IM projects.
And we also talked about pitfalls, and I think pitfalls and success factors are sort of two clients of the same metal and the two sides of the same metal. Sorry. And so what, what are these common pitfalls where could come and trouble, or which drive your success? It is understanding your requirements positively or negatively not having gathered your requirements. Probably it is about stakeholder management and projects. Success stays in falls with a good stakeholder management as, as well as with expectation setting expectation management set expectations, right?
So don't oversell be realistic. Talk about what I always emphasize both quick wins and big wins. So what are the things you want to do fast? What are the things you want to achieve on the longer run organization and both PROcheck organization? And the transition into line organization is important. Something we'll touch later, we will touch later on. When you talk about a target operating model, having the skills in place internal or external clearly pitfalls technology overkill. So technology is important and we need technology, but it's only a part of it.
And if it are two technology focused, we take a risk. We need to change management. Don't leave people behind don't create resistance against your project, set your focus, right?
We think modern don't don't. I think one of the big challenges today is that there's, there's a tendency to say, okay, we, we go for what others did before, which is good to a certain extent, but if it means you're going to something which is already outdated, then it's the wrong way. So I think you need to find a good balance here.
You might not want to be the pioneer, but you still need to understand what will you need in the future. Think beyond just the current requirements, cause also back to requirements. And finally, last and least pragmatic be pragmatic. You need projects changed. There's a lot of things you can spend endless time with creating the perfect role model, but be pragmatic. Lesser perfection sometimes is your winning factor. So this is something we talked about in a previous webinar, in a podcast available online.
So you can review also this auto webinar that brings us to, to projects and what are the key success factors for the projects? And this is overlaps to a certain extent, but it also goes a little bit, maybe deeper into some of the subjects. And I structured this into five areas.
In fact, four areas that drive the success in the fifth in the center at the center is what makes up success and success comes from delivering on time at budget in quality, complete and distinct, complete means. Delivering what you need distinct means. Don't redo things you have in another area, just because you don't know about it or so to user friendly. So does it still the things we see so frequently that there's technic technologywise functionality wise. It's great, but users can't use it. It's too complex. It's too cumbersome to use it.
Think about user friendly user experience is super important.
Last, at least it must be accessible. The world will change and do it for a sort of a changing world growing world that you trust for your workforce, for your partners, for your customers, for all identities plan for that, not necessarily implement everything at the beginning. This goes back to pragmatism, but plan for it and to achieve that you need to do good requirements analysis and a continuous update think in a program and this program will change. This will evolve over time.
So what are your current requirements you have also from things that don't work as expected, what are future trends? This is what analysts can deliver. Ask the Analyst, what are the regulatory requirements and other factors that come in. So think beyond just what you currently see as your challenge. Then it's clearly about planning about budgeting, about stakeholder management, planning from a vision blueprint, architecture.
So technical planning from a program planning perspective, attach stakeholder expectation management, go from program into the concrete project.
Planning ensure that you have money on place and a good project manager. You need good project managers, definitely with some level of technical understanding because it's always a technical thing. People's processes, policies have the people in place the organization I'll touch it later on with the target operating model as well. Well defined processes, spend time defining processes.
You learn a lot about us, the paperwork, so to speak the paper design of processes is definitely well spent time, as well as it's fruition improvement, architecture and for policies at the end, you need the policies because they guide what you do. And then, then you can look at tools and the implementation, but there's a lot of groundwork to do ahead of this, to be successful in your project, this tools and implementation singers portfolio to and fit gap analyzes.
So what do you have? What do you need? What are the biggest gaps?
The most UR urgent things to do understand your operating model create a long list. So the press of look at whatever our leadership compass or other types of documents, which look at this market, go down to a short list, narrow it down, run a proper RFI and RFP request for information for proposal, nail it down. Maybe to two lenders, do a POC. A POC is a POC, a short test shouldn't take longer than two weeks of some selected critical capabilities. Maybe also then go into an MVP pilot approach, but don't mix it up, select the right provider and system integrator.
You need to have the right partners on hand and also have guidelines on and for architecture and implementation. So that, that we, that everyone who does some customization or coding, does it following defined guidelines.
For instance, everything you, you, you create as custom code should be in, held in separate segregated microservices using APIs that helps you to ensure that to, to reduce the risk of that.
When, when you have the next update that all the customizations start failing. If you work with the proper segregations for APIs, also some of the things we discussed in earlier, webinar consult, and this brings you then also the IM agility because you, you need to be agile and you want to be agile. And for doing that, you need a couple of factors. And one is organization. One is people. So you need a proper organization. This is again, this target operating model thing. You need to people, you need to educate people because you will not find all the people on the market.
Then you need to, to model what you want to have.
So have a plan, have a high level plan. You need to plan your concrete roadmap. You need to, to have a good operating approach. You need to build it in a well sorted, a modular way. This is for instance, one of the things we have in this co define concept of identity fabrics, where we also did a couple of webinars and we have a ton of research on that. And you need to automate, this brings you down to that, to the targeting target operating model, and also to a high degree of automation.
So it's automation thing is in that slide in some way, twice was the GI ups thing below it. And this target operating model I attached. This is very important. So define how your organization looks like, and you can start this with saying, okay, what are the major sort of operating and operating model categories to major elements, which are governance aspects like access review and policy definition, which are onboarding and support manuals will fulfillment, which are process related things which are the operational provisioning and all the other things you really should create such graphic.
You should understand what are the elements, put it into layers like we did, where we have to develop and, and platform operations. You even may split this into two where we have to functional operations when we, where we have to and some business onboarding. And then the next step will be that you take such a graphic and think about who is, who are the parties involved and who does, what, what is centralized in your organization? What is decentralized?
So are there things that are happening decentralized, like certain aspects of, for instance, entitlement management, are there other things which definitely happen centralized like policy design policy or process design? What are things which might to certain extent, be centralized or decentralized. Like you come up with a standard process framework and whatever, some of your legal entities have the ability to adjust it to their specifics.
You need to define it.
And then you need to define who ask what who's responsible for, what you can create a Rocky metrics or responsibility, responsible accountable, etc. Or, or you could do it in a different way. But at the end, you need to understand who does what in this. And you even need to think about who does what from a line versus a project organization.
So, and what is the, how is transition handled between the project and, and program and the line organization? So these things are things you need to define. You can start with, with a graphic like that, feel free to, to use that. And then it's, it's the groundwork to do saying, okay, how does this map to my organization, to my partners, which partners do I have, like, like a cloud service provider or managed service provider, system integrator, maybe some other partners who are more on the consulting side, the internal teams, and what is then the IM team doing?
What is the business teams are doing? How, how are this split up? But this also helps you in defining your, your future. I am organization at the end of the day. So you need to spend time on the target operating model. And you also should, for all of this then take, and this goes sort of start something this up, taking a, a structured approach. And you may read from some the per the idea of that plan build, run improve is not, not, not a well approach anymore because everything is agile. I don't think so.
I think we should better think in, in different layers and all of them are in some way, plan, build, run, improve, even when you're agile, sit together every two weeks and plan what you build and run and improve. So it, it is just in shorter circles in some way.
And you have a long-term strategy, have a stable architecture, and you need a stable architecture that can't change with every every second week or so. You need an agile implementation. You need to continuous operation.
And for these things, you need to think about what is, what you need to plan like the targets for your strategy, the principles for your architecture, the requirements for the implementation and the operation model. And then you need to think about what does it mean for building, for running, for improving. So I won't read up that entire slide. There's a lot of information in, and as I've said, we will provide a slide deck for download and you can then go into details.
But I think that an important aspect is you need to, to do a proper work at all levels, from the IM strategy to the IM architecture, in that case to the IM implementation to the IM operations, and it will evolve.
This is the improved part. It will not be something which stays as it is for the next 10 years. It will evolve thinking a broker thinking a living thing IM is constantly evolving when I I'm an I am right now for probably more than three decades. I started in the early network and land manager days.
And when I think about how I am look back on these days to the days where we talked about media directors to the days of trust workforce identity management, to the days of identity management days, for all types of identities, well beyond the humans and a world where we, we deal with cloud services and traditional IM traditional, it, it is really fairly different. And even that stop evolving, there are next new topics popping up every, every now and then every again and again. So review it, improve it in the adequate cycles. So what are actions you can take?
And that's not about security identity because they are so, so closely related from a strategy perspective, a target is really that security identity become an enabler of digital business and they are, or you could phrase it the other way around if you're not good in identity and security, your digital businesses at risk. So you need to align security and then identity with requirements like business, continu management and digital experience.
You need to, to educate about this security, security awareness, as well as their role of identity for digital business, you need to adapt to risk, but also to new business requirements. And so you can again do that for all of these areas and understand. I think part of the story is really tell the businesses story that all you do here is not just something you must do because of some regulatory requirements, but it is business enabler.
And you can do it in a way where it able Ables business and it secures the business and where it's convenient and secure.
This must be your target and you must be, must do it in a very well structured manner. And this is what I'd like to share with you in the 20 minutes I had, I wanna bring up a second poll, as I've said, all the slides are, will become available for download cause all the details. This second poll is, is very easy. It is just the question of, do you already have a comprehensive blueprinted architecture in place that covers all of IM so not just user lifecycle or access management or privilege management, but everything. Do you have something like that or not simple answer yes or no.
Again, I'm 30 seconds or so and okay. Another 10 seconds. Okay. Thank you with that. I am happy to hand over to Andre Bria and his perspective on this topic as I'm one stop shopping for success. And I am projects.
Thank you very much, Martin. And good morning to everybody from Denver, please, don't be concerned by the beer behind me. This is just a part of the taste for decor of this interesting here and yeah, today, I wanted to a little bit about well expectation in identity access management project, because for my experience, it's very, very important in order to make them successful.
Cause it somehow shows you what parts of the targeting model Martin explained is important and taking of and over between these different, different tasks and responsibilities there. Yeah, my name, my name is I'm the we're system integrator and managed provider for identity access management, more than employees worldwide. Therefore I'm delighted to share today. Some experiences we made this all the different solutions, different flavors out there all well different on the Martin Martin explained.
So one promise is if you think about all the tasks we have to do for identity and access management, it makes a lot of sense to go for solution instead of software solution for obvious reasons, right?
Of course, plan run Martin that that's likely not the approach.
We, we are working today in agile it, but anyhow, having iterations on that is is valid. Of course, and then it maybe not different teams, but, but teams, but one team taking care, also different aspects of plan, build, run, and improve. And the expectation is clearly, if you go for solution, you already get a of function provided to software. There less planning effort is, is reduced significantly solution Iskey solution. And for the run operating what the providers taking care of that. So no efforts for you, right? So would say, congratulations.
If you start with that mindset, then you really prepared for making an educational experience because my assumption is will likely not, not work in that way.
One example for that, some of you might know the Gartner hype cycle for identity and access management. Couple of years ago, there was interesting thesis saying identity management managed services are somehow deprecated because SAS services for identity access management will do the job in the future. Therefore they're not required anymore and will be out of the hype cycle in the future. Then the last hype cycle told a different story.
Identity management manage service are back in the game and reaching the plateau of productivity delivered identity access management is going back in time. So time is still to come. And I personally don't agree with the first opinion on that. And also as a new one it's I think we don't have to think about, you can go for manage services or for SAR, but we have to combine these approaches to make an identity access management solution successful. So as you're talking about expectation management, it's time for small check.
There are a couple of providers out there and today in RFS and RFPs, typically SA is always the first choice for very good reasons. And I would not argue, argue against, against that.
Anyhow, the risk is some SaaS providers mentioned. So of course, a couple of more, the risk is that during the sales processes, of course, by nature kind of over promising and patient is on the client side, driven by these discussions. It's so easy to consume these services and we don't have to take care about a lot of critical things anymore. The turn key solution, we can start right away by that. Please have in mind the target operating model Martin shop before and now let's have simplified form of that and that's go through.
So in reality, what you get from the sales provider and that's, you know, world good quality, reliable service, secure service are two of the aspects.
Martin mentioned, it's a platform development who can compare to the software development if you ment software product. Yeah. So you don't have to build up the expertise for, for, for, for programming the software, developing the software, bringing in new features into the core product. And of course the platform operational, that's what you get. But these are two of the six.
I don't want to prepare enough from, from perspective, but this is something what we, what we should have in mind. Now, why does it make sense to talk about managed services? Why does it make sense to managed service provider? Even if you want to go for a solution. And this is simple provider can of course cover much more of the aspects than the provider can do because approached to, but it's not doing exactly what you wanted to do. You can compare with a vanilla play installation of an identity access management software, right?
You all agree if it makes a double click, the installer yeah.
And installer done, then I'm not done this project right there, something running, but now the real begins and that's some the in as well. So therefore let's now go a little bit through these different about the, about important things to have in mind.
As I said, platform development is everything about providing the core functionality, everything what is, but, but not just the functional perspective, a lot of nonfunctional aspects of course implemented in the, in the platform, Harding security assessments and so on. And especially combined with the platform operation and you are getting everything. What is required for a service was a high availability. Yeah.
Typically, typically availability promised by the is nearly good for all use cases I have in mind. There are some very rare situations in which organizations prefer to go for managed service provider combined with software instead of SARS, because they have very specific requirements on availability.
For example, they want to protect themselves against any limitations when it's about internet availability, maybe of, of production sites and things like that.
So having fall back OnPrem can be a reason or so high requirements on availability that is, that is necessary to go for different infrastructure providers, Microsoft Azure, combined with AWS instead of just one provider that are really rare situations and of solutions much more expensive than going for south offering. So, but what is the starting point organization then customizations?
And because you have to, to make sure that the expectation is not, there's a turnkey solution already there and you can starting, but you have take care of a lot of, of things that just want, wanna mention some of these example. First of all, everything, what is related to the corporate identity, the look and feel, but also communication with the end users, the data model, the processes, what are the sources for identity data?
What are the targets for identity data and much, much more, this is something which is often underestimated.
And especially when it's about the offering and this therefore want really to, to highlight.
And it's now this is something what is provided by managed sales provider to you often, this is really project work because it's something what really depends on the individual requirement of your organization and having clear understanding of these requirements, success iteration, the identity accession specification customization is part of, kind of project to bring the system live is the very first iteration, but then having all the smaller adjustments of the solution is then part of a managed service. Yeah.
How can this be part of a managed service now, for example, having, having kind of, of redefined change request via key sizes. Yeah. This is a small change. This is a large change and this kinda change can be part for managed service offering of course, to make it to plan from budget perspective, for instance, without having, having all the, by setting up a small in order to make bringing Martin we code code.
Well, of course, expectation is especially if you offering that most of the implementation work is configuration, but often customizations with a little bit more complex logic going for, for programming, right? Maybe, maybe there are web hooks. Maybe there are rules you can implement in JavaScript, which makes them much more sense than configuring it in a 50 kilobyte, large XML file. Right.
So, so a little bit programming will be part of that. Also you might want to go for an approach in which the configurations are not done on a UI level. Yeah. But on a configuration is code level. It being mentioned before. And in that, in that case, you will make sure that all changes are done via API and the code for calling these APIs as part of the GI repository, going through pipeline with all the benefits we can get out from that setting such a pipeline up operating, running.
It is of course some efforts.
And that's all also area in which a managed service provider can provide to you all the functionality already in place adapt to the provider of your choice. So that, and that this part of the project is not so time consuming all these things from the, so then the fulfillment and that's, I would say the, really the, the daily business from an perspective of a managed service provider, but also for everybody who operating an identity access management system and very important, this is something which the provider help you in any way of provider incident management.
But I would say more than 90% of the I are platform or platform development to users systems and have to be analyzed and fixed with the knowledge of the particular solution of your infrastructure, of your it landscape, not with a lot of internal insights into the development of theta platform, for instance, right.
And, and that's, and that's something, what is often forgotten when it's about SLAs and, and also incident management for what kind of incident management that provider helps. And what part is just, what is responsibility, because it's really related to the, to the own it landscape.
And therefore this is typically very important part for the managed service provider to provide D five SLAs for the incident management incident, response time, maybe incident resolution times, and having these things in place to allow you to provide robust service.
This is very closely related to the business as well because onboarding of new applications of maybe new business business business units with specific, with specific policies in place, if you're in the situation in which you do not have enough mentor to be enough to yeah, fulfill this requirements of your it product in your organization, then the identity management is becoming the bottleneck when it's about bringing new applications life.
And this is a very, very bad situation.
Of course, that's, it'll damage the reputation of the service a lot, and this is something you really wanna prevent. So a managed service provider is defined SLAs for all the onboarding procedures, guidelines for application, maybe, maybe onboarding workshops with application owners can help lot to, to, to up a very good reputation for the identity management within your company.
And this is on the long run from perspective, most important goals, because if the reputation is damaged them, then nobody wants as part of architecture, for instance, making the identity, the digital identities, the core element of implementing such an such an security approach. So it has such a impact on the old company. If there concerns about the identity management, that's the reason why having managed service provider in place is, is something which really helps a lot from my experience.
Because if you build these things just up as project team, the projects team will be done one day.
Yeah. And people have to take over which don't have theses anymore. And then it can be painful to later to later bring a managed provider. It's much doing it at the beginning, the early iterations, maybe starting this go life of the overall solution.
Anyhow, there will be of course, parts, which will likely not be done by the managed service provider itself, especially the IM governance tasks we have seen in the target operating model. And, and it's important to have the internal capacity to take care of these kind of these kind of actions. And as we all know, I, it resources hard, very hard to get it makes sense, provider focus, focus on, on these things, which are important and required in order to successful identity access management solution running.
Yeah, that's it from, from my side about identity access management, manage service offerings and how to make them successful. So now Martin, back to you, we are happy to answer questions
And we are back to the third part of the, this webinar, where we look at the questions and answers and thank you for, for all the input you you've provided. And what I wanna do is, is first I want maybe start with, with one question.
I think it is one where, where both you and I can, can provide some answers, which came in, which is how can I manage service work efficiently together with internal it resources. And so, so I think we, we come from a little bit different positions because you, you, you are from organization that also provides managed services. I'm the Analyst.
But, but I think may, maybe you started, I bring in some of my thoughts about how, how can, what are the important things to really make it work well when you have a couple of parties in
Yeah. Martin, you mentioned before the, of course it's some effort setting that because a clear understanding what are all the tasks there? I think it's easy to have my understanding, what are the players there, but what are the tasks have to be done? But the targeting model helps a lot going through all these boxes and building up that understanding and defining it clearly in Iraqi metrics. Yeah.
Saying, okay, this team, this party is responsible for that. Maybe this party is getting that information is being informed about these kind of things. And because it really helps to prevent any misunderstanding. Don't be concerned of building up these Rocky metrics because for managed service providers like IC, but of course, others as well, and this is day to day business for onboarding clients.
And so that's something what we are used to do in order to make sure that there's no, no misunderstanding and, and, and clear understanding of the responsibility,
Add a here, because so, so when we are Analyst come into projects, but it's either early in the planning or sometimes it is when things are in trouble. So last thing, and, and then it's frequently a little bit of finger pointing about who's guilty and, and who did, didn't do what that party was supposed to do.
And, and very frequently, this is that there's just no clarity about who was responsible for what, there are no defined interfaces. There's a lack of a clear organization. And I think this is, this is exactly the point, which goes back to the target of brain model and maybe Iraqi metrics as one of the, the ways to, to depict how all these things trip work together.
And that is the reason why I'm I so strongly believe that you need a very good organization, an organizational model, which clarifies them for all these blocks and even more in detail, which of the parties is responsible for what, in which way. And I think this, this effort is never is wasted time because it will really help you. And it goes, and, and this there's another question about SLAs, how do different SLAs play together? You need good service descriptions. You need good SLAs. You need to clarify things.
Otherwise you will, more or less inevitably fail or at least get trouble sooner or later.
Yeah.
And, and also important from my, from my point of view, as we were talking about, about SLAs response, these kinda things before don't, don't just focusing on directly related or respond, operating, providing the identity solution. Also the application owners in place, because they have to do their part as well in order to I, which are related to specific applications. So they are also hand over between the manager service provider and it organization inside applications can of course not be done by the manager. So provider was not in charge charge of them.
So there are different, different points over responsibility, and yeah, that really, really require to spend the time. And
As I tried to say, and maybe I wasn't clear enough about it. I think that the, the interesting thing is at the end, no one will be unhappy with having that. So it helps the business. It helps the various types of providers when everything is clearly defined, because it's not fun for, for any of these parties when, when, when there's trouble in the project.
And so, so it is really an important and a very helpful thing. So maybe we take the time until some more of the questions come in for having a quick look at the results of the first poll, which was about what was about the reasons you see for, for IM projects, stalling or failing.
And budget is step one was the, the lowest number here, but it's, it's really quite a lot of people focused on insufficient stakeholder management and insufficient requirements gathering also expectation management, which is in some way related to stakeholder management has got quite a number of sort of words here and there.
There are really a lot of reasons if you, if we combine stakeholder and expectation management, which are, as I've said to a certain extent related, then, then it also shows don't oversell what you're doing in your, in your project with that, let's move to, to one of the other questions here that we see a couple of questions coming in. So, so one is here. Richard is I think an interesting one. What would be the reasons or advantages for outsourcing IM operations instead of carrying it sort of within the organization?
Andre, do you wanna bring up your perspective first?
Yeah, sure. So to be clean, typically lack of resources.
So that's, that's, that's often, often the reason too much too much work to do ending up in a situation in, in which you are not able to respond fast enough to the requirements, to the demand, to incidents problems and, and them up in a situation that identity becomes a bottleneck that's that's from my perspective. So number one, number fund reason.
Yeah. I would say that it's is really skills gap. Yes.
So, or lack of resources, however you'd like to phrase it. I think the other point is that if you potentially, an op operations provider is, can do things more efficiently based on practices, on experience than you can do it with just your internal team.
And I think these are some of the reasons we typically see for certain parts of operations, probably sometimes lesser for, for the IM operations, but specifically, but also there, you know, some things you automate, you automated once as a service provider and you, you use automation than for many, which is harder do when you, you just need to do it for your own organization. So I think this is something where you, you definitely can benefit as long as the, we need to be fair on that.
The service provider delivers on that, that promise of sort of giving you an advantage by his best practices experience and his ability to repeat things across a number of customers. And I think this is an, this is one important aspect here, which I would bring up as an answer to this question.
Yeah.
Maybe, maybe to, to bring some, some of the examples. So as mentioned, staging processes, configuration as code, these kind of things. So this is of course something up once by minister provider to support that for Okta or Microsoft Azure, and then is reduced over the, the clients.
Another aspect is typically the importance of identity, access, manage, and reasons that organization is growing over time by being adapted by more and more applications, it systems out there, maybe subsidiaries in other regions in the world and providing them the support and also 24 by seven, that, that on, on a, on a good level, because it's, it's block time on the other side of yeah. Integrating applications there, it's also something typically brings internal teams really to the, to the limit.
Okay. We have one more question here.
Maybe one I, why would I'd like to, to pick first data model? And I would say behind us data quality seems also like potential pitfall. Yes. Data quality is something which always is a T IM project.
So who, who, who do you think should be responsible for orchestrating this from HR top down to target applications is an enterprise architect IM or where it was in the top. I presented. Would you put it in? I think it's, to some certain extent, it's even a little outside of the target operating model, because it really starts with sort of having a model where, which defines the responsibilities, etc. Of different parties. So for which data, and sometimes for which identity information, even in which sort of scenarios create change, et cetera, is who is responsible for that.
And this is the work it's also part of groundwork to do.
I think we recently had a webinar, not that long ago about identity information quality. So we used find a couple of things that our, our website recordings and reports, cetera around identity information, quality, which give you quite a number of answers on, on this subject. And at the end, then it is that you have a responsibility in the planning part and you have a responsibility. You need to have people who, who really care for quality. It must be part of a process it's at the end, it's was a part of governance.
So this is what I see in yes, identity information. Quality is always a problem in this. So before we close the webinar, I'd like to have a quick look at the second poll with not too surprising answers. That the question was who already has a comprehensive blueprint, architecture across all of IM in place.
And so service 30 to 70 ratio is what I would have expected here. It's still something we, we don't see from my perspective, not frequently enough.
So it's, it's still too much focused on a individual problem and individual challenge instead of a broader approach, which says, okay, we start really with a picture of all of our IM and this is by the way, it's not SU not a tremendous work to create such a picture, look at what we have written about anti fabrics. That's one of the things okay with that. I think we are at the end of the webinar and through the questions we have received, I want to bring up one comment more, which I believe is a very good one. Security is like a diet. It's not just the one time thing.
You have to maintain it constantly. I can, we can talk quite a lot about also about diet part. It's really a constant thing, unfortunately. And I think it's true for security and identity is also another one time thing. It's something which is evolving constantly. So thank you them to all for listen into this group called webinar. Thank you for IC consult for supporting this webinar.
Thank you, entree for all your input. I hope to have you zoom all back in one of our upcoming virtual events or high events. Thank you.
Thank you. And have a great evening.