Balancing Compliance and Rapid App Development with Digital.ai’s Wing To

This is Textron tv. Hey guys, thanks for the throw. ai, and we're talking about how to strike a balance between, well, the speed at which we can build and deploy software, and all these compliance and governance regulations that we constantly encounter that are getting stricter as we go along.

Wing. Welcome to show, Hey, great to be here. How do we kind of approach this?

'cause it does seem like the pace at which we can build software is gonna only get faster, especially in the age of ai. And yet we do have all these requirements from regulations that, as far as I can tell, are just getting tougher as we go along. So a lot of organizations may be perhaps able to build software faster than they can actually deploy it, and it has nothing to do with the tech.

Yeah. Um, I think it, it's completely right. Um, there's, there's that constant tension because the organization wants to be fast and efficient with, um, delivering software.

But on the other hand, there's this real worry that whatever's being delivered, is it going to match what they expect? And are there any concerns to do with, um, uh, security, vulnerability sensitive personal information? So re really what organizations are looking for is how can they understand, um, what has been delivered, um, where, when it was done, who, who approved it and where it's going.

And usually that's done by a series of manual, mostly manual labor intensive gathering of information by the, um, by engineers, um, uh, documenters people from across the organization. And what we're seeing is that there's an opportunity to take advantage of the fact that a lot of this, um, the processes are already being automated. So an organization that's trying to get productivity and speed are pushing towards having, um, automated, uh, release, uh, pipelines.

They're having automated continuous integration. But the challenge is, is all scattered across the entire, um, the entire life cycle, the entire, uh, delivery chain. So what we're seeing is there's an opportunity and, um, tooling that will bring together all of that information and make sense of it.

And that's really the, the key to being able to balance those two things. One is, um, one is do as much automation as possible, then take that automation and the data that is, um, available and bring it together to start analyzing and build up a, what we would call a software chain of custody, rather, rather like, um, you see in the logistics or legal sense, this idea of understanding across entire process evidence of who, what and why, um, across each part of the lifecycle. So, um, really a case of how to orchestrate and bring together information in a coherent way to build that, um, type of reporting automatically.

I feel like all this comes to a head at the continuous delivery side of the equation. What is the current state of cd? Because frankly, I feel like historically we've all been great at CI and CD has been a little bit more challenging and not as many folks are down that path on the maturity curve.

So where are we as we head into 2024? Interestingly, I think it's, um, it's a bit of a mixed story. I think a, um, a CD in the small has been, um, more doable.

So what we're seeing is that, um, at the team level, is it we, we get organizations, um, or that, uh, and within organizations, individual teams, they've picked up this idea that, hey, we we're moving from, um, we've done continuous integration, we're now going do CD continuous, um, continuous delivery, and they build their own, um, release pipelines. Um, and they construct the, the tools they, they, the tools they want to use. I think as it scales is that's when we start having problems.

'cause two things, um, two things happen. One, um, especially with, um, large organizations, there's usually some dependency between the teams. So the, the fact that one team has done it and another team has done it a different way with different sets of tools starts causing some level of friction.

Because there are unfortunately, um, I think everyone would love to be in the ideal world where everything is completely loosely coupled, um, complete microservices, but it's where everyone's in transformation. Uh, there are a few very lucky born on the web, um, companies out there, but everyone else is dealing with the reality that we've got this mixed world. So what they're finding is that they've got this, um, um, they've got this mixture of different teams using slightly different tools in different ways.

And then I think the real rub is that to start with, it was great. We, um, people built, um, the pipeline. There were smaller teams, teams got a bit larger, started bringing on new people and the, these continuous delivery pipelines and all the, um, the tooling that goes with it, particularly as we go into, um, cloud environments, well, the stacks got more and more complicated.

It's now really hard to, um, make sure that the stack works in the right way. And what that causes is that the most efficient, um, proficient and experienced developers are now doing the work of maintaining these pipelines. And you've got this spread across all your, all your teams, all your teams have got the, some of the best people making sure that they're training up the new people, um, on, um, onboarding them and then managing the pipeline instead of being really creative and doing what they should be doing, which is creating really excellent software.

So I think that's kind of the state of it. And I think this then kind of comes straight into this, um, this idea of, um, compliance. Because not only have we got inefficiency people, um, really not maybe focusing on what we'd expect them to be, but all this information is now scattered across all these, these, these different teams.

And what we're seeing is that the way in which organizations are able to get themselves out this dilemma is fir first of all, applying some level of orchestration put across the, um, the teams. Because there may be some level of standardization, but best practice still says there's a degree of variation amongst the teams in terms of the tools they want to use. So how can we orchestrate across the tools?

And rather than assume that we can mandate the, um, the type of tooling and therefore have consistent yourself information, it's really how can we bring the information from different tools? 'cause there's always gonna be an ecosystem of tools. How can we bring that information together?

So really it's a, it's, it comes back to some that age old problem of orchestrating across an ecosystem, bringing together data from a new, across an ecosystem, but also taking advantage of some of the new trends. Um, there's a, there's, I'm sure, um, um, I'm sure most of the audience here is really assigned to hear about this idea of platform engineering, um, the center of excellence that is focused on providing, um, tooling. And that can help there because one, it's part of platform engineering and providing golden paths and workflows for doing that.

First of all, that of course helps out that first thing I talked about in terms of, um, productivity. Because engineers are spending their time building release pipelines. They can now take, um, recommended Golden Path, um, release pipelines and there's still some choice, but that's also an opportunity to build in some of the collection of data and the governance because that's, um, that's a way in which if we know there's going to be a golden path that helps the developer ga gives a great developer experience, but at the same time also embeds some of the collection of information we require.

That's like a double win. It helps increase productivity whilst setting ourselves up ready to do, um, software chain of custody. Um, I'd also say that one of the other practices of we're, we're seeing is that rather than worry about governance and compliance right at the end of the software delivery, rather like everything else is shift left.

You know, we, we had, um, shift left, um, um, testing, then we had shift left. Um, se um, security, there's really a, a concept of shift left and a continuous verification. So instead of thinking about just order approvals and compliance build on those into the pipelines and workflows so that as the software's going through its delivery lifecycle, we can do the checks, we can do, um, we can do, um, verifications, we can do, um, approvals either automated or even manual, but have it as part of the overall process.

Don't leave it till the end. I feel like a lot of the governance requirements have these controls that you're supposed to bake into your process somewhere, but the documents themselves are, shall we say, dense and a little overly complex. And so the average development team probably shrugs and goes, I have no idea what we're supposed to do with that.

But do you think that as we look at generative ai, it will become easier to translate those docs into controls that I can embed within my CICD workflow, Near term, tangible way of tackling that is actually part of this idea of, um, providing golden paths and, um, workflows and templates of teams. 'cause the, I think you're absolutely right. The average, the average developer, the average person, I think would have trouble understanding these documents.

And typically, and I think this is why really is, um, is definitely a team sport. Because when I see things such as, um, requirements or plans and audit, there's usually a separate team outside of engineering that has to understand and guide and recommend all this. And I think part of the opportunity for providing templates and workflows is to do that translation once and bake it into the systems.

Um, so that's one thing. But I'm seeing this interesting emerging thing around ai. And AI itself is interesting because generative AI is this whole promise of, um, promise of increased productivity.

And even the, even the doubters out there, um, are saying, well, yeah, for the right type of coding, it's going to give like 10, 20% and we're still in the early days. Um, of course that's now creating a huge amount of, um, headache for the rest of the delivery, the delivery pipeline, and all the other people involved including compliance. 'cause more code means more things to, to make compliant and govern.

So the concept of having more automation is definitely one way of dealing with it. Um, but I'm also seeing these, um, companies emerging that are, um, looking at, uh, generative AI to understand, as you say, the, um, the compliance documents and look at translating it into some more, um, meaningful way for, um, engineering organizations and possibly make recommendations to create, um, governance policies. And, and that's a nice kind of tie because the other thing that, um, another emerging trend that we we're seeing, um, that is helpful for organizations is this idea of, um, policy as code.

Because, um, there's one thing to have common governance and compliance in terms of we must collect this data, we must run these tests, we must run these scans. But every organization has a different take on what it means to be compliant. But so we all agree we have to do, for example, vulnerability scans and it should be part of every release process.

I, I would say that's kinda like a meets minimum. But the question is, some organizations say we can't tolerate any vulnerabilities. Some organizations say, well, as long as there's a, they're low risk and there is a plan to, um, remediate them, then we will let them pass.

And so that's a, that's a policy on top of the, the, the, the testing. So the idea that you can capture these as code so that you can then automate to checking off these. Um, and there's some, um, open sales, uh, projects like OPA that, um, are being used here.

So I, I think there's gonna be some interesting ideas. One, you can do this already, um, but it requires humans. Um, I think there's an opportunity in the future for generative AI in an assisted way to maybe take some of these different governance, um, policies and these different, uh, compliance policies and help help conform and 'cause create these governance policies that you could then apply as part of your, uh, tool chain.

So I think it'd be in, it'd be interesting, but I think it'd be the same as with, um, the same as people using AI in, um, coding and development. It will be augmentation to begin with. 'cause no one's gonna trust that.

Um, AI's gonna give it and, and then it's gonna pass. And, and no one's gonna accept the, the excuse of, well, AI signal. It was, okay, There you go.

Do you think that auditors will force some of these issues? Because historically there's not been a lot of love loss between security teams and developers. And developers often view security as an obstacle to be overcome and the security people blame developers for just about everything.

Um, but can we get to the point where maybe because the auditors are gonna get smarter and more, uh, vigorous in their search for issues around vulnerabilities and whatever else that will finally force this issue and these teams will have to come together? I, I think they, I think they will. And one of the things that's, that is a side effect of doing this better and being able to have the level of productivity, but the level of compliance.

If, if organizations, um, orchestrate, um, and federate information and, and automate it, one of the side effects of this is, first of all, you're, you're gonna get, you're gonna get compliance. So that, you know, that's kinda like the number one key thing. But if it's no longer laborious and onerous, then the value of this level of, um, compliance and knowing the, the, the chain of, um, the chain of, um, actions and um, uh, the approvals and changes, et cetera, is that it can be used useful to other purposes.

The first is troubleshooting. Now the reality is no, there, there always will be things that happen when things go into production. Um, I think, you know, everyone would prefer if they, we've never had any problems when it goes into production, but when there are problems that happen when things go into production, being able to trace back and say, well, what changed?

Who approved it? Did we have the same li Right? Libraries can actually help teams get better at troubleshooting.

So it, uh, it provides a benefit in addition to doing the compliance. And then the, the other area I see is, um, having value is actually on continuous improvement. Because what, again, in for retrospectives, when after software's been delivered, either if there is a problem or not a problem, um, you know, what goes well, what doesn't go well, you can almost then look at the, um, uh, the chain of custody reports and say, okay, in know, in the cases where we did well, we did these things well, we had these approvals, um, we had these, um, meeting of our meeting of our compliance.

Sometimes when things don't go well in retrospective, you can look at it and say, well, maybe we haven't got the right policies in place. Maybe we needed to do more checks. I think when it's seen as no longer just a, um, a burden, but seen as something that can actually be part of an improvement process or a, um, ability to be able to react faster, then I think then I think the, the value becomes much more so for an organization.

So what's your best advice going into 2024 here as to how people should affect this level of change? Do I just throw everybody in a room and lock the door until reason prevails? Or is there something I can do here that's a little more tactful?

I think, I think this, um, I think first of all, I think it's gonna become more important. To your point earlier, there is no shortage of extra, extra, um, governance and compliance being laid on organizations. I think the advent of generative AI creating, um, the opportunity for more productivity is also gonna force this tension as well in that, um, more organizations are going to have to be concerned about this.

Um, because no one wants to be the first organization to use generative AI code, um, generative AI assisted code and then find they've leaked, um, leaked things or accredited a backdoor that they hadn't anticipated. So this idea of having more compliance and more checks, being able to feel more confident about the risk is gonna be higher. I I'd say the one way in which to do this is to think about in terms of the overall transformation and, um, uh, in terms of things such as, um, moving towards, um, continuous improvement on say, agile or DevOps.

Because many organizations already thinking, well, how can I, um, how can I get to the next level of productivity? How can I get to the next level of, um, efficiency? So in doing that, they're already thinking about things such as, um, how can I, um, do better at doing automation or orchestration across my teams?

So typically there's gonna be tooling involved as part of the tooling. I would recommend we idea of continuous verification, bake the stuff in, take advantage of as that, as we do that transformation of gathering the data, because typically those transformations involve creating tooling and, um, embedding existing processes. 'cause we're all, typically it's a brand automation.

If that's happening, don't, don't do these things as an after fort, but build them in. And also then it'd be incremental initiative as opposed to, um, a huge project at the end, after having done all these changes, selected tools, then, then, then it's like, oh, we did compliance. Like, mm.

That, that's, that then causes a massive project at the end is it's almost like the un agile way of doing that compliance and, um, compliance and our governance. All right, folks. Well, you heard it here.

We're moving from talking about these issues to actually doing something about them in 2024 because well, it's expected and we're gonna have to figure out a way to respond. Hey, wing, thanks for being on the show. Oh, great being here.

Thanks a lot. All right. Back to you guys in the.