Bhavin Shah

Good afternoon, everybody. About a year ago, some of you have probably been to the DevOps Summit last year. You may have heard of the terminology continuous compliance. You may have heard it in another form: automated governance. We're excited to bring a real story that did happen from that last summit to this summit. And this story is about Resolution Life.

If you don't know who Resolution Life is, Resolution Life US is an insurance company. Now, when you think of insurance, the first thing that hits your head is compliance, right? When you think of insurance, what doesn't come as a natural second is technology, right? Resolution Life is unique in the sense that it is a technology-forward, cloud-native insurance company. And that said, they still have to do compliance.

And what they've been able to achieve is what Resolution Life themselves are going to share today. I know you see two of us here. You'll find out the mystery about the third person shortly.

So what we're going to cover today is, what are the challenges and opportunities when it comes to software delivery changes, change management processes in the insurance world? Resolution Life will share their own problem statement. They will give what their problem was, and obviously the vision with which they started this journey.

Obviously, for some of you who may have not heard the term continuous compliance, we'll talk about what is continuous compliance and, more importantly, what did we do to achieve that. And then we'll see some glimpses of how the problem was solved for Resolution Life.

Now, I tend to introduce myself a little later in the game, given my initials. I hope you respect that. But I am Bhavin Shah. I'm from Gathr. I oversee sales and customer success for Gathr. With me is Matt Bonser. He's the director for Cyber Risk and Regulatory at PwC. And the star of the show, who couldn't teleport himself here at the exact same time, is Mittal Bhiogade. He's the technology leader and chief architect from Resolution Life US. So thanks to the AV team, he's here live with us.

Mittal Bhiogade

Hey, Bhavin. Thanks, and thanks for arranging this. I really appreciate it.

This is chief architect for Resolution Life. And just to give a little bit more blurb on Resolution, being born cloud and being fully digital, cloud native, we do have a lot of challenges on compliance delivery integration. So we would love to share the story.

I just want to highlight, we are mergers and acquisition organization, and we do manage life insurance and portfolios. We run assets, $30 billion assets under management, and we serve more than 1.1 million customers. So I just wanted to, for the folks who don't know about Resolution Life, give a little bit blurb.

Bhavin, we can get started.

Bhavin Shah

Thank you, Mittal. And he'll obviously be back on screen again for Q&A. Go ahead, Mittal.

Mittal Bhiogade

Thanks, Bhavin.

So just to frame the problem statement, I think we were trying to solve two challenges for us. One being, how do we create a lineage in our software development life cycle? And what do I mean is, from inception to construction and deployment, end to end, how do we give the visibility, like what are we developing and what are we deploying for our customers?

And the second problem statement was, when we are doing all that, how do we bring the auditability and feasibility of the change management? That's the part of the continuous compliance. How do we share what we do with our compliance stakeholders and audit stakeholders?

And some of the very common challenges, irrespective of the industry, are each organization has disparate processes. They have disparate tooling. When an audit stakeholder asks for evidence for a change management, there is a scavenger hunt, right? Like, how did this change really go to production? And there is no clear visibility on what was done. You are not able to correlate when the change is spanning across multiple technology platforms. You're not able to correlate, right? Like, how are these changes related?

So these are some of the challenges we were trying to solve. Bhavin, we can go to the next slide.

So to solve these challenges, we looked from key lenses: from people, process, and technology. Primarily in context of process and technology, we wanted to look at what are our different workflows when the change management happens between different platforms, and how to make that consistent. How do we use, if not same, similar tooling, so that our DevSecOps, CI/CD pipelines are consistent, at least in terms of stages, if not tools?

And just to give some examples, how do we document our epics? How do we document our stories? If developers and engineers are committing to source control, is there a consistent way so that we can build that lineage between what were the requirements which were documented into a requirements platform and how all this gets connected?

So that was all about refactoring, reengineering tooling and processes.

From people perspective, the lens we wanted to apply is, how do we make the individual team stakeholders, whether it's a product owner, the tech lead, and the QA engineer, how can they become self-sufficient to own their change instead of traditionally working with a change management board, which a lot of organizations have to promote the change? And there is some kind of an approval process, which is not transparent, right? Like, what is the reason the change is getting declined or approved, given that a lot of intelligence and knowledge is with the teams who are actually doing or building that change?

So we wanted to give more and more authority and responsibility to the team. At the same time, we wanted to put checks and balances for compliance. And given in insurance and financial industry, we are regulated, so we have to produce evidence of the change. And we are audited both internally.

The goal was, how do we make sure we can give teams an option to build and deploy at a faster cadence, but at the same time put all the governance and auditability and traceability? And how do we do this seamless, so that both kinds of personas, the engineering developer persona and the auditor stakeholder persona, both needs can be satisfied?

This was our attempt to challenge the change management advisory board, which is in several organizations, to have an alternative change management process. And if you followed all the rules and if you did all the checks and balances, you could get your change deployed in, if not in minutes, definitely in hours. So that was our proposal, to have an alternative change management process.

To control checks and balances, we had some tooling and monitoring. For example, we did some kind of a drift management. Let's say for separation of duties: who is building the code? Who's deploying the code? We did some kind of an exception reporting to determine if exceptions were taken to get the change out.

So those are the things which we have done in terms of process. And these are the areas, from a high level, people, process, technologies, where we have tried to make changes. So we can move to the next slide. Thanks.

So if you look at the solution, how did we achieve this continuous compliance, which is GA and we are using it in our production right now? DevSecOps platform is at the heart of the solution. And there are auxiliary platforms, whether there is a change management solution like ServiceNow or a requirements management solution like Jira. So all these tools get orchestrated in a software development life cycle.

And what we have done is we have brought all that information and built some correlation together in a common place. So it's an aggregation of a lot of software development life cycle tooling, which is brought in a single place. And then we have built a lot of visualizations and dashboards to satisfy the two personas: the engineering developer persona, to showcase how is your change going from inception at requirements all the way to the production, which is a change management; and then for our auditor stakeholder persona, we show the same kind of data in a different view in context of change management.

So an audit stakeholder could literally go and say, "Hey, this is a change which I want to investigate or audit, and this is a change management number." So the tooling which we put out there, which orchestrated the whole software development life cycle, you could look up on that change management ticket and then literally back trace. How did that change go to production? If there are pre-prod or any other testing environments, all the way to development, and even all the way back tracing to the requirement, the auditor or stakeholder persona can literally do this self-service without asking questions to anybody. So this is a kind of a transparency we have brought in.

And there are a lot of stage gates and quality gates in this kind of a model, whether it is on the security side, whether it's on the code quality side. If there are regulatory rules, we have tried to bake each and everything in our CI and CD pipeline and orchestrate with any other tool and bring that information at a common place so that we can visualize it.

So that's what we have done. So Bhavin and Matt, I can give it to you for the next stage.

Matt Bonser

Cool. Thanks, Mittal.

So yeah, I'm from PwC, and as you can imagine, we usually get called in by our clients when they've got the mess on the left-hand side, when they've got auditor findings, when they've got that kind of thing. Mittal and Resolution Life didn't want that. They never wanted to be there, and they wanted us to help them move over to the tech-enabled model.

I'll be pretty quick on this slide, spend more time on the next one. But as you can imagine, there's a whole bunch of other stuff. We've talked a lot about the cool engineering pieces. There's a lot of other things that underpin it as well, like policy, standards, procedures, things that the auditors are going to look for, like playbooks and guardrails that need to be built into or developed along with the engineering pieces and the pipelines. Obviously, the whole goal for everyone was to avoid the left and move straight to the right.

So here is, and I apologize, this is small, but as you can imagine, trying to get it on a single slide is a bit of a challenge, and it's obviously very simplified. These processes aren't linear, but what we've got here is the three main groups of controls that are embedded into the process and into the tools, and then the continuous monitoring that sits underneath those.

The first group is focused on the inclusion of compliance and security and control and privacy and all of those kind of things into the development process upfront. These can also be some of your project management controls. They could sit up there as well as, for example, a feature owner approving a feature to say that it's ready for work.

The next group is around the security controls or the security validations that are built in. We've got them all sitting in one place on this. Obviously, they're not. But this is your SAST, IAST, DAST, SCA, all of those other scanning techniques that you need to use to pick up your vulnerabilities and anything else along the way.

Obviously we have built in the principle of shifting left. So doing those as early and as often as practical, obviously not just blindly shifting them to the left, but doing them at the appropriate time when you're going to get the most value from those.

The final set of compliance areas is what we're just calling the IT general controls, but it's more complicated than that. This is where things like your segregation of duties exist. So making sure that you can't develop and promote your own code. That's the simplest way of looking at that.

But then also going beyond that, to think about the tools themselves that are being involved in the pipeline. And if they're playing a critical role in that control, then thinking about what needs to happen to those tools as well. So for example, you need role-based access. You need to control the way that changes are made to those tools. You need to make sure that anyone who is interacting with those tools as a user can't then go and bypass the control or move through a checkpoint or anything like that. So there's quite a lot that goes into that.

And then across the bottom, that's where we have set the continuous compliance piece, which Bhavin will start to get into, or the compliance monitoring piece.

What's unique about what we did here is we are not looking at each tool in isolation. We are bringing it into the one place and then being able to apply rules to it to make sure that it's meeting both those, I'll just call it, financial statement control rules, as well as other regulatory and other compliance needs.

Bhavin Shah

Thank you.

So the big question, right? What did we do? Now, it looks like a long nine-step process, but every step has its merit. The most important thing is just getting a clear definition of what is really needed, sort of the business and technology understanding. And then along the way, those control gaps, any bypass of that step will later haunt the journey backwards.

So one very important thing as you think about continuous compliance and the planning aspect, Mittal mentioned lineage, is as you think forward, remember the return journey backwards, because you want to create that feedback loop. The moment something fails, people ask, why did it fail? Go trace it, go fix it. So you have to keep that forward and reverse journey in mind.

Documenting those control gaps is very, very important because that's, when you go to step three, you finalize scope. Step four is that future-state solution design, having that vision of, okay, what do the different personas want? What does the internal audit team want? What can I present to the external audit team? What does management want to see? And what do the people who need to fix the problem need to see?

So you have to keep those stakeholders in mind, and that's that future state, which, depending on what they want to see, you start designing the system. And then all the visuals and all of that, getting visuals, metrics, believe me, is the easy part. Designing this and the workflow is very, very important because you have to satisfy the different stakeholders.

Procurement setup is, if there are missing gaps in terms of whether it's configuration, you need infrastructure to do certain things, you have a missing tool, whatever, if applicable, that needs to be done as well.

Once you get to that point, then the stitching work begins where you actually do the tools integration. To what Matt and Mittal said, now you're ready to put that fabric together, stitch everything together, and then overlay the solution on top. But by this point, you already have the vision. It's documented. What does that forward journey look like? What does the reverse journey look like? So the moment something fails, you have an audit trail available to go fix.

Once you do that, that's that feedback loop, step eight. So now this is an ongoing process, because just because you produce a report, someone's not going to do a buy-in and say, "Yeah, I love the report. Great, thanks," right? They want to understand what that report means. How do I digest it? What's the feedback? How do I take action on it? So that action piece is like a cycle in itself. Ongoing monitoring, feedback, trigger violations, take actions, fix it. Does it go through that cycle?

Now, piece by piece, you've automated the whole journey. So these nine steps are important in terms of the end-to-end journey.

Now, why is this important? I know it's kind of like stating the obvious. Why is it important? But this end-to-end traceability or that audit trail is what is going to drive the action.

I know oftentimes we go into discussions with customers and say, "Hey, my management is asking for metrics. I want to fix problems. I want to get more efficient." Those are good business outcomes. But then how do you get there?

So this end-to-end traceability to track code changes, infrastructure changes, process changes, configuration changes, is very important because that then gives you that end outcome, which is your efficiency, the cost reduction. And it's not just cost reduction in terms of, okay, I went from manual audit to automated audit. It's also optimizing the resources that you allocate to that problem statement, right? How much time are my people spending going around, like Mittal said, the scavenger hunt to go figure out where the problem is?

Now you've optimized that. Now I have a digital trail of everything that's going wrong, possibly where the control points are. Do I need to train people? Do I need to do something different?

Compliant processes and tools, as Mittal said, it's not just about the tools. It's about people, process, and technology. So those checkpoints, and that goes back into that earlier process flow. I mentioned the nine steps. Those checkpoints are very important. Don't just limit it to tool. It's the people that drive the process and the tool. Any of those can go wrong. You can deviate and then go off compliant.

And think of scale, right? A lot of you come from large companies. There are hundreds of teams, maybe even more. You've got to think scale, because doing it at scale without automation is more chaos, which previous session was all about.

And then the low-touch change flow. So again, when I say that, it's how do you drive change management? Overnight, going to something automated will not be easy. Doing it step by step by looking at the pieces that need to be automated and putting them in motion is where you'll get that low-touch flow from a change management perspective.

And this is something that's critically important as well. So although the benefits say, "Hey, it's continuous compliance, it's a no-brainer," but how do you get there is what Resolution Life was able to share.

So I'm going to invite Mittal back again. He's willingly shared some screenshots from their journey of what they've accomplished. Obviously some data is masked for confidentiality reasons. Mittal, you want to set the context and I can play the video when ready.

Mittal Bhiogade

Sorry.

Bhavin Shah

Favorite problem. Yeah, yeah. Can you hear me now?

Mittal Bhiogade

Right. So, yes.

I think one thing I would love to share is, to embark on this kind of a journey, we need a lot of stakeholder partnership. So we partnered heavily with CISO organization, and our CIO and CISO, Rob, really wanted to do this. They wanted to bring visibility and transparency. They wanted to work collaboratively with our audit stakeholders.

And we had excellent partnership with both PwC as well as Gathr, both from process refinement to tooling, bringing all this together and building the lineage out. And I would like to thank Neeraj, who really orchestrated this program, which was really complex, multi-pronged.

So yeah, that's something I would like to share. Bhavin, we can showcase it.

Bhavin Shah

Okay. Boy.

Mittal Bhiogade

Yeah. So this is our landing page. There are two personas. One is on the audit side, the audit trail. And this one starts with an API pipeline. And what you are seeing, I know we have laid out all the API names, but these are all the... Oh, this is jumping fast.

So this is a detailed view of a pipeline, and it shows from Jira ticket to all the way who approved it and who did the production deployment. And then you keep on drilling down and you keep on seeing more and more details, like what their exceptions are, or if there are three pillars, red, amber, green, and yellow, depending upon whether the pipeline was green or there was an exception or it was broken.

So this is the card view which tells each and every phase of software development life cycle. So if you see on left, and this is a detail of that view. But I think what, and we can obviously share this material in some way, but the intent of all this information is to bring transparency on audit, on both sides, the engineering side and the audit stakeholder side.

And we have published DORA metrics, typical, what's the cadence of deployment, what's the MTTR? And we have customized some of the metrics in Resolution context. Like, what is the time it takes when the story gets into the pipeline, and how much time it takes to get it deployed?

And we have some governance being established in organization using these metrics. How do we improve the cadence of software delivery? How do we improve the number of deployments? How do we find the bottleneck in the software development process? Is the testing taking too long? Are there any approvals which are stuck, and how can we automate and bring build efficiency on this?

So I'm moving back to you.

Bhavin Shah

If you think the video is running fast, it's okay. You can always come by our booth. Matt and I will be there. You can take a look at the use case in action.

But since we have about a few seconds now, Mittal, what would be interesting to share, and you can bring Mittal back, AV team, thanks again for a wonderful job there, what would be interesting to understand is, what was the buy-in process from the different stakeholders? This is a lingering question because it's not just about one team, that okay, it's only the DevOps team or it's only executives. There are multiple stakeholders here.

So if you can share a little bit of that quickly, and then we'll open it up to questions.

Mittal Bhiogade

Sure.

So I think the main thing which Resolution Life does is there is a value assurance initiative, which allows us to bring on initiatives which would improve the efficiencies in organizations at different levels.

So DevSecOps was proposed by our team: how do we bring efficiency in the overall process, and how do we improve the cadence of software delivery, and how do we also satisfy all the audit needs? Because what used to happen is everybody used to think the audit is slowing down everything. And our idea was, how do we partner with audit stakeholders? And Rob, our CISO, being the primary individual who is interfacing with our audit stakeholders, so we partnered with him heavily.

We got a great buy-in from our CIO, and pretty much whole organization was involved. A number of development teams got impacted on how they do through the build and how they deploy. So this was expanding the thing, like the continuous integration and continuous deployment. How do we also inject the compliance aspect into it?

And it's an ongoing journey. We have onboarded digital platforms. All the APIs, like hundreds of APIs, run through this platform. Hundreds of data pipelines are running on this platform. And we are still in process of onboarding a few things on this approach. So it's continuous improvement on what we have done. I think it has not reached an end state, and we are continuously evolving.

Q&A

Q: Are there any questions from the audience? Mittal couldn't join in person, but he's available. He said to meet with anybody virtually, in person. He's on the East Coast. So if you want to reach out, that's fine, but if there are any quick questions we can take.

Compliance or...

A: Yeah, that's a great question. So the question was, was it a single solution for different types of compliance? I'll just talk in general terms, how we would usually do it.

So when it comes to your compliance for your financial statement controls, that's going to be the same. That's just potato for potato. When you have specific compliance needs, for example, if you're in a big bank or something like that, you may have to have some slightly different versions. But when you use a tool like Gathr, you can apply different rules to different pipelines. And so that's how you do that.

But for the stock standard, everyone's really looking for the same stuff. They're looking for testing, authorized changes, all of that kind of thing. And then you may need to layer in some additional rules over the top.

Bhavin Shah

Mittal, I hope you're able to hear the questions.

Mittal Bhiogade

I'm not able to hear the question.

Bhavin Shah

Okay. So the question was, did Res Life have different compliance or different areas, or one umbrella compliance policy?

Mittal Bhiogade

I think compliance, as Matt said, there's only one compliance at Resolution Life, and the same standard is applied. I think the framework, what we used, is pretty consistent. The stages are consistent. Maybe there could be some fine details or customization at certain stages, like maybe an actuarial system might have a different need versus a Workday Finance.

So we did some fine tuning based on, what we refer is a pipeline type. So maybe certain pipeline types had some specific customization.

Bhavin Shah

Thank you.

Probably any other questions? And I'm standing between you and the break. I understand. If there's any other questions, we can take one real quick, or you can come see us at the show floor.

Thank you, Mittal, for joining us virtually, and thank you. Good company. Thank you.