RedMonk co-founder James Governor speaks with Mike Long, CEO of Kosli, about the challenges and evolving practices of software governance and compliance in regulated industries. They explore how sectors like finance, automotive, and healthcare face similar software risks despite differing regulatory language, and discuss efforts to create shared terminology and control patterns. The conversation also covers how modern platforms, including Kosli, help organizations automate compliance, improve delivery metrics, and streamline audits by maintaining detailed, real-time records of software changes.

Rather listen to this conversation as a podcast?

 

Transcript

James Governor
Hi. I’m James Governor, co founder of RedMonk and I’m here today with Mike Long, CEO of Kosli and we’re going to talk about something that is kind of interesting. It’s not necessarily the thing that you necessarily expect to be talking about from a developer perspective, but certainly anyone that’s working in software engineering and development in any large organization is likely going to have to be thinking about that and that is governance and compliance. So welcome Mike. And yeah, I mean I think as much as anything else it was interesting to see Heavybit, renowned investor in the developer tool space, recently invested in costly. So congratulations for that. Why do you think such a dev tools friendly company thought they should be investing in compliance?

Mike Long
Well, I think it goes down to really the background of both the partners and the fund. But also, I mean it’s more than DevTools that have you a bit focused on. It’s really the infrastructure layer for software development. So they’ve had data platforms, infrastructure companies, data companies. We kind of fit in between all of those spaces. And I think if you’ve been in the space long enough, you realize that software delivery in these areas, especially in regulated areas, the compliance and the governance around that is so important and it’s a big unsolved problem so far.

James
And so let’s talk about that a bit. One of the things I find really interesting is having spoken to sort of companies in pharma, in banking, in telco, in automotive, certainly the German automotive market, it’s interesting because they all think they’ve got a unique snowflake of a regulatory problem to solve. They all think that their particular industry is the worst and their regulators are the worst. But actually there’s quite a lot of commonality in that. But from a language perspective, let’s drill into that a bit because I think that we’ve spoken about this before. Is there an agreed language for talking about how to drive better governance in software delivery?

Mike
Yeah, I think it’s actually quite helpful to look first at the industries because you’re right, everybody does. See, we’ve worked with automotive, defense, medical device manufacturer, financial services. Everyone kind of feels like they’re very unique in this situation because they’re either meeting different standards like ISO and SoC2 and so on, or Fedramp or military specs or FDA levels, or you know, essentially just getting audited by the financial regulators. But from a software perspective the risks are kind of the same, that you don’t want the X rays to go off at the wrong time. You don’t want the car to drive off the road. You don’t want transactions to be going to the wrong place. The risks are kind of the same in software regardless of the outcome. It’s like, well, do we control the process? Do we know what’s going into the changes? Do we control the risk of those changes?

James
Yeah.

Mike
And when you get down to the individual controls, they’re all the same. Like zoomed out, everyone has to have a process that manages the risk of software development. Everyone kind of needs to follow the process they wrote down. And then the third part is you need records of the proof that you followed the process because there’ll be someone coming to check. So that’s the same across industries. And then in between you’ve got this layer of, well like this is what, like we’re going to meet ISO 26262 if you’re in automotive or so on. So you’ve got this middle layer which is very language specific to industry often and quite vague. So you got this vague kind of description of the requirements. And then when you go back down into the technology, it’s again very concrete and similar. It’s like you must do peer review on your code. Like every code change must have been peer reviewed. Some industries call it four eyes review or peer review or never alone. But there’s like some story around that there’s artifact binary provenance or supply chain artifact tracking. There’s deployment controls, there’s release approvals, there’s really concrete stuff that every software engineer knows.

So at the high level it’s super the same. At the bottom, the implementation level it’s the same. And in the middle everyone uses different language and even within an industry companies will use different language for this stuff.

James
So that makes it harder. I mean, you know, we live in an industry that certainly from sales and go to market perspective does thrive on buckets. It is very helpful if we can just go, yes, this is the thing, this is the particular name. So anyone coming and googling it, or heaven forbid some of the other analyst companies that thrive on that sort of definition and naming. What are some of the different terms that you come across people trying to solve these set of problems?

Mike
At the high level it’s different things. So we happen to call it software delivery governance because it’s just about how do you get change to the production in a safe way, improve that. That’s kind of the story in a nutshell for us. Other people call it automated change management, governance automation governance engineering on LinkedIn right now there’s a lot of people talking about GRC engineering as a space in itself.

James
GRC engineering, I know about GRC, but GRC engineering is a bit new for me.

Mike
Yeah, it’s kind of broad in the same way that GRC is. So as I understand–

James
Wait, did we even say, GRC by the way, folks, is governance, risk and compliance.

Mike
Exactly. Yeah. And like GRC is a big space and like in a financial institution it goes from financial controls to physical controls to like all kinds of things.

James
Yep.

Mike
But like GRC engineering as it seems to be developing is more about how do we apply engineering practices to the GRC space in the same way that SRE was about applying software engineering practices to operational space. So I think like we all kind of are talking about the same thing when it gets down to the details. I quite fond of the idea of controls engineering. So there’s a particular control that you want to engineer in your organization, but that’s not the space that we operate in for sure. And you know, there’s lots of variations on those themes. Like if you look at Nest, for instance, they talk about policy enforcement points and we talk about controls. How you kind of work with this terminology is a bit of a mess in the space, to be honest.

James
Yeah, I mean, as I say, that is a problem. As an analyst, it’s an interesting challenge because at RedMonk we tend to think that it’s our job to use the language the industry is using rather than to making stuff up all the time. But on the other hand, there are like multiple industries, as you say, there isn’t even agreement within specific verticals, which is, it does make things challenging. How do you foster, other than like what we’re trying to do here, how do you foster a conversation to begin firming that up? I mean, what… when you like, so you’ve got a lot of customers in financial services, for example, are they willing to get in a room together and discuss what they’re doing that is common? Yeah. Tell me a bit about this sort of communities of practice and how you’re pulling them together and that might help to hopefully coalesce some of this stuff more broadly.

Mike
Yeah, I mean financial services is a really great example where we quite actively involved in an organization called FINOS, which is a sub structure under the Linux Foundation. So it’s a place for folks in financial services companies to collaborate on open source. But in practice, actually a lot of the conversation that happens in those forums and in the conferences there are about, well, how do you actually do this stuff? For example, there’s a subgroup within FINOS that’s looking at common cloud controls, which is, hey, we’re all going to use the cloud. How are we going to define what the best practices are for securing and controlling our use of public cloud? And that’s a great way, it’s like a place, a safe area for folks to collaborate even amongst competition. We’re quite actively involved in automated change management SIG inside FINOS where we’re working with major banks on helping to define, even at the high level, what SDLC control should look like. I have a feeling that we’re going to end up moving more towards something like if you’re familiar with software design patterns, where we come up with common control patterns that we’ve seen actually in the wild and give them a name that we can all agree on a context and maybe some implementations in different contexts as well.

So just like design patterns, we all know what a singleton or an observer is and if we could come up with similar definitions for peer review and for deployment controls, then maybe we can start to build this domain as like, if you go back to domain driven design. One of the challenges we face in product and marketing is that we can do these things at a very technical level, but everybody talks about it in a different way.

James
Yeah, yeah. I mean that shared language is super hard, super valuable. You know, previous era, showing my age here, there was actually some useful work in a standard that people really hate, or at least a thing called ITIL, the Information Technology Infrastructure Library, which for all its sins, it did provide a common language for describing, as you say, sort of patterns, the things that we needed to do, an agreed language. And I think that’s one of the things that enables us to commoditize, standardize and have common tooling to support.

Mike
It was also like ITIL was foundational in the sense that it kind of professionalized service management and allowed a whole bunch of tools to spring up in the space. Lots of software packages like ServiceNow is a great example. Right. Could ServiceNow be as big without ITIL? I don’t think so.

James
I think you’re probably right.

Mike
I think like every IT leader and every large organization knows ITIL. It probably has a lot of people certified in ITIL because they just want to do the right thing that everyone else is doing rather than build all from first principles.

James
So is this much, much blind but possibly slightly useful?

Mike
Well, yeah, I mean like one of the things I don’t want to do is to build the next ITIL. That would be a project for someone else.

James
Right.

Mike
But like, not everyone can, like Google, Facebook, all the FAANG companies have got really fantastic software delivery governance architecture. Right. They’ve built their —

James
Talk a bit more about that. Yeah. So what does it look like in… Yeah, what does it look like in those FAANG companies and what should be aspirational for an enterprise that wants to get serious about, you know, delivering more software more quickly and doing it in a way with the guardrails that ensure… yeah, they’re not going to get too far ahead of their skis, I guess. What does it look like amongst these leaders?

Mike
One of their major advantages is they have a very singular architecture. Generally they don’t have like sprawl that the typical financial institution has, so they’re able to institute things at a much faster clip. The other thing that, like, what they’ve all built is some kind of data platform around software delivery, which gathers evidence of specific facts that they need to be able to prove that they’re in control. Similar to costly, like record every build that happens. So you know when something runs in a given environment, what code it came from. Recording the bill of materials, recording any kind of gates around quality like code coverage, SAST and DAST and security scanning. Whatever you happen to have defined as controls in your sdlc, they’ve built it into typically golden pipelines or a paved path or whatever language you want to use around this. But the important thing is that everything that happens in the journey is recorded and then you can use that data to automate controls. And that also is the basis of your audit trail. And actually many banks have started down this journey as well. We have a really big bank as a customer who wanted to solve this problem and started on a build process before they realized we existed.

James
Did they set on a standardization process first or did they try and do it across their sprawl?

Mike
They tried to do it across their sprawl, yeah. Obviously those part of a platform story. Every company that has any number of software engineers has a platform engineering story. And usually it’s consolidation and getting from old legacy CI platforms and tooling to modern stuff. So, you know, you’ve got… I think we’ve had two waves, actually. The first wave was around containerization. Containerization and container platforms allowed a standard runtime which kind of cut out all the different snowflake servers that IT had to contend with in the past. So already you’ve got the same package of delivery going through your processes. And then it’s about consolidating the pipeline into… rather than having some teams on Jenkins, some on GitHub, some on GitLab. Consolidating on a golden pipeline where you can start to gather the information and enforce controls and standardization. But they kind of have to happen together. Right. It’s maybe worth touching on. Like, what is the alternative to automating this process is to do things manually with tickets.

James
Absolutely. Tickets and spreadsheets. Pretty messy, honestly.

Mike
CAB meetings are still really common in financial services–

James
100%.

Mike
–and its advisory board where as an engineer you want to make a change and actually you need 17 approvals and you have to go to a meeting that happens on the second Thursday of every month and say, please, can I get in in this change window?

James
Yep.

Mike
That’s just not compatible with continuous delivery–

James
Modern software delivery. I mean, it just doesn’t make any sense. That’s, you know, they’re all under pressure at the same time to be like, oh, you need to be doing. You need to be more like Dora. You need to do multiple deployments a day. Like, why are you not… the business is desperate for us to be able to roll out new functionality and then you have to go through the CAB and it just. Yeah, that doesn’t… They just don’t go together.

Mike
It’s kind of interesting as well is that like enterprises build organizational scar tissue so you kind of add more and more process and meetings and so on. It’s always easier to add a new rule than to take one away. Especially if you’re regulated. You don’t want to be caught without — and you don’t want to be caught in a state of non compliance with a regulator. It’s a big deal. But what’s happening is that you’re building up these rules that never get really taken back to first principles and evaluated like any other process in your business, you would be working on as a product, software delivery as a product in an organization. And this is the way, you know, we talk about software platforms as a product. Right. So we’ve got–

James
Yeah, yeah, yeah.

Mike
Typically we’ve got backstage, we’ve got kubernetes and you know, we’ll take care of runtime for you in this space. And that’s a product. Right. Providing a production infrastructure for engineers and to serve their customers as a product. But the path to production is also a product that really needs people working on full time to make sure that it’s being continuously optimized. And that’s what happens in all the leading tech companies.

James
Absolutely. I mean, so let me ask you, we’re going to have to talk about platform, we sort of did. We did a bit of homework. We said we were going to talk about, like, what are the issues rather than drilling into what specifically Kosli is. But I think actually it’d be quite helpful to ask what exactly Kosli is. So from an integration perspective, what does it look like as a platform? You mentioned this sort of fitting in the data space. What exactly is it and why is it relevant to this sprawl of dev tools, management tools and everything else involved in building software?

Mike
Yeah, sure. So, I mean, at a high enough level, Kosli is a data platform for software delivery. So we record what’s running in your environments, like the cryptographic fingerprints of all the workloads as they change over time. So we kind of build this forensic history of what’s running that can be container platforms, cloud runtimes. It could be a server with a disk, you know, in the basement. It doesn’t matter. As long as we can fingerprint it, we can track change. And that’s like the core of our engine. Right. Make sure we know how our systems change, not how we wish they change, not what’s in a ticket, not what’s in the desired state and a git repo, but actually how the systems change over time. That allows you to go back in time and say, what was running on Christmas? How has this system changed in the last 12 months and so on.

James
So it’s just like a flight recorder for your software delivery?

Mike
It’s exactly that. It’s just like what’s going on over time in your systems. And then now you have this, the next part as well. Those changes, should they have happened, what do we know about those changes? And this is where we would add some logging into your pipeline. So you might want to record your software binary builds like the build happened this build, and at this pipeline, at this URL from this git commit produced this Docker image with a sha256 sum.

James
Okay. So you’ve got that level of granularity in the telemetry, okay,

Mike
Exactly. And it’s the SHA256 Sum that allows us to do everything. That’s where you get the secure chain of custody. So anytime an artifact with a SHA shows up in any environment, that’s how you can say, oh, it came from this code. You can ask questions like, has this code ever ran in an environment? Or what code ran in this environment over time? That kind of thing. Yep. And then you can, from those pieces of data, you can add more like, here’s the code review here’s the GitHub pull request, here’s the sonarqube scan, here’s the SNYK scan. Whatever controls and evidence you need for audit or making deployment decisions can be baked into your pipeline and recorded and automatically controlled for at a certain level.

James
Okay. So rather than waiting, like quite often happens, today is the audit happens and then suddenly that’s the data gathering exercise. You have to go in, start trying to work out all of the things that were going on. It’s an absolute mess. Some expensive auditor sends in the juniors, they’re not necessarily understanding the domain at hand, where they have to go in pull of this, all of this information together and it’s kind of brutal. You’re saying that this is something that just, you’ve got that database of record already?

Mike
Yeah. So, okay, that’s what caused the… well, why do, why do companies buy it? There’s, there’s two reasons. One is to automate the software delivery governance so that you can go to production automatically. You don’t have to fill out forms, you don’t have to go to cap meetings.

James
Yep.

Mike
Like you just like. As long as you follow the rules and you have proof that you followed the rules, you can ship. That’s the first thing. So it’s like the impact that Kosli has is how do we improve the door metrics in this organization. And typically that’s by optimizing the bottleneck. And in a regulated industry that’s the change management process. So that’s the first reason why a customer’s bias. Now there’s a day two reason as well, which is audit. Audit is painful and expensive. You spend a lot of money, get an external aud auditors to come in, or maybe you have a big internal audit function, come in and ask the question like give me all the changes to the payments API in the last 12 months and show me that they’ve had approvals, scans, what code was running and I want to be able to. And that’s when you start like scraping APIs, taking screenshots, building spreadsheets and that’s. You already have all the data. You can just sit down with the auditor and provide it as they ask the question and give it to them.

James
Okay, okay. Well so all of this in an era of vibe coding is going to become ever more important and you know, vibe coding everyone. Don’t try it at home folks, certainly not on regulated industries. If you do not understand the software that you are deploying and what it does, that’s not going to please the regulators very much. But yeah, I don’t want to go too much into this AI conversation now, but you must be seeing organizations that have a greater need for greater traceability given that they are potentially at the moment just generating a lot more of the code than they previously were.

Mike
Yeah. So every bank is either experimenting with or have rolled out some form of AI copilot for the engineering and they’re seeing results. Right. More pull requests. So that brings new problems. Right. If bottleneck is still the software delivery process, you get bigger and bigger batches waiting to go to production.

James
Yeah, that’s no good.

Mike
With more and more code that people maybe don’t understand that well. So the risks are increasing. It’s just like — it’s the equivalent of slowing down your releases to it once every six months if you keep it once every six weeks. But double, triple, quadruple the amount of code change going out, you can’t do that without also increasing the level of control. So that’s one really interesting part. Another really interesting part is that as agents start to become more of a thing, I think it’s still emergent right now. But as autonomous systems make decisions, they also need records of all the things that they do. Like you can’t have an agent changing ports and firewall rules or database schemas without keeping track of these things.

James
Absolutely. Tthat’s why I think it’s going to be much more useful. So anyway, we don’t want to go too far down the AI rat hole now. It’s going to be a thing. I’ve got a request for people watching because I’m really interested in this. I mean, honestly, Mike. So here’s the thing. What the first, one of the first things RedMonk ever wrote about was what we called a compliance oriented architecture, where we were trying to work out what were the set of services that you needed to comply with an industry regulation rather than buying an application every time that you wanted to do. So this stuff is very interesting to me. What I’m interested in is if you’re watching this and you’ve got a name in your organization, what you call this governance of the software that you’re building, this compliance across the software that you’re building. I’d like to know what that is. So please leave a comment, let me know. Email me james@redmonk or Mike, what’s your email address?

Mike
[email protected].

James
So this was Mike Long, Kosli, and yeah, we’re both really interested in this. Compliance is not going to become any less important. Certainly geopolitics is very exciting at the moment. And with AI kicking off, the need for that sort of flight recorder, I think is going to be important. What do you call it? That’s what we want to know. So let us know. Mike, thanks for joining us. And that’s another RedMonk Conversation right there.

Mike
Thanks for having me.