Leveraging Rapid Application Onboarding to Accelerate Digital Transformation

Speaker 1:  I'm going to hand it over to Brent who is the practice lead for Okta Identity Solutions at Accenture.

Brent:  Thank you.

Alright, thanks everybody. Great crowd. Glad everybody could make it. Hope everybody got to see the keynote this morning. I think that's always exciting to see what's up and coming in the Okta product suite. 

So today I'm here with all of you. Excited to be here. This is my second Oktane and I'm a Senior Manager in Accenture's digital identity practice. I'm also our global Okta-Alliance lead. So I'm tied in with the majority of our Okta projects across the world and have insight into what's going on with most of those. Today I want to talk a little bit about digital transformation and what it means next generation identity and access and what are the implications of all of this with your application on wording program. 

So digital transformation. That's kind of a big topic and who here has seen We're the Millers the movie? Kind of funny. So at the beginning, David's sitting there watching a bunch of YouTube clips and here's a picture of one of them where the guy is at Yosemite and he sees the double rainbows and he's eventually so awestruck he just exclaims, "What does it all mean?" And I think that's at some point when you get into digital transformation, you start asking that same question because there's just so much to figure out and... Why's it happening? What are all the changes that are involved? Etc. 

You know yesterday in our partners session, Charles Ray said some nice slides showing the progression of farming from the subsistence days all the way through the industrial scale and his point was going from very low survivability scale all the way through the large scales that are in industry these days and I think the other aspect of that as well is in those machines, people used to sit in those and have to drive them and watch everything that's going on. And now there's GPS, there's auto-steering. So those machines are basically driving themselves at this point. And in a few years, they're going to be autonomous. So it's kind of interesting to see how something like digital transformation is still making changes in like a farming industry that's been around for thousands of years and now it's changing again because of this.

So if we look at our history for the past several years, its kind of fun to see what's happened with our major technologies from the 50's through today. For the elderly in the crowd, including myself, it's kind of fun to look back and see some of the key events that we remember as we started getting into technology. You know one of the big ones for me was '91 when the internet became mainstream in the public. Shortly after that, I was in college and the first commercial browsers and stuff started becoming available. So watching all these things progress and being a part of it has been something that's been amazing for me to be a part of and I'm sure for the rest of you and for all the things that you've dealt with as well. 

But as we move to the right, we have to ask ourselves, what's caused the spike in innovation and change and there's this rapid acceleration and the rate of change in a short amount of time. Because we've kind of had these slower curves coming through but now here, we're at the point where we're into this whole new era of this transformation. And you'll hear people talk about the digital revolution and some people don't think it's quite here yet, but I think if you look at this, it's pretty convincing that it's definitely in flight.

So what's driving all of this? Unfortunately, there isn't a clean answer. There isn't one single thing that's causing all of this to happen. There's been debates on what are the most important three or five things that's causing digital transformation and there's just a lot of stuff. I mean, in the old world, with the old legacy systems, you had to be an expert in a handful of technologies and things. And now with digital transformation, we've got so many things that are changing and so many new innovations and technologies. It's honestly hard to keep track of it all. Things with our infrastructures moving into the cloud, the explosion of mobile devices, our reliance on API's and the whole API economy. And then how we're starting to now leverage AI into robotics to reduce our reliance on manual labor for repeatable tasks.

Then as all this is changing, we have to ask ourselves, "how can we leverage this innovation and take it back to what we're working on in our day-to-day lives?" So with identity and access, we're kind of moving into the next generation of the capabilities. In the old world, we would have a project that would consist of 4-8 months of just deploying infrastructure and getting the core service up and running. And during that time, we could sit and figure out how we're going to start and initiate our application onboarding track. So we had a long runway to figure some of those things out. So we could come into a project, start with the project infrastructure piece and then knowing we had some time, at least 2-4 months to figure out the rest. 

Now, that's all changed and digital transformation has forced us into this pivoting into this new model that user expectations are driving the business to react faster. The business has expectations to deliver more capabilities and value to the consumers and users very quickly. So now when you come into and identity project and land on the ground and starting running, you don't have a runway anymore. You're basically taking off very quickly and your scale of time has now shrinked from several months down to weeks and days. So if you don't come prepared with that application onboarding track right off the bat, you're gonna be in trouble. So you have to land with knowing how you're rolling out the foundation and then having the application onboarding program ready to go right away. 

So if we look at a typical IAM implementation approach, the approach itself is still fairly consistent with what we used to do. You roll out the foundational product, you do the baseline configuration, and then at the same time you're starting to look at the application inventory, defining the pipeline, what applications can integrate with which standards, etc. And then you start getting that framed up, but once again, the timeframes are so much shorter now. Your foundational configuration is gonna be down to weeks, sometimes days, depending on how quickly you can roll it out. And once you're past that, the thing that's going to drive the most effort and complexity from there on out is your entire application onboarding program. That's when you get deep into the weeds with potentially thousands of applications and the client environment. Some will be fairly easy to integrate. You'll have some little hanging fruit with the cloud apps, things that support standard such as SAML, OAuth, etc. But then once the easy ones are done, then you get into the harder integrations where they may not support the new standard interfaces, they don't have APIs, etc. And then you have to start if you really want to onboard those, you have to get creative or down the custom road.

And I think another important piece of the onboarding program is really defining when you're actually done an integration. Because there's so many different options to integrate with now. With single sign on, you can get them integrated with SSO, MFA, etc. And then that piece of the integration is done. Then you have to continue on with provisioning, life cycle management for the user identities. And then also if you have a governance capability as well, and you're doing certifications, attestations, things like that, that all has to be integrated as well. So the applications may be in varying states of done, but you may not be completely done until all those things are actually integrated.

So how do we get to a place where we can actually do this effectively? So we basically need to come with a factory model or framework that we can leverage to do these things repetitively and consistently over and over with the whole inventory of applications. So we need to bring this with our program to show how we're going to work with the application teams, if they have additional development teams, service management organization, project management, and then also showing leadership how things are tracking. So you have to have the full breadth of the technical capability and also the project management. You may have to get into change management and communication and awareness with all the teams that are involved as well. So it's a full cycle. You can't just have the technical capability and leave all these other things off to the side or else you won't be successful. 

So why do we need an integration factory to begin with? Well like we're talking about with digital transformation, one of the key points earlier today in the keynote was that in our old world, we had a handful of applications we were dealing with with integration. Maybe 10-20 were the key apps you had to bring onboard with the system. Now most businesses are in the tens, hundreds, and the larger enterprises are up into the thousands of of applications that need to be integrated. So if you try to apply the old methodologies where you just pick a couple here and there and bring them onboard, you're basically gonna be doing it forever. So we want to do this to scale and maintain a high rate of pace to bring things onboard and that way you can start to leverage your investment with the identity product because if you just have it sitting there and not doing anything with your other integrations, it's basically just a waste of investment. 

So predefine integration patterns, those are extremely important so you can do this repetitively across each application. Leveraging standard workflows, integration catalog, things like that. So all of this combined helps you achieve speed and efficiency so you aren't reinventing the wheel with each application. You know how you've done it. You've got the pattern and you're just repeating this over and over. 

So integration patterns are key. So this is something that we spend a lot of time on and it's not just with Okta, it's with any identity product that you're going to deploy. You have to have integration patterns defined. So if you come in and just say, "well we're just gonna onboard all that stuff, but we don't know how." Well that's asking for trouble. So we come in, we have a cam set of architectural patterns. So if you have applications and X number are going to be cloud-based, you have patterns for that. You're gonna support SAML, OAuth, OIDC, etc. You have the high level integration that you can give to your application teams and say, "at a high level, from an  architectural perspective, this is how these work." When you're gonna do SAML, here's how the token exchange, things like that, we'll go back and forth with your application. 

And some applications, and third party apps will support this out of the box, they have the capability to just [inaudible 00:12:40]. If you start sending the tokens in and it just works perfectly. Other applications were never built, or home grown applications, never had this capability built into them. So that's when you may get into the scenarios where you have to interface directly with the application dub teams. That can be challenging sometimes. The products that have been in the environment for many years may not even have an application team that's left on site that knows how the application works and that could be challenging to get people to actually crack open that code, if they even have the code to make those adjustments.

So to help ease some of those burdens, you come in with the application integration templates that shows if I have, lets say a Spring Java application, here's how you could potentially integrate with the Spring SAML plug-in. Or if I have an Angular JS app, here's a code snippet or sample I could plug into this that will make you SAML aware or can leverage OAuth API's, etc. So you need to bring all of those examples into that development team because you can't just tell them, "hey you're gonna use OAuth today." If you just tell them that and let them go on their own, they're probably gonna fail. So you need to give them clear guidance and examples of, "if here's a code snippet that we know works with other applications, let's see if we can make it work for you as well." 

And also, when we get into provisioning, that can be tricky. Just because we're in the cloud now, some of the older challenges that we've had with on-prem products have not gone away. With Okta, we can very easily set up provisioning with anything in the cloud that they've gotten oracle application network. And then if we're doing group mastering into AD, I mean those things work fairly easily out of the box. Soon as we get back into the on-prem world, then we're back into using the on-prem provisioning agent, leveraging SCM with that protocol. And then if we have other legacy applications sitting inside the firewall that already are leveraging at database, maybe they're in AS400 mainframe, some of the older stuff that Okta is not going to connect to out the box, then we get into some custom connectors if needed. But that's where some of the... We're trying to leverage some of the digital transformation innovation that's come about and starting to look into things like robotics, and chat bots, and things like that to see if we can come up with a better, more rapid solution to automate these things instead of having to go through this custom connector development site cause it typically 2-4 months.

So another aspect is when we get into the on-prem integrations is we want to leverage as much on-prem infrastructure as we possibly can. The world's kind of changed, especially in the access management side. We used to deploy agents on all the servers or on a server farm, web proxy, etc. And then everything would be protected behind that, they would talk to the mothership through the agent. Well in the new cloud world, those agents don't exist anymore and now we're trying to figure out ways that we can leverage other hardware infrastructure to kind of replace that model. So if you've got an f5 in your environment, you can basically turn that into an enforcement point and now it broker the token exchange between Okta and the f5. And then kind of act like the old agent in the old world and give the application the attributes or the token that it needs to log in the user and still provide single sign on. So NetScaler. So there's nice patterns for integrating with all of these now with f5 and NetScaler, etc. Also if you get into rolling out into the API access management with Apigee and MuleSoft, those are very effective as well. 

So as you're doing your application onboarding analysis and creating your pipeline, you also need to look at the infrastructure components that are available and see exactly what of those can I pick and choose to help my onboarding program be more successful. Palo Alto Networks is another popular one that's being leveraged fairly often and we're seeing cases where once we've hooked up Okta with Palo Alto, we're able to retire two or three other systems that have been in the environment for years and that's just value right off the bat. 

RPA is one of the new technologies that's kind of been spawned out of the whole digital transformation era. It's an example of leveraging new technology to come up with a new way to avoid having to write these custom connectors and really get into a model where we can replace manual labor using an autonomous process that can basically mimic what that user's been doing over time. So for example, we have service delivery centers that are doing manual incident and ticket resolution where somebody will get a ticket, they will go look at the details, figure out what needs to be done, and then they'll go through and manually take this into a system. They're doing these tickets because these systems haven't been connected automatically through a connector for provisioning or other means because they're either it just hasn't been onboarded yet or there is no good way to onboard that system for some reason. 

So RPA with robotics process automation is a good alternative. So when I have highly repetitive processes that kind of take the same data over and over, I can leverage this to start automating those processes and be basically just make a script that says if user X comes in and they need access to, let's say workday, and workday would probably be automated, but let's say an SAP system that hasn't been onboarded yet and there's an interface that SAP you bring up, you log in, and you enter a bunch of information to create that user profile on SAP. You can basically make that script through the RPA agent and then it will go ahead and once that ticket comes in, it will kick off that RPA process. It will actually go in, open up the SAP interface, log in using a service account, and start entering all that information that a person normally would do. So it's basically doing that on behalf. 

So this technology has been used successfully in call centers and other industries and now we're starting to bring it in with identity and access to see if we can leverage this widely to use it as another tool to automate and streamline the provisioning processes. 

So also how we're actually delivering this with the client is very important. So in the past, we typically would follow the waterfall model where you just had a very structured pipeline it just went through the iteration and after potentially several weeks or several months you would finally come out with some result at the end. Hopefully you ended up with the result what the client was expecting, but sometimes you would get to the end and either client expectations or business requirements or something's changed that you may have or maybe weren't even aware of that changed in the process. So you would get to the finish line, you would start doing the demo or doing the release into the QA for the QA testing etc. acceptance testing and they would say, "well this is nice, but it's not what we need anymore." So then you would go back, start again, hopefully you would be more in tune with what the client requirements would be through this next cycle and get it right the next time. 

But it's just moving to the agile world is helping us avoid those disconnects and missing the target at the end. So now we're getting to the more adaptable framework instead of doing this long haul deliveries, we're breaking stuff up into the sprints the various agile models. So when we're doing application onboarding sprints for single sign on or provisioning, we'll pick 5-10 applications, depending on the team that we've got on site and we'll say within six weeks, we're gonna bring these five apps onboard for single sign on. And that way you're achieving value much quicker and you're not waiting til the end to say okay I'm bringing 200 apps after six months, but I'm just steadily accumulating apps over weeks instead of trying to do it all in one shot. 

So another key thing here is continuous integration. This has been popular in development world for quite a while now. It's starting to leverage tools out like Git, Maven, Jenkins, Confluence, Jira, etc. to get a full pipeline of start to finish automation from anything that I have to develop from a code cycle and release. So that's really important when you get into any custom code that you're going to deploy. Okta actually uses something similar on their release cycle, where you're using continuous integration as well. And the key thing that can really bring value here to your clients is around the testing automation piece. That's still with all of the cloud systems on-prem, that's still a gap that regardless of which system you're deploying, if you don't have testing automation, it's going to be painful and will catch up with you at some point. 

So by deploying testing automation, you can continuously keep your pipeline in flight, run through all of your integration and regression testing on even a daily or monthly, multiple times per day cycle if you're running that fast. So it really helps cut down the time that users would have to go in and do all this validation. And you can use all this automation to do that testing on their behalf.

So basically the testing would run on a period basis and you would just struct a report and say, "hey do I have any issues? If not, then I'm gonna go live with these changes or this onboarding." You can also use this if you're worried about new products or new capabilities that are coming through the Okta product suite in the preview environment or the production environment, you can have your own regression testing suite that's automated and it can run through if we've got five or ten key use cases that you want to ensure that never break regardless of any Okta release that comes out, you can have that sitting there running on a daily basis and then if at some point something gets released that breaks one of your old work flows, you'll get trigger, we'll send you a notification, then you can see what possibly made that change that broke the work flow.

So the goal here is to get in, get closer to delivering identity in an agile way. It provides consistency and then getting with an orchestration so you can actually do this at pace and provide a consistent result over and over. 

So why are we doing all of this? In the end, what's changed? There was the big spike back in the '90s, early 2000s, and now the digital transformation that's happening now. Well a lot of the key business drivers are still the same. Just because the explosion of technology and innovation and the number of things we have to keep track of now is much greater than what it was in the past, there's still some key drivers that are still the same as they were several years ago. 

Something that's been promised from all of these deployments, probably since late '90s, early 2000s, was this goal of getting to a single set of credentials. With all the on-prem deployments I've ever been involved with, I don't think that goal was ever achieved at any client. But I think it's promising now when we're starting to look at something like Okta that's based in the cloud, it's got 5000+ partners in the Oracle app application network. I mean we're starting to see the beginning of something where we actually could get to a point where it might be feasible to actually see a single set of credentials one day. There's probably still gonna be one off or exceptions here and there, but this is the closest I think I've seen us actually getting close to that goal. 

Of course lower capital expenditures, nobody wants to or most people don't want to keep deploying hardware into their data center and keep paying for that. Many organizations just aren't equipped to do it. They don't have the resources that can actually deploy physical hardware at all anymore or even if they have a private cloud, they don't have the expertise to really manage that on an effective scale. So they are going to move the services out in the cloud as well and that's why we've seen this huge adoption of cloud in the last couple of years. I think that's really an important shift that's happened in the last few years. We would go out and talk to clients about why they should start moving their services into cloud 4-5 years ago and we would immediately hit road block because their security organizations would start bringing up questions of why would I ever want to do this, why would I move my key systems out into the cloud where it's vulnerable and anybody can start attacking it? Well that conversation has completely shifted now. When we talk to clients, it's either they're bringing up their cloud first initiative, how fast are we gonna move this into the cloud and if I haven't moved the system already it's coming soon, so how fast can we get there. 

So that's been a huge shift. We rarely get the push back that we saw several years ago. I think along with the digit transformation, the whole conversations have changed. 

Of course, the improved adoption in user experience across your organization. One of the key things that has always been a road block with an accessible identity program is getting internal adoption and just buy in from all the business units, users, etc. that it's good idea to start using that stuff. Number one, lot of times people just are hesitant to change and they just don't want to go back and either change their work flow or process that they've been using for many many years cause now they have to think about it again. Or even touch these applications that have been running out in the environment for a long time and now they have to crack it back open and potentially change that as well. So it can be painful. 

So that's why I stressed earlier you never want to come in with any of these as just a technology project. Now it's more, especially with the quick time to value that you're going to deliver to the business, you have to be able to show them as this is going to roll out, here's all the things that are going to change to your end users and you're going to have to effectively plan for that. So you have to have communication plans to make everybody aware that this is coming, how they're going to be effected with it, and what's going to change in their world. And hopefully when they hear that, they're gonna be excited. So they're gonna say, "wow, I'm going to be able to log into these five systems with my existing credentials now." So typically it should be a good thing, but it just has to be framed up so that they know it's coming.

Of course one of the key mantras of security for the past few years is how do we improve the security posture without sacrificing convenience for the users? So I think this has been interesting to watch the evolution of multi-factor over the past few years. RSA kind of had the corner or the market corner for quite a while with the dongle and the token that you would just read the numbers off of and now with Okta and their MFA offering, it's really started to show how we can start really leveraging these new technologies and innovations to still provide a strong level of assurance and security, but still make it fairly easy for the user to use it as well. Especially when with Okta, you've got 10+ different integration options now. In the past, you would be like if you had 2-3 different options that worked well. So it's definitely becoming easier to integrate with, deploy, and use. 

And also with things like touch ID, the fight alliance, all those things, it's just becoming more and more prevalent. Looking even at your financial apps. If I go onto let's say Wells Fargo on my phone, it's using touch ID. American Express is using it. It's definitely in the main stream. It's here and we're still secure, but the user experience is also being thought of as well. 

One of the key things that's still time to value, how we're shrinking the window of how we can really truly deliver business value in a meaningful way to the client. So in the past, we would deploy a system and say, "okay great here it is, it's up and running." And then the client would be like, "Okay now what? Yeah that's great, it's running. It's perfect, but it's not doing anything for me because it's not integrated." So that's the key, getting the application integrations up and running and showing them you can do this very quickly. You can leverage your investment in the core product and now it's spread out to the rest of your enterprise and you can use this effectively to bring true value to all of your end users. 

In the past with internal user experience, usually the drivers were compliance, security, etc. And now I think we're really seeing the shift on the consumer side that's really driving the true rush, the time to value. Especially in like the products in hospitality areas, if you can't keep up and actually deliver that new web app for your, let's say your mobile check-in experience, or your loyalty program, you're going to start to lose market share very quickly cause there are other companies out there that are doing it very quickly, rolling it out very fast, and people are fickle. Especially on mobile. If they don't like something, they will go find something else that they do like very quickly. So if your app isn't what they expect, they won't use it. Especially if they log in and have a painful registration process, if it's not remembering my profile information, I have to do things over and over each time I come in, they're just not gonna put up with it anymore.

So that's what I've got for today and I appreciate everybody coming to listen and if anybody has questions, please let me know.