Welcome to our KuppingerCole webinar "Making IAM Agile and a Business Enabler". This webinar is supported by iC Consult. And the speakers today are Tim Hobbs, who is microservices evangelist at IC consult, and me, Martin Kuppinger, principal analyst at KuppingerCole Analysts. As the webinar title already says it is about making IAM agile. This will also be a lot about customization orchestration integration of some more technical aspects at the end of the day, but also put into a broader context on what do we need to do to serve today's business needs. Before we start some, some quick information about our upcoming European identity conference, some housekeeping, a double billed directly dive into the subject of today's webinar. So next week, starting on Monday, we will run our European identity and cloud conference 2021. This is a fully high Purdue end, so you can participate onsite in Munich, or you can participate online. There are different ways to participate depending on where you want to participate.
Have a look at a website, there'll be a very interesting event with 200 plus speakers, a lot of exhibitors onsite, and with the virtual attendance, many minute sessions around everything which is relevant or on identity around decent residency, Iran, cloud security, and related seams. So don't miss this event. It's not too late to register for seminar itself. From a housekeeping perspective, we are doing a recording. We will provide the slide X for dialogue. After the Butner, there will be a Q&A session by the end of the webinar and feel free to enter questions at any time.
So the first part I'll, I'll talk a little bit about the business, the impact, if I am and how to make I am trial, then the second part him hops. We'll talk about the benefits of a highly customizable identity management and how to make this work. So how to, to run this in a way that it doesn't bring you into problems with updates or when delivering sort of, and you code, et cetera. So how do you already make this Ferg in a seamless manner, even in complex environments and lots of pleased, there will be a Q&A session that we also will do a few polls and sort of the first question I'd like to raise. In fact, it will be two polls. The first question is about your current . As identical evidence had frustration to a permissioning last cycle management access governance is the same tool already based on a microservices architecture. So what you learn or is it more sort of a traditional awesome monolithic architecture? So are you modern Microsoft or traditional?
Okay. I think we can close the poll. Thank you very much for participating. We will craft the results of the poll during our Q and a session as to be able to do for that a second poll of a trial run before switching over to Tim. So why don't we look at this theme of why is identity management so important? Why is the Flex-a-Lite NC management so important? Then the point is start with this change business, this under change. And I think the last 18, 20 months have really demonstrated that. So they have all that already longer changed, like the digital business transformation towards that, the shift to, to cloud that operating models. But there's also a lot of Irene ovation, but you have also seen that there can be external effectiveness, which require businesses to change way faster than ever before. And the conflicts have to be digital businesses.
It also became obvious that we must see and beyond the representative management, we must make identity measure morale. We must do it differently. So identity management, definitely. Yeah. A bigger singer. I've now it's more than that restriction regulatory compliance. And it evolved over the years from, from, from standard disciplines like administration to governance, to consumer red, auntie management, adaptive authentication. Is that the end of the story? No, I don't think so. It will become even bigger because we must instance since then support all these sort of complex workloads and multicloud multicloud multi-hybrid environments. You must think about the identities of sinks and services and devices and relate to them and make all this work. So at the end, I think the point is when we look up that the current, the two gay situation, then digital identity is very much at the heart of everything we do in digital business.
I'm always a little capitalist, this term digital transformation, because I don't think we are talking about a transformation transformation would be from yeah, to B it's more Cherney. It's good. So we need to continuously innovate to get better and dealing with the digital identities of customers of things. Is it essential? On the other hand, you must enable these, the complexity of our it to, to be managed. And, and when we look at today's situation, then we have new applications. We have new types of deployment models. We have to evolve some national it, if you must secure all that, this dynamic environment, it's not that we say, okay, we set on a server and this takes us a couple of days or weeks, and there'll be configure every single Rhonda that this is stable for how long it is. Workloads are going up and down. It's continuous change, or we need to, to support this, we need to secure this.
And it's about who or what, which identity can do what it's about identity management. So we must do more. It's going beyond. And this is really the theme of digital transformation, where we have all these external impacts, like a fast changing competition competitors, no one expected, maybe a few years ago, many charm and automotive vendors, probably a couple of years ago, didn't expect Tesla to become a real competitor. We have different types of partnerships. We have the volatile regulatory environments. We have, everything is connected. We have, on the other hand, all of this cyber attacks, we have a huge risk. And so, so we need to be more agile and organization or flexible, more innovative. And that means we need to do things different. We need to change our, the way we are doing manufacturing. Everything is connected and smart manufacturing. We need to change the way we interact with customers.
We have to connect the things and all the stuff and everything is software in some way there software really keep, keep playing. That that means we need to manage that digital identity aside of several other technical issues is what makes this work. So we need an identity management that is more flexible to react, and which is also broader. And it's come up abilities many talks over the past years around also sort of the bigger concepts like at auntie fabrics that are attached to them in it. But to me, it's very clear, it's way more than traditional user life cycle management, dynamic provisioning. Even in these environments, likely have seen this, all the work from home challenges. You need to be agile and flexible to support what is changing. So are you ready? That's your identity management caterer today's needs. Is it that you're here and can say, okay.
Yes, cool. We are there. If not, then it's about modernization. Then you need to revisit your identity management. What are nice, very required. This isn't about throwing away into a completely new, it is about looking at what are your future requirements, tuition. Do you currently deliver to these? Do you need to reach change just to, you need to improve that? Can you short off a longer rely on what you have? where are your biggest gaps it's already going consistently and in a very structured through this broader picture, and that's thinking about what are the initiatives it each would take and how do they fit into a bigger picture, a picture that helps you to do what identity management needs to do. We call this an identity fabric. So how can you connect every one ever sing to every service? Doesn't this IDN, what identity management needs to do?
It you'll find it at our website, various talks, where I go, wait, print printed. The identity fabric seem that I can do in the short time I have for today's webinar. But at the end, what you need is you need to understand which capabilities you need. So the lifecycle management, the identity wetting, or proofing, finishing your relationships, Federation, privilege, access, having APIs, ready to work accounts. You also need to understand that this is the button at the bottom layer of this graphic. How do you support all your links? I see you build that. Usually you build that trust Morgan and you world has everything. Isn't SAS service, much. You have a legacy. How do you integrate with that? You utilize your existing identity management for doing so. On the other hand, you need to connect the top off the graphic. How do you connect to all the new stuff to the SAS service, to the digital service, and how do you upper left side of that center of the graphic?
How do we enable digital services to consume identity services to consumers, surface for registering users, for proving users, for authenticating users, for managing the identities for privacy, all that stuff. This is what you need to do. So you need services and you need a modern architecture behind it. This is the technical aspect into the traffic to do so. So it is from our perspective, it's essential to really today, step back and say, okay, I need in future to identify your calves, to create a picture, to add a model and to plan from there, step by step. So with that, the question is you got this so to speak, or what are some elements to really make this actual identity matters work. When I expect this to go alignment. So we have discussions with our customers very frequently about, is it a decision between on premises only or cloud first, or is there more, depending on the architecture and the solution you have, that might be also something where you have some flexibility, because if you go for what are microservices, architecture, container based deployments, coordinators, and stuff, you kind of run it in different types of clouds.
You kind of re even shifted from a to B. So there are options and you need to understand which options you have options you need to do. So, but it goes, it might be that you say, I go for pure SAS. So because this really is my needs a little bit less flexibility, but if some of your responsibility then to the provider or you go to something, in-between Tim, we'll talk about service layers, which is really more managed services approach this, a lot of support from the service provider. There's some more level of flexibility than, than pure-play assess. But at the end, it's important to understand you need modern architectures because they are the foundation for flexibility 18, what you're doing.
So it is really just technical architectural thing, which, which helps you in flexible deployments around it way. You need it so well while you might argue traditionally eloquently other functionality. I believe that's from what you could say, this is the non-functional feature, but I believe that the architecture aspects and the way you customize it, you integrate it. Orchestrate are really key factors when picking on modern, I am to enriching ever area of identity and access management. So it's about customization, understanding the need and there the role of customization. So are you scared about issues? We show customizations for not creating, you know, I think many of you probably have had this experience that whatever release 11 of the tool you have in place comes out and you learn that 65% of the customizations you have made or deposit 10 years, one Virg well released 11.
And you had that way to in a huge road trip for creating are various reasons for that credit. Many reasons why it might end up in that you might trust that use the API for trafficking. There might have been a gap in India, the number of API APIs. There might be many other reasons for that, but toward a future, you can do it better. And the, the foundation for is, and this goes back to, I talked to him quickly about identity API APIs, the identity API layer D interface, where you work against when, when building, for instance, different service, but also in customize it so far for customizing S and coding do it. You know, segregation pills are great. If you have a microservice architecture, many small services that expose interfaces, which are called API APIs, then you can do your new, your customizations. And I don't microservice.
So it means you have shown this a little larger trust before you have these APIs, often microservices, which are exposed to wise identity API, they are. And when you customize, you create another microservice, then you extend when you orchestrate, for instance, with your it service management, you create another microservice, which again, might expose API APIs, which then can be consumed about or services, but you keep it segregated. As long as the API APIs are stable and you even might consider abstracting them so that you can change the underlying thing. Notion as long as to our stable, you are in a quite good situation when it comes to upgrades and you make it small much Zillow, well segregated, easy to maintain, easy to change, easy to improve. So utilize this potential of modern architectures for what you're doing here and consider it something I'm not a big believer in the term, but, but it came up in the context of this discussion, consider something which might be called cutoffs productivity, a P auto terms. I think it helps maybe over time.
What I, what am I talking about? I'm talking about an approach, which says, so do you want to talk to Steph ops? So you have your development, you roll it out. You, you put it into production and for the entire environment, there's also an infrastructure management aspect. And if you bring in this, let's say I have infrastructure's code. I when developing everything, I also ensure that my entire infrastructure is set up appropriately. Then that term get offs can be used as upset. That might change over time. So that's an approach which is about develop, deploy, operate, and ensure that everything works well. And when I look at a reality, I've seen so many, many issues and, and incidents and, and identity management really about identity management, which just happened because there were changes and then some files were lost in updating or some configurations went wrong, starting to file configurations, et cetera.
And the infrastructure that's Siggis running, then, then it becomes clear if you can manage to combine that and to, to make it one consistent approach, which ensures that the infrastructure is always the one you expect to be the good at this, from my perspective, then should go even one step further. So you might have listened to this conversation about cloud infrastructure, entitlement management, it's about also securing that infrastructure. So how do you ensure that all of these runtime environments, your, your clouds, your, your Qubit, data successes, all that stuff is well secured. So how do you ensure that? I think we need to go a little bit bigger into something we see as dynamic resource tiled, access entitlement and access management. So go beyond the cloud aspect and go beyond just the infrastructure entitlements to secure everything, to secure for multicloud, multi hybrid environments. What can, who can do what these environments be?
The UNP, the service on a resource, on a system to integrate it, to automate it, to build a policy. So think beyond that, Rigo have a look at not only the technology of identity management, but talk with your dev ops. People, talk for your cloud people about how you can move to EMT created consistent approaches and that space that will be what brings you success. And for success, there are many elements it's not trust technology is way more. So when you look at key success factors for identity management projects, this slide would serve up an entire webinar for sure, but it is not just the tools or right insight or tools. It's the implementation, the operating model, the way you run it, it's on the bottom of the peoples, the processes, the policies, it's the planning on the left side, patching stakeholder and its requirements.
Understanding not only what you have in requirements, but also future requirements, potential regulatory requirements to ensure that your project is delivered on time and quality and so on. And, and agility and specific. I see eight factors. You should have a look at, which are your organization. So you need an identity management department, a powerful one in place. You need to have the right team internal, external when educated, you need to invest in education because there are not so many specialists there. And then you need to model, this is the fabrics, create your own fabrics picture or whatever you call it plan. So what is your article? Where do you start? What do you need to do first go for the operations model is sure that this really runs boot customize in a way to have habit, easy to handle this. Microsoft is flexibility and automate everything automate based on policies that will help you then to sort of build on your, your target operating model and concepts, call it, get ops, call it differently are what really makes this work. It's about integrating operations and customization with stats. I'm at the end of my part, I quickly want to launch a second poll, which has two options. So are you, I am twos primarily running on premises today, or as I that's this identity as a service. So let's launch a second poll. So just mix the answer between somewhere. So I'll fall looking for your I'm sorry.
Okay. Then I think we can close it. So with that, it's Amit to make Tim the presenter to most right now, we'll talk about the benefits of customized, simple identity measurement and how to make us for building on what I've set. So it's your choice.
Okay. Super. So thanks Martin, for, for the, the background there and the, the industry perspective on, on what we need and that, that dovetails perfectly into what I want to talk about. So I want to talk about I agile IAM as a managed service. So in between the, the Ida's and the on premises options that are traditionally seen as the only two options. So if we look at the, how would we solve these, these situations that Martin talked about? Many people think that ideas is one answer and something else is the other answer identity as a service or identity management as a service has a lot of advantages. Definitely. So it's very reliable and it brings you to market quickly, as long as you fit inside the use cases that are available, and the costs are very understandable and usually set up beforehand. So you can see what you're going to pay before you make any choices.
And if you want to grow into new markets, then that's usually very fast option to get into new markets or places that maybe you weren't operating before, but there are other trade-offs. If you go for an identity as a service offering, and in one of those is the flexibility that you have as a company. It's also the, the model of rollout or implementation of the identity as a service itself. And that's something that might be important to you, but based upon what Martins just informed us, having a good process behind the scenes really dictates how effective your business is going to be using that service, or how quickly you can respond to new opportunities or new technologies or new standards or new methods that you want to use. So we think that having dev ops get ops a process behind the delivery of the service is super important.
The, the other aspect there, which many people think about, especially in the beginning stages of choosing how they want to have identity and access management deployed, is am I going to be locked into one vendor or one implementation for a very long time? Am I going to need to revisit an entire project every couple of years? And that's something where the, the lock-in aspect is, is an important consideration. Are you locked into a particular approach or a particular technology or particular vendor, and how, how easy is it for practical? Is it to move out of that, that situation that can be not just a, a cost driven decision, but that can also be a decision based on acquisitions or growth, whether that's growing out of your existing system or it's acquiring new companies that bring a different technology or approach, and you want to take advantage of it.
So to look at this another way, or the reverse way, the, the, the traditional choice is do I have a product that I implement and him in the earlier days, we would say, oh, is it a product on premises? Of course, it could be a product that you implement in a cloud or a hybrid situation. But the decision here is really do you look for an identity and access management product that is extremely customizable and driven by a project to implement exactly what you want, in which case you have complexity to manage, or do you move or look towards a identity as a service option, which is very straightforward to implement and usually quite fast, but also has constraints or limitations depending on how you look at it. It means it's very standardized. It means the use cases are very well-defined and this is so that the identity as a service provider can provide the service level agreements that you want.
They can provide exactly the functionality that you're looking for. And if what you're looking for fits in Ida's, then that might be the right option for you. If what you're looking for doesn't fit, because your use cases are unique or more complex, then you'd need to look towards the other end of the spectrum and work towards a product based solution, whether that's a product on premises, or it's a product managed by somebody else. And that's where we think there's a real opportunity to have not just a product based implementation, but take advantage of the methodologies of as a service technology and create this in a custom fit way. So our approach to this, which we have implemented for several, several large customers, primarily in Europe, but also in other parts of the world is to start with the best of breed products. Some of those that, that you may know, tie this together with the infrastructure necessary to run those products, but supply this as code. So this calls back to what Martin was speaking about in the good ops approach of using declarative methods or declarative ways to decide what you need to implement for infrastructure. Then do the same thing with the configuration of the IAM product itself. So declarative configuration of the infrastructure declarative configuration of the IAM products, and then run this with automation so that you always have a, we always have a consistent way to bring the product, the infrastructure necessary for the product, with the configuration that you want for your use cases to market repeatedly.
We think it's very important in this context so that we don't lose out or miss out on any of the use cases that are important, that are critical for a flexible IAM solution. So that means there's a large list of capabilities with regards to the access management, the identity management, and also how this works within your company. The, the options that each organization needs are different. Some people are very focused on very strong authentication methods. Others are focused on the, the user life cycle on the onboarding and offboarding process. Others are very focused on how their internal employees will be servicing their own customers and all of those lead to situations where with it in high desert, an IDs implementation, you might not have the opportunity to have your customer service people be in the, the right role to help your users or your employees, whoever your, your end users are. You also may not have the same options for highly tailored authentication methods, and you may not have the options for different levels of authentication strength for internal employees versus external customers. And those are our more complicated scenarios that we think are very critical for enterprises. And, and in those enterprise situations, especially we're not dealing with a very straightforward or simple use cases.
Our perspective is everything is code. Everything is code fits perfectly into the get-ups paradigm. The get ops paradigm takes declarative configuration and applies it from a version control, get repository. So get even the technology, but it's source control and apply that declarative configuration to the implementation. In the simple sense, this means that you can start from zero with a cloud provider and apply your declarative configuration and have a running IAM system within tens of minutes. Let's say within 30 minutes, you can have your IAM product deployed with your configuration and ready to run. That might just be attractive from a disaster recovery point of view, but it's also very attractive from the point of view of bringing new features into your IAM implementation so that you can enable your business to now take advantage of these new features. It might be bring on a new Federation with a new partner so that you can market a new, a new opportunity to your users, or it could be that you want to change the configuration of your workflow for I am provisioning and, and therefore you want to be more efficient in an internal process, okay.
When everything is code, that means that it's super important to get that code from that that repository deployed into the real world, into a cloud provider or into a infrastructure and get the software running repeatedly. So it's very important to have a good process. The continuous delivery process is therefore in, in our world of identity and access management, not, not usually focused on writing code itself, but writing configuration. So we, we start the process on the left-hand side with the people and we, the people that have input into what the configuration needs to be. So that includes the customer or the client with developers. If there needs to be ad-ons or microservices is Martin explained that need to extend the identity and access management products, expert configurators. So people that know how to configure the IAM products to make it do, to meet the use cases of the customer.
And then of course, auditors security, everybody else who has an interest in how the identity and access management system is going to run. Once it gets out there and it's running all of these opinions, get codified and therefore put into source control, put in to get from there, there may things that are built for there may be things that are organized or packaged so that they're ready to be deployed. Test them before you go. If we, if there is a desire to have a release control or a release manager involved, then that's the checkpoint of the workflow before deploying into a real environment. The great thing about this process is that we can start it at any point. We can add new features at any time. We now have control over which new things get into source control. And also we have control as to which new things, new features, new capabilities get rolled out into production. It's not an all or nothing decision. It's a, it's a process that's additive. And we can add new things over time. When anybody on the left-hand side, any of these people decide that there needs to be a change in security or a changing configuration or an update of the product. Let's feed it into the left-hand side of the process. Let's run it through the packaging flow, test it before it goes, and then roll it out into a production environment. Okay.
Something that we've found very powerful is to package things the right way. And that means that it component based approach to enable a service oriented architecture. These terminologies are, are things we've that the software industry has embraced for a very long time. And it's something that makes a lot of sense. This fits perfectly into a microservices architecture. It's a question of how large are the components and how often do you want to deploy it? So from our perspective, creating components that have like concerns is important and having those components bring everything that he need for them to run is also important. When we look at a component, we don't simply look at the component from what is the purely functional things that needs to do a component may also bring along with it, the, the declaration of how it should be monitored. So not just how it runs, but also how do they monitor it.
It can bring along with it, how its logs should be output or where they should be output to the reports necessary to, to get data out of the activity of that component. So all of those pieces come along with a component and in our perspective, so each component can be one feature could be rolled out this way, or it could be a component that has many features that are enabled or disabled based upon the, the preferences or use cases of a customer. Each one of the components runs through the system and gets packaged and deployed. And we can change components as we need to this, that components can have different versions. Of course, it, there is the same situation as all microservices architectures is that there are, there's always, the question of are different component versions compatible with each other. This is a well-known problem in the microservices world, where having components that have compatible versions are compatible API APIs is a critical factor of your testing matrix.
It's a critical factor of your deployment. And the only question is, do you have the right process to manage it? So from our perspective, the, we run these things through the process of the pipeline and the deployment into modern architecture, modern technology. We use Kubernetes as our technology. Kubernetes nowadays is the orchestration software of choice for nearly all cloud providers. And it's, it's a very common architecture choice or orchestration choice for on-premise implementations too. So we, we embrace Kubernetes as the modern data center architecture and therefore take software that maybe isn't ready for Kubernetes, and we make it Kubernetes ready. And therefore we have a standard way to, to bring this packaged, these packaged solutions into a modern data center.
Once we have a methodology, we have a technique for bringing this out in one place. We now have the opportunity to replicate this, this approach in as many regions as are necessary and regions become necessary for, we've seen for primarily two reasons. One is for latency based latency based performance and, and making sure that people have good availability of their, their IAM components in different regions, and also have a fast response for those IAM components for the login process, et cetera. The other thing is regulatory restrictions. So in, in many regions in the world, when we talk about identity data, we have a lot of restrictions about where that identity data can live and where it can move. And in that case, it makes sense to respect the law of the countries involved or the regions involved. And that means there are situations where you want to have a repeatable process.
You want to have consistent functionality, but there are aspects in different regions where you may not be able to move identity data, or user identical identifiable data between regions. And, and those are situations where we recognize what's necessary. Here is a good approach that works in all the different regions, but also the flexibility to handle local authentication or local use of identity data for users so that you don't trip across any of these multi geography problems. The capability of having multiple geographies also leads to some side effects, side effects, include high availability and fully real-time fail over. And the ability to migrate from one region to another, because all of the regions are the same. These capabilities are these side effects of, of having this capability is really great. It means that conversations about availability and disaster recovery are much easier conversations because it's already built into the system.
So just for a moment about, about what we've created, we're in production with a number of different customers. We have the identity and access management products as the core to our offering. We wrap this with our methodology, for build and, and deployment. We add some custom features along the way. I think anybody who has experienced with identity and access management deployments has recognized that not everything you want is in the box with the product. That could be something as simple as the report that you want isn't available, or it could be more complicated regarding a feature that you need to create, or an, an addition to the product that you need to add via a plugin or other method. These custom features are it's important for us, that those custom features get deployed and managed the same way as all the other components. So from our perspective, it's, it's super important that they all follow the same flow.
So everything follows the same, get ops flow, the same componentization flow. And those custom features are different components for plugins to the products that we've constructed a way to plug them into the product so that we keep the same product. We plug in the feature and we deploy it using the same methodology on the right-hand side, you see two other important aspects, the security, the security aspect, which needs to be implemented at all steps along the process. Security is important from the very beginning as to which features you're going to choose. It's important during your testing phase and your deployment phases, so that you have an eye on security at all aspects. So this is, this has become popular or popularly. The popular term for this is in the dev ops world is DevSecOps to embed the security, not in the development flow or the operations, or as a gate at the end, but make security part of the entire, the entire process for creation and deployment of your identity and access management system.
And then finally, let's not just talk about the day one it's implemented, you're live, and you're done. Let's talk about the monitoring and the operations of the ongoing system. And this is something that in traditional traditional rollouts or traditional deployments of, I am, the, your IAM partner is involved during the first phase of gets you live. And then after live, in many cases, they're done and they, they leave and now you're left to operate the, the system that was built. And, and that day two questions then are up to you and up to your team to now develop, how do you monitor the system? How do you operate a day to day? How do you scale it? How do you ensure, you know, all of your scenarios are going to work with regards to availability. Your SLA is for, for that and your disaster recovery scenarios.
So we think that's an important aspect that also needs to be, let's say, shifted, left and built in from the beginning. Let's not just build a component to build a component that has a method of, of monitoring a method of operations with regards to policy on scaling policy, on fail, over and backup. All of those should be aspects built in from the left and they carry over to the right, and then it, your entire system is practical to operate and feasible to operate on an ongoing basis. We take all of these and we deploy them usually into a cloud provider or on premises for some of our customers. And as I mentioned earlier, all of this is on the Kubernetes platform. So whether that's I have the three cloud providers, the three main cloud providers listed down below AWS, Google, and Azure, and those cloud providers all have an offering for managed Kubernetes clusters. And we have some customers that run their own Kubernetes clusters, either with a partner or themselves. And that's just the technology for the data center.
So to look at this a little bit differently, Kubernetes or open shift on either a bring your own cloud infrastructure, you provide the cloud provider and this type of deployment goes into it. Or we do that for customers too. So we manage an entire cloud infrastructure, the cloud accounts and everything for some of our customers, or if you're already savvy in Kubernetes or open shift, and you're managing that yourself, then that's the data center, that data center technology that we think makes a lot of sense. So we'll the identity and access management solution and put that into your Kubernetes environment because of the nature of, of supporting a, let's say, a standardized orchestration for the data center. That means that the in multiple regions is very attainable. It means that a multi-cloud strategy is not, not the same kind of problem that used to be in the past for the same type of same level of effort. So it's a lot, it becomes very practical to deploy whatever your I identity and access management solution needs to be all the components that you need, or the different offerings from an IAM vendor to deploy those into multiple regions or deploy them into different clouds at the same time. Those become very attainable when you're using a lot more standardization on the technology side.
And after talking about technology this whole time and about, you know, the flow of, of building components and putting them into deployment, let's talk just a moment about the delivery model. It all comes down to people and it all comes down to how are your teams involved during the, as we call the initiation phase and also during the managed service phase. So in the beginning, how are your teams involved with having their input into what is necessary for the identity and access management system, functional and nonfunctional requirements. We work with the teams very closely here. We have some customers that want to be extremely involved. So they are committing a code they're committing configuration to the, to get, which gets deployed. We have other customers that want to be less involved there. They want a service provided to them as opposed to being part of the team of deploying the service or part of the team of getting this running.
We find it very useful when customers are involved in the entire flow. That means that your teams are up to speed. That means they know how the platform works, and they know how to use the platform to make, to make it do what they want to make them able to achieve the use cases that you want to have deployed. And then after let's say the platform is running and now you're, you're live with your initial use cases. And your initial features. Now the teams understand how to add new features, how to add new capabilities and how to flow them through the platform and the process of deployment and get them supported by, by your readiness organization. So that has to do with not so much the operation of the platform, but it has to do with how do your helped us or customer service people interact with the platform with regards to do they have the right reports? Do they have the right logs? Do they have the right access into the, to troubleshoot any issues or to help users through the, let's say the end user flows or the login problems of things like that. So the, the people behind this are extremely important. It's not about replacing people with technology. It's about taking advantage of the technology. So the people can be more effective in what they want to do.
What we provide as a managed service is an IAM platform using best of breed products. That's ready to run. We manage the release process, or we help a customer manage the release process. We also ensure that products get updated product. A new product releases are ready for the platform and ready to deploy. We ensure that everything that is deployed is managed from a security point of view. So this is a, an operational concern that is very critical, especially in IAM, where we don't want to have vulnerable versions or vulnerable components out in the wild. And so that's an important and ongoing process of keep things up to date from a security point of view, but also keep things up to date from a functionality point of view, we provide as much customer access or as much access to the running systems as, as you want, or as a customer wants.
So with an identity as a service offering, many times do you don't have the, the access to the backend, the direct access to what's happening on, on the machines or on the servers or whatever you'd like to call the, the virtual components that are out there in your cloud provider. But that's something that is very important for some customers to get under the hood, to see what's happening on the inside of the identity and access management system to really get their hands dirty, if they want to, or keep their hands clean and have it be somebody else's system to manage from a tool chain perspective, we really focus on using new and modern technology. We think that it that's extremely important. It keeps us up to date from a skills perspective. It also keeps methodologies fresh. And it also means that overall we're never satisfied with what we're using, where we, we see that the tools we're using today are the appropriate tools for today and new tools come out.
That might be more appropriate tomorrow. And the, the biggest thing about our systems is that, or that the platform that we've we've put together is that the platform is continually changing and evolving. And this is a perspective that not every customer is willing to, or is happy to, to internalize, but super important to recognize that there is a consistent rate of change that should happen in your implementations and in your identity and access management and in your normal it operations embracing that change and taking advantage of the new technologies, new approaches that come out, we find is very important. Having a very collaborative approach to running the entire platform. Customers have great ideas. We have great ideas. The industry has great ideas. Let's continue to use the best of those ideas tied in together in a cohesive platform that enables what we want here. And what we want is just to support the business.
When the business says, I want to have a new functionality for my customers. I want to roll out a new web store. I want to we're in the middle of a pandemic. I suddenly have a, a, a need for everybody to work remotely. How does IAM support those business drivers and how can they respond quickly? And having a methodology that changes consistent and change always happens and change for the better or improvements are always necessary, really helps enable the whole platform, the whole tool chains, the whole pipeline to, to be responsive. And then the last two things on the bottom here are with regards to, let's make sure we're doing a good job. So let's not just do what we think is good, but let's also measure what we're doing and ensure that we're, we're meeting the measurements and the expectations for ourselves and also for our customers.
And with regards to let's have the right reports in place. And if we don't have them, let's create them. Let's make them part of the platform. Let's not create custom reports for every single customer and let's create reports that can be reused or that are, are very important for, for everybody. And of course, that doesn't mean don't create custom reports or don't create custom functionality. It means that whenever there's an opportunity to generalize functionality and have many opinions go into a stronger core capability, we take advantage of that. And then with regards to availability, we, we measure ourselves on a 99.9, 5% availability. And this is based on the, the five nines capability of the cloud providers or four nines of the cloud providers. And once we have multiple layers of that, there's no way to meet a 100% availability, but we do pretty well. And we're really happy with the, the ability that we have to keep our systems running all the time, have them always be available for hundreds of thousands of employees logging in every day or for millions of, of consumers on the internet logging in every day. That is something where we're really pleased with and we have a good track.
So thanks very much for listening. I hope this has given you some ideas of how it can be done. So a lot of the, the things that Martin talked about earlier, these are not just approaches that can't be achieved. We achieved them today. We achieved them with customers in production who have many, many happy users, and the customers are very happy visit our website and, and, and see who those customers are. And we're, we're really glad that we've been able to, to achieve some of the goals that, that it seems like Martin puts out goals and he says, well, this is the thing that you should look for. And we, we look at that and say, well, that's a, a great, a great thing to strive for. And we hope that we've achieved some of it with the, the offering we've put into place over the last few years.
Thank you, Tim. Very, very insightful talk. Yes. All trumpets I list is to raise the bar, isn't it. But I was thinking of guidance on, on where to go from where you are today as a customer. And, and I think it's really, we are in a transition phase of identity and access management, and I think it will be a little hotter, sings, more policies, broader perspectives. And this will be very interesting over the next couple of years. And so it's really time to step back and look at what is my future perspective and identity management. So let's go to the Q and a,
Okay. Oh yeah. Sorry, Martin. Just on that comment, I was going to say that I find it interesting today that we talked less about particular features of identity and access management. And we talk more about how do you get it running and how do you manage it over time? Because it's, it's more of the, the ongoing concern of IAM is interesting or important than the do we have certificate authentication, right? Th those very point specific features. And
I think that's an important part, you know, I've, I've, I'm talking as an analyst before, not in a follow life, so to speak of the shortlist of winters for so two years or, or so. And one of the important learnings I had is that editing a feature is relatively easy, changing the architecture, if you did it wrong, that is the big challenge. And I think it's, you know, when you make a plan, when you have a blueprint that you can do a lot of things as in that, and this is I think, so it's really essential to really start as to planning because every, every dollar you spend for a good planning and then creating a model and selecting the derive technology pays off multiple times and it goes wrong. If you do it the other way around, if you trust staff as a tool.
So we have very little time, I think you already answered some of the questions for if you like, like auto dealers, product updates, and also you talking about the organization. So what I'd like to do is I'd like to have a quick look at the results of the first poll we yet, and maybe we can't display these because I find them quite interesting. What you're seeing here is really that roughly four out of five still are relying on traditional identity and access management architectures compared to modern microservice container based deployments. And I think this shows quite well to the current situation. It doesn't mean that you need to change immediately over the next time, but when you look at updates, when you look at new investments, then you should think about what does this cost, what is the right architecture to do so, and maybe you also can go directly to the second poll,
But this, this result here is interesting because it, to me, it really shows that we as an industry, we, as the customers need to put more pressure on the traditional vendors to, to move to new approaches because the, the rest of the industry sees that microservices have a great, a great opportunity. And it's really, I think, difficult from a vendor perspective, when you have a monolithic product, it's hard to decide how to break that apart, because you don't want to sacrifice the reliability you've given to your customers for years. So
You benefit as a winder. I think that that's true and it's addressing, I think probably three years ago or so when I did my first talk about microservice and identity management, right after us, a couple of vendors approach that I, what does it mean to me? And so I, I would actually say it's not that much about pressure to my interest because I believe probably all the vendor stuff just stood it well, but it's a journey to move from a traditional product to modern solution. So for the of poll, I think we have a, also an interesting split. We have relatively few, which are pure, pure IDAs already, and that we have sort of half of the rest that is still only on premises DNRs, which have some parts. All right. I would assume that mostly it's more DD access management piece and all the syndication pieces, which aren't an itis already. And again, it's a Charney, but I think it's always important to understand this is a chart. And I said, we can cut, remove to the results here and then yep. I think that is a situation.
Yeah. My take on that. The results there. Yeah. Makes sense. I think the choice for many people is somewhere in the middle of, of Ida's versus whatever the alternative is. And the alternative seems to be IDEXX versus on premises. And those are two extremes of, of, you know, of a balance between where are you comfortable putting the data? Where are you comfortable operating, whatever it is that you've chosen. And what are your opportunities for operating your, your software in either yourself or via somebody else or in a cloud or off the shelf from an IDEXX provider.
Okay. Unfortunately, we already have time. Thank you very much, Tim. Thank you to all the attendees for listening to the Coco club and our hope to see some of you onsite in Munich next week, or at least in the online life transmission of the UN all the conversations. So don't miss that event. Talk to you soon again. Thank you. Thanks Martin. Thanks everybody.
