Hello, I'm Rob Hirschfeld, CEO and co founder of RAC and in your host for the cloud 23 podcast. In this episode, we dive into a talk that I've been building and working on called the compliance deaf curve, something that is an evolving concept that tries to explain how companies fight compliance governance and standardization efforts, something critical to platform team and infrastructure platform team operations. This case, we'll get back to that conversation to try to decompose some of the mathematics that I've been using into more universal or more easily understood components, which is exactly what we did in the process, we built a compliance flywheel that I found really fascinating. And something that if you look in the graphics for this podcast, you will see an example of that work. This is one that even if you don't have the screen in front of you, I think we did a good enough job talking through the concepts that you will find it to be very useful. And if you want to, it will also be helpful to check out my compliance, death curve talk at least one has been recorded and released. And I will continue refining this talk and giving it at conferences, I hope like blucon, or some other vendor items as we go through the summer and fall. So check that out. It's a really good conversation, I know you'll enjoy it.
You're ready for some mad I would love to get pick up on the compliance death curve. And see if y'all had insights into how we would go do that. That's different.
Sure. Okay. Let's Let's go.
I, I haven't put a lot of thought in let me review where we were. Because y'all had a ton of ideas. And we'll we'll bring back where where we were. So I, I went through very, very briefly a couple of weeks ago, this this idea of the compliance death curve, where standard is sort of standardization and agility, where people are very, they're so worried about the bottom of this curve. They don't, they won't climb, they don't get into the innovation phase of the curve. And you don't need to rehash the really good conversation we had about why about why why this is happening. What, what we ended up doing this in the middle of another deck, sorry. Was, was I tried to recreate some of this as a mathematical formula, because I think it's helpful, especially when you're talking to business people to sort of put it into some simple mathematic, trade off type of conversations. And so I got into this agility, autonomy, agility is autonomy time standardization, that's this one. And then I broke standardization. And then but what what was tripping y'all up? Was this sort of these these? And these are misconception ideas to me. They're not they're not correct. But it's useful, is that what we see when people talk about, they assume that any increase in compliance comes at the expense, a part will come at the expense of agility. And so I was trying to capture that, in this sort of idea that agility and standardization are counter to each other. And the element you know, because I think a lot of people are afraid that, you know, if they're going to get better compliance, they're going to lose the agility to do it. Not everybody. And then the next one, I think that y'all found more frustrating was the idea that agility is that autonomy as a primary driver, and standardization is the primary detractor from agility. So as I drive up, standardization, I'm going to get less agility. And that's not true. But I believe this is in go ahead. Okay,
sorry, Rod. Can you go back to the previous one? This one, or No? No. Yeah. Would not be okay. Maybe it's my dyslexia but agility beyond the talk and standardization beyond the bottom?
No, in because if if agility increases in your organization, this is the myth of the way. The perception, the perception is that if if I'm highly agile, that if I can't be compliant
in the context of the myth, the position is correct. Again, in the context of the myth, right? Uh
huh. Okay, so are you going Miss reality Miss reality? Or are you doing a bunch of myths, I
have two minutes. Two myths. The other myth is that standardization or autonomy are opposed. The
one thing I have a problem with, if you put these back to back, I would bet if we could see them side to side, but
in as far as the slides go, is to go.
That's not what I meant to do. But again, like on the on the one hand side, you have agility signing session, divided by agility button, if you on the later one, if you move, standardization to the left of the equation, equal sign, then it will be much of the time standardization. So it's,
Oh, so you're actually yeah, that's a substitute. If you substituted in agility? Can I wonder how easily I can write on this? Probably pretty easily. Yeah. So if I substitute agility, and here, then what I end up with is, Oh, that's interesting. Hold on, let me actually do that. Or I have to I have to figure out how to undo the annotating. There's my patients, there's undo. Okay. But what we're what we're saying what we're saying here is that if you put all these together sorry, and do is do the substitution, then you've got a compliance equals standardizations squared. Oops, I picked up the wrong thing.
Divided by autonomy, right.
Why it's squared?
Because my drop is doing is it's his substituted agility with autonomy divided by standardization. Oh, yeah,
correct. Yeah.
I don't work at all. No, no, of course, like the like, these are two separate medicines. I don't know if it's even valid, to put them together, but
divided by an interesting idea, to to see the other two myths. You're right. They're myths. But it's an interesting point to do that, because then what people because we're going back to fears. And so people's fear is that in order to get compliance, that you're going to have to double down on standardization, and in crush autonomy,
right? Or if you move autonomy to the left, then then compliance times autonomy equals standardization squared. I see what that looks like.
So you guys feel like me? You know, throwing a wrench in the works here.
Hold the Hold on.
I don't mean swapping them. I just multiply both sides by compliance. Oh, dear, okay, so you multiply both sides by autonomy in this case,
okay. So it's equals, okay. And then then you? Well, that's okay.
I get like, this is probably completely nonsensical. But it can be fun to throw those around and see where the midst can lead. The three knows that. The
reason why I'm more reluctant to do this is that you're this is I think, I think this is a harder concept for people to understand than the idea that autonomy is you have to suppress autonomy to increase increased compliance. Yes,
again, which is almost like It it, it probably doesn't make much sense in terms of in terms of the actual math and it's far divorced from reality. But it can be a way of showing the absurdness of the myths.
I think you're right. Although I think if you if you talk to most people that right, then then they would they would tell you that we can't get in compliance without the standard police coming in and taking, you know, taking away all have our autonomy. And, you know, we're just destroying innovation. From that perspective, right, that's, I think, because I think a three storytelling of saying, Here's a myth, here's a myth. And if you combine these two myths, what you end up with is people's, you know, Harrer, that they're basically going to, you know, they're gonna have to have, you know, a doubling of standardization, in order to accomplish compliance. And that's what some standardization, people are usually okay with their, this is what they're really afraid of,
is, I strongly suspect that the misconception is what they think autonomy means. And this can, this has the risk of becoming political. But if you take the libertarian view of autonomy is I do whatever I want, whenever I want, then the myth is true, by default on autonomy is I have the freedom to, to do what I need to do or what I want to do within the scope. Dot I'm given. Then there's this math break star.
Yeah. And the other point, Rob, to your storytelling notion, just from a structure perspective, and call it experience is, don't put two lists back to back, put a myth put reality, put another myth, then put reality. And then if you want to combine the two, because otherwise, you're leaving people going, I don't get this at all.
I was saying, well, the ocean. I mean, of course, the tail risk also of putting the mids back to back is that people will start combining the mids like we just did.
And ended up with the ridiculous list.
So by so I wanted to talk about standardization. I want to go ahead. Yeah, I think we you know, normally we don't want to get into semantics, but this group often does, because actually, it turns out to be important. What I want to do is draw us a semantic distinction between standardization and modularity. That when people think standardization, they're thinking about guardrails and limitation of process to use existing process components, whereas modularity is providing a whole bunch of interchangeable reusable modules that enable the the outcome, right, so it's kind of like the Yeah, I mean, when when you think of governance and you think of control, you think standardization as luck. But modularity is kind of the positive spin on that, that the greater your modularity, the greater the agility, right? You get
to replace old parts and you like, like, if you want to, like to draw equivalencies. Like my choice of ankle for this would be the, what happened in the late 19th century with standardization of firearm formats.
What do you mean by
bullet caliber?
Okay, this is the you're going way back. Alright. Sorry. I see. Okay. Yes.
We can look at at the metric system or PVC pipes or all there's all those are screw types. Yeah. Yeah.
I mean, well, this is, this is where I went with where you were talking about guardrails versus reusability. Yes. Right. And then what was what was interesting is that I went a step further than that. And this is safety. And this is toil.
Okay. Yeah.
So the story, the narrative, the narrative here, is is different in that we're saying we're going to put in if people's perception is, standardization means more guardrails, we're putting in guardrails for safety, which which is, which is a, this is protection. Which is just fundamentally feels like a limitation. Right? Actually, I can go I can go further with this. And this is this is a limit.
I would perhaps replace that would risk reduction.
Yeah, yeah, I like that. Yeah, better business language. I like safety, because it's a more of an emotional word. But yeah.
And this one is acceleration.
Yeah, I can give you an early example of this, from my career, that when I was working at HP in the in the Superdome chipset group, one of the things that I did to create the test automation was to create the ability to automatically extract from the code base, the configurations of different multiplexers, within the chipset. And the way that I did that was by I created an event, data structure type, that could be called by the dozen engineers in the chipset code base, that would help them test their code more effectively. And so that's an example. So I created a module, which was an event, a hook, inside the code inside the Verilog, the hardware description, language code that these guys could use that actually made their jobs easier. But by doing that, I created all this automation, which resulted in not just acceleration, but also risk reduction. So modularity can lead to substantial standardization, without actually are reducing agility and actually can increase agility.
Okay, but I have I have a little bone to pick here. Please call it call it standardization, as in standardizing across a group of things that will always be used, versus standard, as in ISO, whatever, whatever, whatever.
Mm hmm.
Yes, big difference.
Big difference. And in the reading of this, Rob, I would say, you're either going to have to speak it or put it on the dock, that you're not necessarily that, that compliance equals subscribing to or following a standard, an industry standard CompTIA standard, an IEEE standard on something standard, right, a blessed standard standardization is choosing those things that you're going to standardize across an industry as a business practice.
Oh, so you're saying yes. But there is has to be standardization. Yeah. There
is also an implicit sense of standardization, meaning change. Because you're because it implies that you're in parenthesis interesting, does not call complies to the standardization and needs to be adapted versus model legislation is you have your process, you're splitting it into reusable parts that might result in standardization, or vice versa. Again, but like as Tyler said, standardization can drive modularity as well.
And, and you can have, you can have standardization without modularity, and that's always a disaster.
Yes, well, but modularity also leads to In addition to acceleration, it by osmosis creates adaptability. Yes.
I mean, we're all preaching to the choir here at once on a decision.
But what we're what we're what we're trying to do is frame these concepts and reframe these concepts for people. Because what we're right these are we're coming up with this inherent myth, right with the intrinsic pieces, a dog is barking at me a lot sorry, that that are keeping people from adopting. Right? St. They've resisted that standardization process, in part because they're reading this or a lot of good standardization process actually moves to modularity and goes down this modularity as this beneficial build. Whereas standardization tends to have the perception of being a restrictive.
Yeah, I mean, you get back to the definition, the dictionary definition of standardization is the process of making something conform to a standard. And my mind how I've always thought about it is that we use modularity to make standardization. work effectively, right, we use modularity to eliminate the downsides of standardization.
And this and this ends up being in part, right part of this is presenting the curve. But, you know, it's equally important to sit down and say, how do we present a standardization effort, so that it's not falling down this left hand track, but is presented as this is ways that we are reducing your toil where we're ultimately accelerating you. And so some of some of what the lesson here is that if we don't want people to perceive this big dip in agility, then they need to perceive what they're trying to get to is modularity, not a standardization effort? And the challenge is a lot of standardization efforts that we see are based on risk reduction. Right, that is the actual rate that's coming down from a from a from a leadership team that is trying to improve security or spend or right there's, there's those are the those are their benefits, and they're not selling the modularity reusability toil reduction side of it. As as the primaries, yeah,
it reminds me of the the early days of iTunes and the Apple App Store, where we had, essentially iTunes disrupting Napster and BitTorrent and the other, you know, peer to peer networks. And the reason why that was successful when so many other efforts in creating, you know, music sharing platforms, you know, they failed, because it was more work, where Steve Jobs was brilliant was he was like, Well, I'm going to make the experience for the users so awesome, that they're gonna want to pay for their music, because they're getting value out of that. And that's where the folks that push strictly on standardization, without thinking about utility and toil reduction, they have to go hand in hand you, you can enforce standards, but you've got to use modularity to make the user experience at least equivalent and ideally, much better when you move to standards.
Yeah, I'm just drawing a mental parallel between what you just described, like the standardization happening in one direction with the music industry, or at least the music distribution industry. And the last year is essentially, the reverse process of that in and I wouldn't call this standardization, I will I would just call this like, reduction of option or reduction of modularity on on the Reddit API's where they remove so much functionality that the the standardized, the standardized themselves, just because, or the modularity themselves, but because all of the third party systems that we're integrating with it, we're not working anymore, right there as well.
Okay, so So the problem that I have with this is standardization versus As modularity, it's not a war. Because one means to achieve. And the other is, you know, a best practice, let's say, and just have standard standardizing across how you can get there and what reinforces I think your point is, if you take the verses out, it's a step towards modularity, which at which brings guardrails, but adds reusability reduces risk and toil. Purdue produces some limitation, but creates innovation, acceleration and adaptability.
Right, I don't know if I would agree with includes part. No, no, but they do synergize on on the part, where do I agree with Joanne? Is that versus implies is zero, goes up moderately goes down, or vice versa. And that's not the case.
And a sense, modularity drives standardization as the best practice on resources and vice versa. And vice versa. It's I'm seeing a virtuous cycle in my head.
I think the interesting thing is I think there's a it's a, it's a present, it's a it's a presentation choice, is what I was trying to trying to say for this is that if you're doing a standardization effort, and you present it as guardrails and risk reduction versus a maybe modularity is the wrong word for this or maybe maybe what we what we actually have here is there's there's maybe maybe there's standardization is here and the word word here is different the word here is wrong.
Maybe governance I don't know.
No standard I would
just put that I would actually Rob I would put compliance at the top and leave standardization back where it was take versus out for a second
however placing a versus would like a double headed arrow
Yeah, exactly on
I would also replace reduces with causes or and shoes and because like it's not like risk reduction reduces total reduction is that oh, it's hard to spot tight reduction or
I was going to take risk and talk like like this out
I would not do that because then you're breaking the downward flow of benefits
Yeah, I like that
yeah, and then underneath acceleration put adaptability
I don't know if limitation is I would just like your recommendation um, this is the reasoning for this. Awesome going down down this like, right the way you are seem to have done done. This is like guardrails adds reusability risk reduction benefits total action, but you can also read this in the other direction reusability arts guardrails toward reduction benefits risk reduction. But did I don't see the outcome of acceleration being limitations so perhaps we can replace that with something that has a more positive shine to it.
Rules.
And this is governance. Gotta want governance to be a bad word here. No.
Good word. Yeah.
Actually, it's okay. IT governance.
Perhaps put it in the next line, like contrasted with adaptability or
inability observability conformance.
Yeah. Conformance is because uniformity. Yes,
yes. Perfect. And I would also actually, instead of putting compliance that at the top, I put it on the left of the standardization column and the right of the modularity column. Because these arguments go both ways, and they're both beneficial. I think
one of the things I want to get to as well, because ultimately, the idea with the curves is to argue that this this path, this standardization, during rails risk reduction, it's actually crosses over. Right. So this is part of the idea that, that these are presented as a choice. But the reality is that they're that they're all actually, you want both benefits. That's what I like about switching this to positive, like, this is positive, this is positive, these are all positives, the thing that I'm trying to get to in the, in the talk here, right, is that you have a perception that this process, you know, doesn't provide that a benefit. Right? When when it really does, because you're gonna you're gonna bring in both pieces, a lot of is just about selling, right selling these ideas. And
to that point, if I may, you unbuild if you can, you want to change your down arrows to be circular, this should be a circle background, because you introduce them as this goes to this goes to this. The your end of your end state is a circle. They're all they're all good.
Right. So there's a back there's a there's the loop.
Well, yeah, yeah,
we're not going to ask you to do smart art on the fly. Unless you want to that.
The other thing also is that, again, like us, you move down on these rows, you can swap any any in any individual roll left and right side, and still have it makes sense. Like standardization, leads to reusability leads to risk reduction, least acceleration, that is a perfectly sensible threat. So you might maybe want to add a second slide that shows that kind of variation there. I
like this, this is hitting at which, which I like is where this goes, this is showing there's a flow between all these pieces was
cool. Yeah. And you could actually also, from a visual perspective and an implicit perspective, show this as a flywheel. Part of it builds value on top of the previous part. Yeah,
no, this is okay. This it's much better say it's a compliance flywheel than a compliance loop. Because that's the that's what we're trying to get to. Right. The reason why the curve looks has this innovation phase and it is because of the flywheel. The flywheel is that
group. Yep, that's you got it. And you have to have modularity to have that.
Do you have to have modularity teller? Or do you have to have some form of reusability, which is not necessarily fully modular? That's
a good that's a good point. It is. Reusability is the outcome. Although and, and digital systems, modularity is a critical component of reuse.
I would say that. Again, it depends on the context. But internally, I would argue that modularity is an extension of reusability. Yes, you start making your components reusable. The final result is that your architecture is modular.
Right? And my argument, you know, my question and my comment is based on the fact that your goal you may not end up at an end state where all the modular, all the modules can be aggregated together, right? Not everything would fit together so beautifully, like a puzzle. You might have an odd shaped, it could be modular, but it doesn't really sit.
It can also be reusable without being modular.
So, sort of like a micro service.
We're out of time. I sense a semantic argument going in. And I'm gonna, I'm gonna break because we're at the top of the hour. This has been amazingly helpful. I still, I still have a math I'll put this back on the calendar a little while because I actually think there's, there's, there's, I want to do this. But there's an interest. I think there's a math equation back here that I would love to get your all's bright minds on. This? Yeah. I love how you were we took this because I think it adds a lot. Thank you. Next week, we're talking about AR VR and the vision Pro. Underwater, the underwater computer.
No, the fishbowl. Computer. And by the way, go check out my digital stand up with the Isaac. It came out really, really well. It's okay. Yeah. My five E's framework for digital leaders. Who, right? Yes, yeah, I
did one that that while that Isaac and his. His not so great timing was released right after Christmas when everybody was offline. But it was a it was a fun conversation. That was I really enjoyed it Isaac's an awesome guy.
Yeah. But yeah, it just it hit YouTube yesterday. And I think it he'll probably say something about it on LinkedIn. I will. I already put it out on Twitter. But very fun conversation. But I have a piece that will be published either later today or first thing tomorrow, which is actually the beginning of a book chapter called the quintessence of the five E's. Or E stands for everything not. Anyway, I will say
looks really cool. I'm gonna put here I have the link, I'll put it in the chat. So let me stop sharing. Just if people want to grab it. And then I'll, I'll put it in the show notes. Thank you so much. This was great. Talk to y'all next week. Okay,
by joselu by.
Wow, it's sort of fun to have a conversation that has such concrete, deliverables and impacts. And this, you know, watching how a talk gets made and refined in real time. You know, these, these talks, a lot of the talks, I give on big concepts, take, you know, months to refine and this type of feedback session is not one that's often recorded and broadcast. So I appreciate you listening through it to this point. And I hope you got a lot out of it. And if you give talks or you want to give talks, watching the process is part of understanding how to make your talks better, something that's taken me many years to learn and appreciate. We do this all the time and other interesting topics, too at the 2030 dot cloud. If you haven't yet, come and seen our agenda, please check that out. We post it at the 23rd iCloud and I would love to see you there. Thank you for listening to the cloud 2030 podcast. It is sponsored by rockin where we are really working to build a community of people who are using and thinking about infrastructure differently. Because that's what rec end does. We write software that helps put operators back in control of distributed infrastructure, really thinking about how things should be run, and building software that makes that possible. If this is interesting to you, please try out the software. We would love to get your opinion and hear how you think this could transform infrastructure more broadly or just keep enjoying the podcast and coming to the discussions and laying out your thoughts and how you see the future unfolding. All part of building a better infrastructure operations community. Thank you
