Host Intro (Gene Kim)

All right. So believe it or not, during the 2000s, I was a paying member of the Institute of Internal Auditors for almost a decade. I loved auditors because of the clarity and precision in how they spoke about controls.

Which is interesting because today, without a doubt, one of the biggest obstacles voiced by this community in terms of who's in the way of implementing better ways of working, of which DevOps is certainly one of them, are the auditors. Whether it's internal auditors, external auditors, or the external regulators.

So thanks to the tireless work of Sam Guckenheimer from Microsoft, Dr. Topo Pal, after over four years of work, we have finally been able to get representatives from each of the Big Four firms here to help us bust some DevOps myths.

As I mentioned yesterday, these are people who support the audit teams. I suspect that when you meet these people, that they're not going to be like any auditor that you've ever met. Instead, I suspect your reaction will be, "Wow, they're one of us." They're boundary spanners. They all come from a technology background, and they've all been working tirelessly within their own firms to help their audit colleagues understand why DevOps is important, and how DevOps could be used internally within their firms, as well as helping their clients use DevOps safely, and educating the entire audit, risk, and compliance community.

So I am so grateful that they are willing to spend two days with us and help us learn how to better work with auditors, how do we engage with them ideally, and end up with far better outcomes, both for us as the audited, as well as for them as the auditors.

So we are going to be playing a game called Busting DevOps Myths that I'm going to describe on this slide. So on the slide will be a title saying "Busting DevOps Myths." We're going to state a myth, and then we're going to ask each one of the panelists: is it busted or confirmed? Specifically, we're going to eliminate plausible, because what we don't want to hear is, "It depends." We want to actually hear specific guidance that you can take away to better arm yourselves in your next interaction with your own auditors.

With that, I would like to introduce our distinguished panel. Please come on out.

The auditors are here. Whoo.

All right, so if you could just briefly each introduce yourself and maybe say whether you're in the assurance or advisory side, and maybe tell us why that matters.

Panel Introductions

01Yosef Levine

Sure. Yosef Levine from Deloitte. I've actually never been invited on stage and said that I was an auditor and then people clap. But there's a first for everything, right?

02Gene Kim

Absolutely.

03Yosef Levine

I am a true financial auditor that kind of got into the technology space a bunch of years ago.

04Michael Wolf

Hi, my name is Mike Wolf from KPMG, Managing Director of our Modern Delivery Practice. So I'm at the advisory side, but I was a highly evolved developer who one day figured out, if I really want to get stuff done, I need to make friends with the audit side. And so I end up being a translator internally and with our customers, is how we tie these things together.

05Gene Kim

Awesome.

06Jeff Roberts

Hi, Jeff Roberts with EY, and my background is as an IT auditor, and specifically for public companies. But over the last few years, spending time helping companies modernize their IT compliance space to help as their rapid pace of development in their organization.

07Matt Bonser

Hey, I'm Matt Bonser. I work with PwC. I started out actually as a financial auditor, and over the last 10 years have moved into the IT audit space and then have been focused on Agile and DevOps, and specifically the audit response to DevOps, both helping our audit teams understand what to do, as well as helping our clients get ready for their auditors.

08Gene Kim

Awesome. And by the way, when I say that they all have a technology background, I sort of knew that, but I was actually a little bit surprised that we were all geeking out over Scott Haven's presentation and critiquing his CQRS event sourcing patterns. That was really awesome. So it's nice to know that within each one of these audit firms are technologists who are deeply steeped in technology.

Myth 1: Audit Will Never Allow DevOps To Happen

09Gene Kim

All right, so let's go to our first myth, which is: audit will never allow DevOps to happen. Busted or confirmed?

10Panelists

Busted. Busted. Busted. Fully busted.

11Gene Kim

All right. Can you maybe substantiate that claim?

12Michael Wolf

Well, if you don't have DevOps, you don't have business, you don't have transformation, so you got to figure it out one way or the other.

13Yosef Levine

Yeah. And I would say that in general why this is fully busted is our audit teams, our internal IT audit teams, are embedded into these DevOps teams consulting. I've seen risk team members submitting a compliance bug in Jira, right, and then that being prioritized on the backlog of activities. And I'm seeing that in customers all day long.

Gene, I think the big piece is trying to change the question as well from, are we allowed to do this, to how do we do this and how do we do it right? I think that's a challenge to everybody in this room: stop asking permission, but start asking how, and how do you get that conversation started with your internal compliance folks, whether it's internal audit or your external auditors, to really figure out how to do this and do it well.

14Gene Kim

Is this going to be unanimous?

15Panelists

Yeah. Yeah.

16Matt Bonser

And I'm going to expand on that. One of the things that I do a lot of is sit in walkthroughs that are early on in the design stage for pipelines, where they're getting me in with, as part of the audit team or part of an internal audit team, to say, "Hey, this is what we're thinking. This is where we see the controls sitting. Can you give us some early feedback before we spend time building?" And actually getting that input right at the start.

17Gene Kim

All right. I think we can say this is busted. Got it. Awesome.

By the way, and maybe, Gio Savone, acknowledge your help in doing a trial of this in the London event. And you specifically were very explicit that you are using DevOps principles and practices for applications that support the attest practice.

18Yosef Levine

Correct.

19Gene Kim

So if clients rely on your judgment, they are in turn relying on applications that are using DevOps. So clearly it is consistent with all the internal control--

20Yosef Levine

Definitely consistent. I think our approach to manage our own internal systems that we use to serve our clients, where we're a data storage for our clients' data, we're practicing what we preach. We're self-imposing elements of COSO and some elements of Sarbanes-Oxley on ourselves to make sure we're doing things appropriately. And to the point that my colleague mentioned, that you embed technology controls and security into your dev teams by design.

If you're an auditor, compliance by design is a really cool concept. And you, as DevOps aficionados, have to really get with your auditors and explain to them how it can make their life easier.

21Gene Kim

Awesome. Any other comments on this, or asterisks or footnotes on this? Or are we ready to go on to the next myth?

22Panelists

Ready. Next myth. Yeah. Yeah.

Myth 2: Change Approvals, Segregation Of Duties, And Production Access Prevent Automatic Deployment

23Gene Kim

Change approvals, segregation of duties, and access to production controls prevents code from ever being automatically deployed into production. Busted or confirmed?

24Panelists

Totally busted. Also busted. Busted. Totally.

25Gene Kim

All right. Is anyone brave enough to substantiate that claim?

26Michael Wolf

I'll take parts of it. Segregation of duties is a really important part, but if you lay out for somebody something like GitOps, and you lay out exactly the access controls to do that. Myself as a recovering developer, we used to talk about--

27Gene Kim

How you doing, man? You doing okay?

28Michael Wolf

I'm taking it day by day.

29Gene Kim

That's all we could ask for. Congratulations.

30Michael Wolf

We used to talk about the importance of code reviews. I will say nothing has enforced that more than a pull request that I can fully trace and go, "Oh, X amount of people were involved in that." Let alone rolling it down to something like documentation, which is also a massive thing. And I often say, "Which would you rather look at? An Encyclopedia Britannica from the '60s that said, 'Man one day will land on the Moon,' or do I want to look at Wikipedia?" The speed of update and governance across that stuff. All of these things is really about a properly put together toolchain and process. It really actually is the glue or guardrails that ties all this together.

31Matt Bonser

Yeah. And then certainly the way we're seeing it is that secured pipeline is going to allow ultimately for promotion into production, but there's a lot of caveats to that. It's about controlling access across the pipeline. It's about making sure that if I'm being controlled, quote unquote, by the pipeline, that I can't go in and change a configuration within one of the tools or bypass a control or update a test script so that it's going to pass my nefarious or just bad code.

It's about having processes in place to make sure the test scripts are being kept up to date as you're introducing new features or working on bugs, that all of those things are being changed across the pipeline. And then those in turn help to create your segregation of duties because it's whilst the person may be doing a one-click commit, other people have controlled and set up the configurations along that pipeline, and the person doing the one-click commit can't go and change those.

32Michael Wolf

And if you think about the power of the different resource groups you could put into your deploy capabilities, you could bring in security, the devs, all the different competencies that you need, including the business users. If you pull them in, they are now a part of deployment. So you're bringing that whole life cycle and everybody together.

33Jeff Roberts

Yeah. And from that audit point of view, the moving away from those historically manual controls to these configuration tooling-enabled processes is so much more powerful, both for you from an engineering standpoint, but also from us as an auditor. It's much easier for us to test and rely and get comfort around that system design than simply these manual human-driven processes that do have a lot of risk.

34Michael Wolf

And I think there's a myth kind of hidden in this myth, where you're saying automatically deployed into production. Much like a previous speaker talked about data definitions and a type of governance over that data, there's certain things risk-wise that we may still want to go to a manual acceptance. But in the pipeline, I can see that that change was requested, who approved it, and then after somebody approves it, then cool, let the machines take back over and--

35Yosef Levine

And that audit trail is exception monitoring. So that leads to really the new era of auditing where everything is hard-coded and you're managing exceptions, and that is the new audit trail.

36Gene Kim

And by the way, I just want to validate this. You're not saying this just to make new friends or impress everybody. These are what you say to actual audit clients and the advice you give.

37Panelists

Yep. One hundred percent.

38Gene Kim

So, busted or confirmed? Busted. Are we unanimous?

39Panelists

Yeah. Yeah. Busted. Busted.

40Gene Kim

Round of applause for our auditors, by the way. Come on. This is cool.

Myth 3: Developers Are Not Accountable For Compliance And Quality Objectives In An Audit

41Gene Kim

All right. Next myth: developers aren't accountable for any portions of the compliance and quality objectives in an audit. Busted or confirmed?

42Panelists

That's busted. Busted.

43Gene Kim

Say more.

44Yosef Levine

So, what we've taken upon ourselves is that every time there's a deficiency, and there's all different types of deficiencies that turn into PBIs, there has to be somebody who's held responsible for getting that in the next pipeline or in the next deployment. Obviously you rate them based on severity and where they're going to go in. But you have to have accountability for all of these and monitor them and age them in a holistic risk management lens.

45Michael Wolf

Yeah, I think as we've progressed to creating these full stack teams, right, at first the question was, is QA the responsibility of a developer? And we changed. We said actually unit testing, behavior-driven, test-driven development, this all of a sudden changes. We're all responsible for quality. And then it was security. Right? We're like, "Oh, that's the security team's." Then we're like, "Actually, it's all our responsibility." We now need to embed that.

I think this is that last or one of the last silos there to break it down and saying, "Actually, this compliance is a non-functional requirement." If you think of a developer, I'm thinking about all the other things I have to do. This is one of the non-functional requirements that we now take on and we own as a full stack team.

46Jeff Roberts

Yeah. And just the prior view of compliance to that is so much as a business blocker, as stage gates that you can't go forward, and you can't get to the speed and velocity that you're looking for. And it's really how do you change that conversation to build compliance into your thinking, into your process, into your pipelines so that it becomes part of your everyday operations, so that it's an enabler for your speed, not a blocker to that.

47Matt Bonser

Yeah. And just to kind of pile on everyone, I'm all for shifting as much left as possible. Compliance and security by design, the earlier you can be doing it in the process, the better. To the point where what we're encouraging our clients to do is right at the start, think about what those non-functional requirements are, and build them out as user stories and have them go through the dev process the same as everything else.

48Gene Kim

So I think the consensus is unanimous again. This myth is busted.

49Panelists

Busted, yep.

50Gene Kim

All right. Another round of applause for-- By the way, is this helpful to you in your own mission? How many people here might be showing this video to your compliance specialists or your internal audit teams, maybe even your external audit teams? Oh, perfect. And we're going to talk about ways that these professionals can actually help you even further in that mission.

Myth 4: DevOps Processes Can Be Made Auditable, Traceable, And Secure

51Gene Kim

All right, next myth. DevOps processes can be made auditable, traceable, and secure. Busted or confirmed?

52Panelists

Confirmed. Confirmed.

53Gene Kim

All right. Could you say more and substantiate that crazy claim?

54Yosef Levine

The best thing about DevOps is everything is auditable and traceable. The question is, where is it hidden, where's the data point, and how do we go about creating an environment that we could get that evidence put to our fingertips when we need it? So some of the steps that we've done is we've created for-- most companies have a level one, level two, level three compliance. For level two compliance, we've given read-only access to a lot of different environments so the auditors could go in and actually see things that are rendered to them and do follow up.

55Michael Wolf

Yeah. I would say where this becomes a problem isn't that it inherently isn't auditable and traceable. Actually, you have so much data in that system, the exhaust coming out of it is--

56Gene Kim

Noise.

57Michael Wolf

--is noise. Being deliberate and creating golden pipelines and golden containers that have already been blessed through compliance and then all of a sudden motivates other people to say, "Oh, I can skip some agreement and alignment because these exist?" I think that deliberate nature of creating a truly connected ecosystem makes this, by default, the default action, right? And to your point, the exception is, okay, we need to get out of that for X, Y, or Z. But this becomes a default golden path, but you have to be deliberate. Using the exhaust makes people question. Being deliberate and laying out the trusted path gains a lot of confidence.

58Jeff Roberts

And so I think a little insight into the way your auditors think is that your auditors generally are afraid of the unknown. In this space, there's a lot of unknowns. They've been trained to not think the way you guys do around what positives could happen instead of the negative: what could actually go wrong?

Challenge back to you guys of how do you bring them along on this DevOps journey? Helping them understand that you've thought through your process, that you understand the risks, that you've thought about what you're going to do to address those risks, really will help that audit conversation, that risk and compliance conversation move forward because there is a lot of unknowns from them. The more you can share, the more you can share your knowledge, the better those conversations will go.

59Gene Kim

Well, let me just throw out something to the audience. How many people here engaged in DevOps have ever engaged in a risk discussion about a particular application release by a show of hands? Okay.

60Yosef Levine

Gene, I know I'm a bean counter--

61Gene Kim

Sure.

62Yosef Levine

--but probably 30%, right? But why not 100%?

63Gene Kim

I would say 34 point-- Yeah. About a third. We're going to deputize you as an auditor, Gene, at the end of this.

64Yosef Levine

Certified. One thing that we've done is for every minor, semi-major, major release, however you classify your different releases, go into a holistic risk discussion with all the relevant stakeholders and understand what are the risks of these PBIs. What do you have to think about? Is there any upstream or downstream impact, any connectivity to other subsystems that may have a, quote-unquote, "issue" that we didn't think about going in? So having these discussions really helps from a risk-based perspective to understand the impact of your different releases from PBI lines.

65Matt Bonser

Okay. Awesome. And I'd just kind of add to that, too. I would argue that the target end state for DevOps is going to be really auditable. There's going to be automated controls. There's going to be a lot of great stuff in there. But in that transition phase, when you're moving from kind of the old-fashioned manual processes into this DevOps phase state, and you've got some automated tools, some manual pushes, all that kind of thing, just be really mindful of that, and that's going to freak your auditors out.

Because they're going to hear, "Yeah, okay, there's automated controls." "Can I test them?" "Well, not quite yet. We've got some workarounds, and we've got some manual approvals here and some automated approvals there." And so just really having a clear view of not just talking about that target end state, because the target end state is great, but being able to also say, "Here's the steps we're going to be working through, and here's the risks along the way, and here's how we're going to mitigate against those risks." But just being mindful that change does freak auditors out a little bit, and that transition period where you've got lots of different things happening and tools coming in and out, and your tools are maturing, and the process is maturing, just being mindful of keeping them up to date as you're going through that.

66Gene Kim

Awesome. Well, I think, are we unanimous that this is--

67Panelists

Confirmed. Confirmed. Confirmed. Confirmed. Yeah.

68Gene Kim

Awesome. And by the way, we didn't rehearse this, but I think it would actually, to take this out of the hypothetical into concrete, could each one of you say that you have seen a DevOps process that you have personally attested or whatever, right? Said this is auditable, traceable, and secure.

69Yosef Levine

Personally, me and my team do it every day.

70Michael Wolf

Yeah. Our teams are working today with internal IT audit confirming those controls across various toolsets.

71Jeff Roberts

Yeah. We have public companies that run pure DevOps models, and they are requirements that they have for compliance, and they're meeting them. So there is a way to do it.

72Matt Bonser

Yep, and same with us. And we've also got a lot that we've done design reviews of lately, and they're really starting to look good, and we're starting to see more and more code go through them.

73Yosef Levine

And Gene, I think a key element here is some of the more highly regulated industries in the financial sector and the healthcare sector, they're going deep on DevOps, deep on cloud. They're a data-centric organization. And if you're a data-centric organization in terms of how you operate from a DevOps lens, now you're just taking those same data management concepts that are generally from a front-end office operational lens, and you're applying it to DevOps.

So one would think in a highly regulated environment or industry, people would be scared of DevOps, scared of the cloud. It's actually the opposite. When you're data rich, you actually know how to manage it better from a DNA lens.

74Gene Kim

All right. Doubly confirmed. So round of applause for another busted myth or confirmed myth, right? Something to help you in your journey. All right.

Myth 5: All Auditors Are Ready For DevOps

75Gene Kim

All auditors are ready for DevOps. Busted or confirmed?

76Panelists

Busted.

77Matt Bonser

Pretty--

78Yosef Levine

Yeah, so I'll go first on this one. Auditors are ready to be ready.

79Panelists

No, but as we said, auditors aren't particularly embracing of change, but in a--

80Gene Kim

In fact, maybe--

81Panelists

Exactly, right. So that was sort of meant as a joke.

82Gene Kim

Let's do the more generous one. We can help auditors who understand DevOps. Busted or confirmed?

83Panelists

So that one is definitely confirmed. Yeah. Yeah. It's confirmed.

84Matt Bonser

But as I was saying, auditors, especially external auditors who are doing financial statements, they only have to deal with what's on the docket for that year. So if you're looking at the financial year '19 financial statements, if there's no DevOps processes that are in scope, then you're not looking at DevOps. You're not worried about DevOps. So they're ready to be ready, but it may not have actually come into their focus yet.

And so that's where we go back to, as you're making changes, as you're bringing these processes in, get them on board earlier. Show some walkthroughs of the design. Get some early input because folks will be happy to point out where they think there might be weakness, and you're not asking them to opine on it or attest or anything like that. Just getting them in the room early and giving a point of view on where they think that design is heading is important because they may not have had a reason to focus on it up until now.

85Michael Wolf

And I think one thing that you're pulling out in what you're talking about, of sharing the experiences of how an auditor thinks, right, how the risk team works through things and is concerned, is really is on us as a community to really push empathy as this massive skill that we need to grow, and that empathy of understanding, wow, this is a massive change for them. How can I educate? How can I evangelize? How can I pull them into my team and structure?

That's the reality of enabling that team to be ready because this is a community that is hundreds of years old as a skill, right? It's a little scary, guys. A little scary. Audit predates technology. And so you have to keep that in your mind to say, "What can I do to enable them?" But at the same time, similarly, because it's been around that long, there's so much change that has had to happen that they're also used to change. And how do we, though, feel empathetic around this and go, "What do you need? How do I help you? How do I embed you into me? How do I go from manual things to compliance as code and policy as code and build those teams?" But it is, as you're talking about, a very deliberate, we need to understand each other. We need to build this into our full stack teams.

86Yosef Levine

If you can imagine a room, I've got a story that may hit the point home. I love getting points across through stories. When we, Deloitte, from the audit business, when we moved to the cloud about four or five years ago, we took our whole IT department, the risk compliance, the security people into a room and said, "Okay, what do you do today?"

Everybody went around the room, kind of explained it. We had some consulting guys there and guys from our cloud practice there to help facilitate a good dialogue. And then we said, "Okay, well, here's what the cloud is. Here's what compliance by code is. Here's the processes that you need for hardening all the different services for all your different clouds, okay? And this is what we call creating DevOps capabilities that your operational DevOps individuals will now take. How does your world now fit into this? Let's put it on a whiteboard and figure out where the deficiencies and the gaps are from a skill set, from a knowledge, and how do we then fill those gaps with the right competency and skill set and retool to create this DevOps relationship so we can go fast?"

When we did that, I kid you not, if there's some people from my team here that were at that meeting, everybody was a ghost. They didn't know what in the world I was talking about. I'm looking around the room: who's in charge? It hit them like that. They had no idea.

So on the other hand, auditors embrace change. We're really, really good at change. We just have to be taken on the journey slowly and at the right pace, and most importantly, in a language that we can understand. So the translator comment, in terms of doing translation, becomes really important in getting to your end goals.

87Jeff Roberts

And I think it's helpful just to remember as you go through these journeys that your goals and your auditors' goals really are aligned. And so your objective is to drive to these new processes to enable your business. Your auditors are also looking at that, right? They want to understand, in the easiest way possible, how you're addressing risk, how you've managed that within your organization.

So it's starting those conversations early. It's being open and upfront. It's asking for input. It's not being afraid to have those conversations. It's in organizations that that happens, they're the most successful through these transformations.

88Matt Bonser

And I would just add, don't forget that there's different types of auditors. So you've got your external auditors who are focused on your financial statements and have requirements around independence and all that kind of stuff, and can only give you some input, but limited input as you're kind of going through the journey. But definitely bring them on the journey and show them what you're doing.

Then you've got your internal auditors and compliance functions. They're part of your organization, even if they're staffed by one of us, but they are part of your organization. They don't have the same independence requirements, and so get them in the room. Workshop with them, find out what they're worried about, show them a process and say--

89Gene Kim

Take them out to lunch? Is that what you said?

90Matt Bonser

Yeah, you can take them out to lunch. You can absolutely take your auditors out to lunch.

91Gene Kim

Your internal-- Yeah.

92Michael Wolf

Well, I think to a point, look, we as technologists are used to technical debt. We get it. We know how to deconstruct it. This is cultural debt. This is long-seeded cultural debt that to bring the auditors to now enable us to deploy at speed, resiliency, all the stuff we all want, we need to purposely break down that cultural debt.

93Yosef Levine

So I think there's another hidden question in here. How to make your auditors happy? So one thing that I tell the coders that I work with is you have a choice on different technologies to utilize in your applications, because we all have choices. There's monetary considerations, there's speed to market considerations. The more you use a PaaS service from a cloud provider, the happier your auditor will be because that PaaS service probably has controls coverage in the cloud provider's SOC 2 report. So that's something that you could do to help influence and educate the differences in the choices that you make from a development lens.

94Gene Kim

Awesome. Well, so, do we have unanimous consent that this is confirmed?

95Panelists

Yep. Confirmed. Yes.

96Gene Kim

Awesome. Another round of applause for our friendly auditors.

Closing Advice

97Gene Kim

So let me tell you a little bit about what we have in store for the next two days. Today, we have an auditors workshop, and we piloted this with Yosef and team in London. It's what you've wanted to ask your auditor, but were too afraid to ask. So the ground rules are, and you'll give more specific instructions, but don't wear your name tag. Don't say what organization you're from. The cameras will not capture you on camera, but you'll be able to ask all of your-- bring your toughest questions, and Sam and Topo will moderate that panel.

And because these distinguished auditors are so eager to help you overcome your obstacles, are doing the follow-up workshop, where imagine the same room, but then each one of these folks with their teams will be in four corners, and you can talk to each one of them with a little more confidence, in a less public setting.

So I think this was just a phenomenal demonstration of how much you want to help this community. So I want to thank you so much for that. Any parting piece of advice that you want to give to this audience in the last two minutes?

98Yosef Levine

Auditors are not scary. We're actually fun. So, the key is just engage early. Okay? You could actually use auditors to help you. If you're understaffed from a security lens, understaffed from a compliance lens, and understaffed from an automation engineer's lens that help you with compliance, your internal auditors could help escalate that need because now you're working with them together to protect your business and your entity. So think about--

99Gene Kim

That's a very powerful message.

100Yosef Levine

It's a very powerful message. They're your team.

101Michael Wolf

Yeah. And if you don't view them as your team, you got to take a seat back and rethink of it. They are your team and a huge asset for you. And I think to your point earlier about making auditors happy, if you've never seen the work that an auditor does, it's kind of exhausting. It is highly detailed. That's why we're all going gray here.

And so what you have the opportunity to do is understand their pain and go, "You know what? Could I automate a lot of this stuff for you and then allow you to now be more valuable in your efforts and strategic efforts?" But again, that's deliberate. You have to reach out. You have to find those partnerships within your organization. Pull them into your teams. When you're building out your OKRs, maybe one of them is about establishing partnerships with the risk team--

102Gene Kim

Wow.

103Michael Wolf

--and how you pull it in. Be very deliberate and action-oriented.

104Gene Kim

Awesome.

105Jeff Roberts

And that's critical to do just that. It's around the communication. Staying out of your silos and having those conversations, whether internally or externally, to drive these DevOps conversations forward. That's the only way you're going to get there.

106Matt Bonser

And I'm going to take a slightly different tack. Please don't forget controlling access and the configurations to the tools. Doing that and being very upfront about that will make your auditors happier.

107Gene Kim

Everybody, could you please give an incredible round of applause to these incredible auditors? Thank you.

Oh. There's one more thing that we need to do, in time, which is we're going to take a photo of everyone standing in front of this slide.

Auditors love DevOps. So if maybe--

108Panelist

Will love.

109Gene Kim

Will.

So if we can get a picture, maybe a thumbs up. Thank you.

110Yosef Levine

Our pleasure.

111Gene Kim

Yosef, hey, thank you again.

112Yosef Levine

Thanks.