I'm pro from w so two, I've been with the company for almost 11 years and mostly leading the w so two server w so two is a company which produces set of open source products, all released under the most business friendly, a attachable license. The company was founded in 2005, so it's 13 plus years now. And we have offices in mountain, new New York, London, Sydney, Sao, and the R and D center is in Columbus, Sri Lanka. So we have about 300 engineers. So we are heavily injured driven company as a company. W so two focuses on four main areas, API management, integration, I aim and analytics.
These are the four key areas we believe that would help you in building your journey towards digital transformation. Under API management, we have w so two API manager then integration the enterprise integrator and analytics extreme processor. And then on IAM, we have w so two server. So a service is being used by many fortune hundred and 500 companies. And most of our deployments, like I would say, 90% of our deployments are customer facing. So that's what qualifies us to come here and talk about CIA.
Okay.
So the major goal of cm is to drive the business growth or the revenue by leveraging ID data, to acquire and retain customers. It'll build an centric ecosystem, which helps you to nurture and anonymous user to a, to a well known loyal customer. So we have come across, like we have passed many faces and today at the age of customer ID is the glue for all contextual marketing, right? So in doing that in our journey towards cm, we face multiple challenges. It all starts with an anonymous user where we do not have any clue about, but wants to like consume our services.
So at least interest about our services, this particular person would visit our website and may just may just explore the options there, right? So then we may use like marketing automation products to capture all the interactions. So we capture all the interactions and store them and under different data sources under corresponding products, and probably correlate to the user set of session identifiers.
The next phase is this guy would download a white paper or probably register for webinar or a workshop.
Then we get to know about this particular user, and that data will go into another CRM system. Then after some time, our sales team would probably talk to this guy and sell some products. Let's say we sold an insurance policy. And that data once again, which includes all the purchasing information and PII data of that particular user would probably go into another CRM system after that. So we sold an insurance policy, right? So he needs to do payments, right?
The, the, the monthly premiums. So he has to come back to our customer Porwal and register as an online customer, right? So in doing that, he has to enter all the, all his PI data and maybe like the, the policy information door stuff. And those things will go into our IM system.
The IM system will talk to the correspondence CRM system and verify that that data is correct, or it's the same user who we sold the insurance policy sometime back is the one who is trying to register now. So after that, if everything goes fine. So we onboard that particular user as a customer.
So this is a typical workflow, how we onboard customers, how we nurture a customer from an, a user to a lead to a, a well known customer, right? So there can be multiple variations, like multiple other flows as well. And we may use multiple channels in onboarding customers. So when we have multiple points of connections, ORs, or multiple channels, so that leads into another problem. We create multiple data silos. So we create multiple data silos where none of those talk to each other, right? So we have isolated data silos.
So 52% of marketing leaders who are responsible for data analytics, they find the most challenging problem, or the most time consuming problem is to do data integration and data management, and more than one third of marketers.
So they find the, the most challenging problem. The analytics team faces is to this, do this data integration. So this is a real challenge. We need to find a solution, then the protect team, consumer data at large scale. So unlike in workforce, I am in, in cm, we work with millions of users, right?
So we, we, we talk a lot about privacy in this conference to itself. So you need to worry about how you securely store the personally identifiable information of millions of users. And how do you preserve the privacy of the personal PI data of all these users? So that's another challenging area we need to worry about in addressing these challenges. These are the primarily main areas we need to focus on. So we call this five pillars of C
60% of digital transformation projects. So they all start with integration.
So cm, in fact, it's not just a product, it's a solution that you build, right? So when you build a CIM solution, you need to integrate with multiple components. So these components can be the it management, then data analytics, same solutions, then CMS customer data platforms, data management platforms, and proofing services. Then e-commerce platforms. There are so many components, right? So we need to worry about how we integrate our CIM solution with all these components, right?
So key enabler for integration, the APIs, all these components in your CIM infrastructure should expose their functionalities via APIs. Otherwise it'll become a nightmare to integrate those components. So having an API is a key factor, and also the components in CRM system should also be extensible, right?
So when, when these components are extensible, we can extend those components and talk to other components.
We are APIs, right? So ultimately we build integration between these components in I, in our cm solution, we are APIs, right? So now we have components talking to each other, then ultimately we need to expose this functionality to the rest of the world, right? So we need to expose this functionality to the rest of the world, through presentation layer. That can be your web. Porwal a native mobile application, maybe the API itself.
So most of the time, the pick APIs to expose this functionalities outside. So we have an API inpatient internally, and also at the edge, we expose CIM function and through another set of APIs. So we need to worry about edge security. How do we protect our APIs at the edge? And also we need to worry about the service to service, communication, how the components interact with each other. So this is another role of IM in the CIM.
So, so this, this role may not be visible the end user, but underneath, this is something you need to worry about. You need to protect all your APIs and IAM has it all to play there.
Okay? So when you deal with millions of users, right, you have no option, but to worry about scalability, right? So there are two traditional ways that we worry about scalability. You handle scalability. One is we horizontally scale our system, right?
Sorry, vertically scale, our system. And the other one is horizontally scale our system. So when we horizon vertically scale, our system, we add more computational power, more memory, power to our service. Then to horizon scale, we add more and more service, right? In either approach to decide the level of computational power we need to add. And the number of instances we need to add, we need to worry about the load, right? So the load could be like API request or the authentication request, authorization request altogether. Most of the time we worry about the peak load.
So we, we, we, we, we estimate the average load and the peak load.
Then we worry about the peak load. So we design our infrastructure to cater the peak load. So if we have system, which is fine with the peak load, it is, it is okay for any other load. Right? But what we find in a CIM system is there's a huge difference between load and the peak load. So we recently work with a customer in Brazil. We is the financial sector with few millions of users. The average, average authentication request, the load is around thousand 700 per minute. That's the average load, right?
But two days in a month, that goes up to 350,000, right? So from thousand 700 to 350,000. So if we build a system which is good to handle this 350,000 requests per minute, we are wasting a lot of resources and it's not a, a good economic solution, right? So then we need to come up with a better approach.
So that is autoscaling. So you need to worry about auto auto scales. Auto scaling means your systems should know how to scale automatically based on certain load parameters.
So there are different approaches to do that, but in the, in the, in the recent past, what we have seen is most people are moving to container based deployments. We've been talking about Docker containers for some time now, for few years now, but now we see people starting to realize the value of that and starting to implement. And also we see this container native technologies are measured today, so they are ready to use in production. So you can, autoscale your system with, with containers, maybe with Docker and using ES as a contain orchestration platform.
So this is a trend we see in our customers. Then the, the multiregional deployments, there are true two drivers behind a multi-regional deployment.
Why we need to go from multi-regional deployment. One is the availability, right? So you cannot like, if you really worry about scalability and availability of your system, you cannot just deploy your CIM solution. In one data center, you need to worry about disaster, recovery and door. So you need to worry about deploying your, your CIM solution in multiple availability zones. The second factor is performance, right?
So, so it it's been found that like, if it takes more than three seconds, a load of website, the end user will give up. So you need to worry about putting your data as much as closer to where your customers are or are the data being used. So that's the other reason why we need to go for a multiregional deployment. So what's a challenge we find in multi-regional deployment. The key challenge is do the data application. So doing a, doing a, a multiregional deployment, we need to worry about the master master application, right? So there are maybe multiple, multiple places where data gets updated.
So how, how you, how you replicate and sync, right? So that's the most challenging part we see in our customers and at data level that is support. Some solutions are costly. So post supports multi master application, but with some external solutions and AWS a so they're supporting multi master deployment, but still at the preview stage. So it'll be soon NGO. So you need to worry about this stuff.
Then the strong and adaptive authentication. So we told a lot about this today, right? Multifactor authentication options for cm and Fido.
But if you look at last few decades, right, and maybe for centuries, we are still struggling to get rid of passwords, right. For so many times. So we have come up with a lot of smart solutions, but why is still people using passwords? Why it's really hard to get rid of passwords, right? So when you build identity server for the first time, the first version was recent in 2007, it only had information card support, right? So information card is a standard put forward by Microsoft to, to get rid of passwords and handle phishing attacks.
But they had to give it up because it, it introduced a new authentication paradigm and people didn't get used to that. So people really find hard to find more usable, second fact options.
So hopefully the Fido and web authentication will get there, but still, I guess we are not there, like at the mass market, we are still not there. Right? So due to that fact, like, because people are still using and passwords, we are seeing that are led to many account compromises and data breaches, right? So in 2016 itself, 80% of the data breaches resulted because of weak passwords, right?
So just by using MFA, it could reduce the account compromise by 99.9, 9%. But the sad fact is in Google, you have multiple ways of enabling second factor. It supports five U, two F Google authenticator, which is the T OTP implementation and OT P O SMS. But 90% of Google users, haven't enabled MFA. That's a sad fact, right? So that means when you decide an MFS solution for your cm system, you need to worry about you, you, you need to worry about the usability in additional security.
You define the right balance between security and usability. Otherwise people won't use.
So that is why still the, the OTP based on SMS is the most popular option. Even though that is not the recommended one or the, the secure adoption, right? People go for the more usable options. Then beyond MFA, we have adaptive authentication with adaptive authentication. You get the control to, to design the login flow based on different contextual parameter. It can be based on environment variables, environment, parameters, like IP address, and do geolocation based authentication. It can be based on user behaviors. Like you can do geo based authentication.
And then you can do that based on different like attributes, user roles, like for a given CIM system. It's not just the, the customer is not the only audience, right? We also administrators. So administrators also need to log into the cm system. So you can enable, you can have like Fido or RSS CQ ID plus password based authentication for administrators and maybe for the consumers, password and OTP, SMS, or web authentication. So you should be adaptive authentication. You can define different authentication flows based on contextual parameters
Analytics.
So when we, when we build the integration between all the data silos, right, when we, when the components started start, started talking to each other, then we can build the analytics on top of that, right? To build unified user profile in analytics, we need to worry about three areas. One is the batch analytics. The other one is real time analytics. And then the predictive analytics and the batch analytics, you can find out statistics like the like historical data. You can find out how many leads that you got for last month.
And what's the, what's the rate of lead generation, how long it take takes to convert or nurture and a user to a lead and then to a customer. So those statistics like business level statistics can be gathered by batch analytics. And also you can gather analytics later to security tool, like how many login, success items, fail items, those stuff. Then you can use realtime analytics to strengthen the security of your system, right? So you can, you can leverage your realtime analytics with fraud detection, systems, risk engines, and make your system much secure.
The predictive analytics helps you make more better informed decisions for the future. So it is, is another area we need to worry about when building cm system and the components, all the components in your system should have the ability to push data to centralize analytics system, a SIM, or a user behavior analytics system.
Okay.
Finally, the secret and privacy. So this is the most discussed area, I guess, in the conference so far. Right?
So, so it doesn't, it doesn't make sense. Like you have the, like the most robust, globally distributed high performant CIM system. If you don't, what about worry about secret and privacy, right. A secret breach or a privacy breach has a direct relationship, direct impact to your revenue, the stop price and the customer interactions. If you go back few years. So Yahoo had several data breaches, right? Privacy breaches, the, the PI data of more than a billion Yahoo users were exposed. So that had a direct impact on Yahoo sales price when it was acquired by Verizon sometime back.
So they had to lower their sales price by three 50 million, just because of their privacy breaches. The, the, the perception created because of the privacy breaches.
So that's an area we need to worry about then GDPR, even though it's an U based standard, it's impact is global. So everyone now worrying about GDPR, and also it has catalyzed many countries and states come up with their own privacy regulations. So when you build a CIM system, you need to worry about the privacy regulations of each and every country and respect those, then the consent management.
So this is once again, another key highlights of GDPR. You should never collect, use a P I data. If you're not going to use them, never collect them. If you like, if, if you have any plans to use this data for the future purposes, don't collect them.
Now, collect them only when you need that. So that's where the, the progress you're profiling comes in. And also you should clearly specify why you collect this data. So you should declare the purpose of data usage.
And also you should give the control of PII data to the end user to do that. We need to have consent portals, consent management portals, so where the users can log in and rework the given consent, and also request to not to process like hold the processing of data and also request to remove all the PI data.
So, so this is one very challenging area, right? So you have multiple components integrated, right? So you have data platforms, systems, how do you, how do you make sure you help you maintain PI data centrally? So one approach is you keep PI data only under the IM system and refer to that PI data through P you would never publish PII data to your analytics system. You will just publish a pseudonym and in and IAM, you will create a mapping table, right?
So when, when you build analytics through the, through the analytics system, then you build that against pseudonym.
Then use the mapping table to build dashboards in a meaningful way. Right? So in case the customer asked to remove all the PII data. So that's something right for the customer GDPR, right? To be forgotten. Then you need not to worry about cleaning all the collector systems. You only need to remove the mapping in your IEM system. So mapping to the particular PII data to the Saudi. So once you remove that mapping, the rest of the data become a right.
You cannot, you cannot, you cannot correlate this data to find the found an identifier related to the user. Okay? So this is the, the whole summary of the talk to iceberg tip of the iceberg is the consumer experience, right? To build the iceberg. You really need to work hard on building or work on this five pillars. Thank you.
Thank you.
