How Faster Systems Integration Can Transform Defense Innovation

Speaker A: Foreign. Welcome to another episode of the Emerging Tech Horizons podcast. I'm Arun Sarafin, executive director of NDIA's Emerging Technologies Institute. Modern military operations are going to be executed using complex system of systems integrated through complex networks and using advanced software. Modern military systems are going to be built and deployed in order to take advantage of the best available technologies of the time and also of course, to meet the military requirements established to address threats or enable new operational capabilities. But for years, systems integration and interoperability between these systems have presented a, ah, constantly evolving challenge for the, the Department of War. Once these systems are deployed, operators and technology maintainers are faced with the challenges of integrating these systems with other fielded systems, sometimes old fielded systems, allowing them to acquire data from an ever changing array of data sources and sensors, and even connecting with commercial and allied systems. Despite advances in technology and Pentagon directives and strategies and congressional mandates, the military is still encountering these same problems today. There's also an understandable aversion, uh, and caution with the perceived risks of attempting to integrate new systems, software and data together with systems that are already executing national security missions and protecting war fighter lives very successfully. In the end, this has all resulted in frustration over whether the systems that we are using are actually taking advantage of all the capabilities that are available today as technology advances and, and whether we can ever hope to upgrade systems to match the speed of innovation. Maybe worse yet, these challenging integration issues are also reducing the ability of companies, especially new and non traditional companies, to provide new capabilities for the systems and even the systems of systems levels to talk us through how these challenges and some idea of how these new technologies, maybe new policies and practices can, can increase the speed of uh, digital integration and lead to better systems integration. We're joined by Travis Lamborn. He's the head of sales at NDIA member company Scale. Thank you for being here with us today, Travis. Tell us a little bit about your background and the challenges scale was created to address.

Speaker B: Yeah, you're welcome. Thanks so much for having me on today, Arun. Um, so I've spent the uh, majority of my sales career uh, between home services and an AI. Um, and really what, what attracted me uh, to scale was the, the type of solution uh, that scale offers, which we'll get into that here in just a little bit. Um, but scale, scale is solving these problems of the way that government adoption of new technology, uh, and new capability, the way that that is uh, acquired and procured a bit of a broken system unfortunately. And, and scale offers a way for government programs, um, to be Able to adopt new capabilities, um, at the speed of need, without having to rely back to the prime or the manufacturer, um, who delivered the initial solution in the first place. And integrating all of these different systems together is really the overall challenge that scale was, um, incepted upon, uh, to be able to come and solve these issues.

Speaker A: How big is scale?

Speaker B: We're small, we're a small team. Um, we have just a few, over 20, uh, 20 people primarily. Uh, almost everybody on our team is engineers, um, solving these complex problems on a daily basis.

Speaker A: And you really seem to be working in that space of integrating systems together at the data layer, at the software layer, modeling, um, how systems will integrate together, optimizing how systems will integrate together. So what kinds of products and services are you really working on right now?

Speaker B: Yeah, so we're, what we're working on is actually integration um, as infrastructure. Right? Because sometimes it can be misunderstood for middleware. Scale is not middleware whatsoever. Scale integrates to any middleware, directly to the infrastructure. So if you could picture this, um, you know, metaphorical of course, but invisible little crack in between middleware and infrastructure, scale is going to sit right in between that to allow any middleware to communicate to any infrastructure. Does that make sense?

Speaker A: And infrastructure is the, maybe the comms network.

Speaker B: Comms network hardware, like you know, you know, comms boxes on aircraft or ground vehicles, um, UAVs, UAS, you name it.

Speaker A: And I know some of the products that you guys are working on, um, is really focused on this, speeding up integration times. What are some of those, what are some examples of those kinds of products?

Speaker B: So we have two, uh, we have Phenom and we have Sync. So Phenom is where all the data modeling is done and that's where you're dealing with your standards on a regular basis. Right? So when you're coding and you're creating uh, an integration, whether it's a one off, custom type, uh, of integration, um, Phenom speeds that process up drastically. Um, it reduces the time spent by 85%. It also removes many different areas and margins for error. Um, because how integration is done traditionally is it's all hand coded, it's a one off integration. Um, it's never a reusable integration because if you go to try something new, whether it's add something new or remove something old, you have to completely start over from scratch. Um, and Phenom reduces that fatigue in that time that ends up taking using uh, the traditional hand coding methods. Now sync, Sync is actually uh, quite a special piece. So Sync is what's granting the capability of changing uh, the integration from a configuration standpoint. Um, so as you go along the bridge, if you will, of integration, instead of completely changing, um, as you go and building this bridge along, you can just simply reconfigure it. So look at it as um, if you've got a Mac, ah, computer and instead of going and changing the entire operating system just to turn on uh, do not disturb. The do not disturb is a configuration, right? When you toggle that on and off, you're not changing anything about the operating system. You're just doing a configuration for the time being. That's what Sync is doing for the capability aspect of uh, when you're integrating multiple M different systems together.

Speaker A: And then on the uh, phenom side, I guess as I understand, really simplifies the process of which you try to understand what's going to happen as you integrate these multiple M systems together or these upgrades in software into your existing system. Is that right?

Speaker B: Yeah, that's exactly right. Um, and you brought up a good point because it's predictable, um, it removes those steps and it creates a predictable environment. Because when you're dealing with standards and the standards are all, they're all embedded inside of a phenom, so when it's connecting uh, the different standards together from like a, Think of it as like a universal translator almost. You know, if you speak Celsius, I hear Fahrenheit, right? We speak two different languages. But that language translation is happening in real time um, for data uh, itself. And so reducing the steps that it takes to get there, um, you're also doing ah, quite a big risk reduction um, throughout that integration process.

Speaker A: And traditionally I guess I would always think over the years of trying to create these systems and systems with older technologies, admittedly these were lab projects or extensive uh, upgrades that require giant system integration projects with large contractors coming in and doing a lot of work. I guess I'm hoping we have to get past that. We need to get past that. Just based on what I see in a place like Ukraine, where it seems like the cycle of drone development to counter drone development to further drone development, in those cases technology is integrating in weeks. But traditionally in the US complex military system side, that kind of iteration, that kind of integration and new capability takes years and I would assume nobody wants that anymore. So I mean I, I guess you're seeing that this lends itself to, if we see that kind of speed of technology development in warfare, these kinds of capabilities are going to support, Support. But I'm curious. I mean, that's where I think it fits in. What do you think is sort of the sweet spot for the use of these kinds of systems and technologies?

Speaker B: Well, you, you said it yourself, right? I want to touch on that because the traditional integration takes years and that, that in itself, that gap really is that threat that we're facing for our national security because there's so many other countries that are so much further ahead of us when it comes to the time it takes to integrate things. And then also the, the willingness, um, to make that process quicker. Uh, it doesn't need to be as slow, um, or broken or as expensive as it has been. If, if we can supply a need to the, the warfighter and we can do so at an exponentially faster pace at a significant reduction of cost, it just simply doesn't make sense to no longer explore that. Um, and really the biggest threat to that process is the primes for the way that they've designed, uh, uh, their methods and models, uh, to be able to, um, provide a solution, um, to the end of the warfighter. Um, it, they, that process just takes simply, uh, too much time and, and it's far too expensive for uh, for the capability that you, and that you get. Because what happens is that by the time that that capability goes into motion, whether it's one, two, three years later, um, after the need has been identified, it's obsolete at that point and we're already having to adapt to, to new battlefield needs in the first place. So uh, we, we need to close that gap, um, because that's our biggest threat right now.

Speaker A: I understand that we all want war fighter feedback and the ability to iterate on the technology based on what they see and what they need and the threats that they're seeing. But that all sounds very complicated and done in situations which are high pressure, intense, you know, potentially dangerous for everybody involved. Um, I'm skeptical. Can this really be done out there downrange in the field, or in the end do you really have to go back to the lab, figure something new out, go to the test range, bring in the system integrator, and then deploy the next system like we usually do. So do you know, you have examples of where this has actually been done in the field?

Speaker B: Yeah, um, it's a great question, Arun, because it's something that uh, does get brought up, uh, regularly. Is, you know, can, can this actually be done? And the answer is yes, we've been doing it for 10 years now. So integrating at the speed of need is, is not only Available, but it's readily available for, for the warfighter. So one, one small example that I can give you is um, we were working with the army on a new threat detection system and we, we brought one of our engineers to uh, to this project and after it was complet, um, now we're going to time you, please integrate this new sensor, uh, that the system has never seen before. It was done in 36 minutes. That would have normally take a multi day if not multi week traditional uh, integration with multiple engineers completely reconfiguring the software itself um, in order to adopt that new sensor. And we simply did it in 36 minutes.

Speaker A: So how is that possible at the engineering technical level?

Speaker B: So between Phenom and Sync, um, with their capabilities and being able to take existing systems, which is expected, the legacy systems are expected, it takes that uh, expectation um, and being able to write in a new capability, it just simply is sped up, that process is sped up because of Phenom and Sync's capabilities uh, for the reduction of hand motions for hand coding and

Speaker A: how much work goes into this. Right. I can't imagine the warfighter sitting there writing code. Do they actually have to write code or do your folks have to come in and write the code for them? Who's doing the work and how much work is there here?

Speaker B: Great question. Um, no, they do not need us, uh, they do not have to rely on us whatsoever. We provide the training so that this can all be done in the field again at the speed of need. Uh, that's simply why we exist. And so we conduct the trainings um, to the individuals that will be responsible out in the field to do the implementations. Um, and so you typically will have a dedicated person or people, um, on the warfighter side while uh, they're in the field to be able to do the implementations. But short answer is no. The reliancy for us is simply just non existent after we've conducted training.

Speaker A: Another challenge is much more on the business maybe policy side. Is that the way that the department buys these systems and fields themselves? Um, it's very dependent on defense industry to understand how the systems operate. So if you step in and say yeah, I know you want to integrate that new sensor or I know you want this new feature because you see an operational need for it to upgrade that system though, don't you need proprietary information or contractor support from the original manufacturer to make it actually work?

Speaker B: So think of it, think of it this way because we don't need to have the permission, um, of the prime in order for this to work. So think of it as like the new AirPods, for example. It's a universal translator. If you're speaking Spanish, you know I'm speaking French, uh, very different languages. You speak French or you speak Spanish? I hear it in French, I don't hear it in your language, but I know exactly the message that you're delivering to me in the way that I speak. That's the solution that we're providing on a interoperability level. So if all these different systems that are integrated together, uh, that simply were never designed or intended to be integrated together, they never had each other in mind, they can communicate through a translation type of messaging and not have to change the way that the software operates whatsoever.

Speaker A: And I think you have examples of that, right? Some work you guys did on unmanned systems of systems, right?

Speaker B: Yeah, we've done a lot of work with the army, uh, we've done plenty of work with the Navy as well. Um, but we're actively working with uh, Army Devcom, AVMC and Huntsville, um, for the MSFTB M. And then we're also a prime, um, on a Sosa aligned satcom, uh, blos effort, uh, with L3 on our team. Uh, and that is for the F35 and the F15. And those are our two current projects that uh, we have our head down on right now.

Speaker A: But in all of these things and some of those primes and some of the existing systems that you're working to integrate, I mean, I would think you keep running into these IP issues. There's a lot of proprietary stuff that's going on in the system. Is IP a barrier for you?

Speaker B: IP is not a barrier whatsoever, um, because you don't need to transfer, uh, all of the data, communicate all the data through in order for the different systems to understand the message that one of them is trying to send. So it only hears, it only needs to send over enough information to say, hey, I want you to do this thing. And it doesn't need to hear why, it just says, hey, I need you to do this. So if one system says, I need you to do this, the other one says, okay, understood, I'll do that. And so you're not sending over that ip, um, all the way down to the data level itself.

Speaker A: Is it in theory possible that some examples that you've talked about are months long, but if I could tell you the variety of systems I might run into and the kinds of signals are sending out that my system needs to hear and integrate, you could speed those things up, especially with, honestly, with machine learning techniques, you probably can go faster and faster, right?

Speaker B: Exponentially faster.

Speaker A: And are you driving towards that?

Speaker B: Absolutely, uh, on a daily basis. That's been on our roadmap.

Speaker A: So I can see there's a lot of opportunity here. Anything ranging from integrated missile defense through Golden Dome to counter drone missions or drone mission swarms, or integrating fires. All of those things require this level of systems integration at the data level. Um, every time it's super complicated that whenever we try to put together systems of systems. So uh, you know, I, I see there's a lot of, I could see there's a lot of appetite for this kind of capability. But right now then, you know, everyone agrees we all need to do this. We've agreed on that a long time. Maybe the technology is ready today and it never was in the past. So what are the big challenges that might get in the way of this?

Speaker B: Well, one thing I did want to cover just before the jumping into, you know, the challenges, because this is, this is one of a, it does sit on a challenge side too. But it's also worth mentioning is, um, the Primes are a challenge because they can bury this, right? It makes them look bad. However, if they take the perspective of how this actually is an integration enabler for them, um, it is a necessary evil, uh, in some essence because for the prime, it becomes predictable integration. And predictable integration means that they can bid firm fixed price and actually keep the spread so they end up making more money and not have to go back to this labor based method. And so we are such an enabler for the traditional Prime.

Speaker A: And I think you're also creating a situation where systems that can be agile enough to incorporate new capabilities into them have a longer lifetime. Right. They're less, less disposable and they can withstand natural innovation coming from either within the department's own innovation base or coming from the commercial side. So I mean, I guess you're arguing that one way as, uh, an integrator could look at this is that this is a threat. The other way that they could look at it is no, this lets our systems grow and stay in the field for a longer period of time.

Speaker B: Exactly. Uh, that's exactly right. And it is strictly based off of a perception, ah, a uh, perception decision. If the prime decides to look at it in the way of how it can help them, they're only going to see the benefits that it provides them. If they choose to see it as a threat, they're only going to view this as something that they need to Push down and push away because it allows the government an opportunity to say, hey, we would actually like to have the same solution with more capabilities at a fixed cost.

Speaker A: All right, so one challenge is actually convincing them that this is not a challenge. What are some of the other challenges?

Speaker B: Some of the other challenges, um, is that integration simply has no budget line and no owner and nobody to sell to. Because one of my co founders said this to me and I laughed as soon as he said it. He goes, no one's waking up in the morning and picking up the phone and say, hey, I need to buy £5 of integration. Right? You can't just say, I want this much integration. And that's just what you buy. And so it doesn't have this, um, productized mentality behind it when it absolutely is, um, another, another aspect, uh, or excuse me, another challenge that we, that we face is, uh, is believability really. Because if somebody says or if we tell them, hey, we can do this in this amount of time at, uh, this much of a cost and time reduction, they're like, how, how is that possible? And compared to what we've been experiencing? And so the 36 minute demonstration that I was just explaining a few minutes ago, that ends up sounding like a really kind of a smaller problem. Um, when it's in the grander scheme of things, that's what's going on on a regular daily basis for the warfighter.

Speaker A: It's, it's also, I mean, systems integration interoperability has been such a challenge. I just don't even think people have, have seen it in ways that makes it believable to them. Right. So do you, I guess you're starting to sit on data from some of your experiments that then you could show to people.

Speaker B: Yes, absolutely. Plenty of.

Speaker A: Right. I guess the other challenge is, though this is probably less true these days, is that you're not one of the big integrators. You're not a big network firm on the commercial side. And so fighting your way in as a small business is also always a challenge, I suppose.

Speaker B: Absolutely. A challenge. And that's one that will continue to remain until we get past that hurdle, unfortunately.

Speaker A: Did you participate in any of the small business programs of the Pentagon, uh, early on, before you started to engage with the bigger contracts and companies we have?

Speaker B: Yes. Um, and on that topic as well is we've had multiple SBIRS, um, with the Navy and with the army, and 100% of all of our sbirs have actually gone to a phase three. And we've had one of those phase threes be, uh, a double, uh, where the Navy and the army both picked up the same phase three.

Speaker A: Yeah. So in your case then, the SBIR program has been proven to be a good pathway into bigger contracting with the Navy and the other services.

Speaker B: Yeah, it absolutely has. But you can't just survive off of the SBIR funding methods. Right. It has to move into a por, um, in order for the substantial growth that that is needed for us to uplevel and upsize, to have the mass adoption event, uh, begin, which is really what our government and national security desperately needs. Um, there's a couple of steps, uh, or a couple of gaps that we need to bridge, uh, first before we could actually get that type of an event to occur.

Speaker A: And do you have sort of best practices of how to work the SBIR program to achieve that?

Speaker B: We do, yeah. My, one of my co founders, Gordon Hunt, um, he's a retired, 31 year Navy, uh, veteran, um, he's very, very familiar with how to navigate, uh, that program. And so we're very blessed to have him uh, on our team. To be able to navigate those in a way that would typically take ah, an entire team, um, to be able to figure that out. He's able to do so on his own.

Speaker A: Yeah, that's great. And that's not a skill that everyone always has. And I guess I would commend to everyone that, you know, NDIA does a lot of work, our small business division working with the SBIR program to understand the needs of the companies and you get to meet companies like Scale that have navigated this system and maybe learn some of their lessons learned as well.

Speaker B: Absolutely.

Speaker A: All right, so we got to bring this all in for a landing a little bit. So I guess I'll ask you if you ran the universe, seeing what you've seen, the challenges of integration, navigating the existing contracts, the culture, the risk aversion. What would you do to improve our ability to make use of the current technology, which I've been paying attention to systems integration interoperability issues for 25 years now. It's always a promise and it never really quite happens, but the technology is different today and you guys are demonstrating that. So what would you do to improve our ability to actually allow for the quicker integration of new capabilities?

Speaker B: I'm so glad you asked. The very first thing, uh, that I would do, uh, 100% is integration is a first class citizen. It's named, funded and it's owned because integration is, it is more than 50% of the budgeted program whenever something goes to roll out, when if you say hey this is going to cost $50 million, you can guarantee that 25 or more million of that is dedicated to the integration side of things. So again I would make it a first class citizen so that it's named, it's funded, it's owned by, so that there is a specific dedication to it that would just simply oh my gosh, the friction would be almost non existent in comparison to what it is today. Um, another thing is by integration infrastructure, not integration services on repeat the way that we're doing it now today, government owned machine readable interface models uh, that are just simply reused across programs because it's re, what we provide is reusable integration. It's not something that has to continuously be one off unique hand coded traditional integration anymore. Um, and another thing Arun is I would say incremental research for incremental change. Because today's process punishes the modularity MOSA demands. Um, where you have to go and completely recertify, recertify, recertify. It's just, it doesn't need to be that way. Incremental, recert for incremental change.

Speaker A: Yeah, those are great. I think they get at a couple of hard issues, right? So even if you've convinced the technical people and the warfighters and you've demonstrated in the field, um, even if you've convinced the legacy contractors, one that their contracts allow this and second it's in their business instruments to allow this. The things you starting to point out here are more. There's no budget for integration. It's every individual program's problem until it becomes the war fighters problem. And no one ever paid for the integration upfront because there's no way to budget for integration. And then the other thing is I can move money once I have a requirement, but there tends not to be a requirement for future integration. Right? We've seen this in our work in multiple ways. One way we think about is why isn't there a requirement that the software in the system stays within some reasonable distance of the state of commercial practice. Uh, the requirements written to do a thing. And if you did that thing in 1983, you're good for all time, right? Even if the world changed around you in the same way, if you know all the systems around you are going to change and the subsystems within you are going to change, why wouldn't you write a requirement that says I need a system that is fully able to adopt and integrate the new capabilities they may Support me over time. Gosh, that's a challenge. And I guess there's some promise though, with the reforms, both in budgeting, moving towards a portfolio style system, and in requirements, doing away with some of the traditional ways of building requirements that these voices of, uh, well, what you guys want is jointness. What you want is tech insertion. What you want is interoperability. What you want is faster systems integration. Now you've got the tools to actually budget for it because companies like yours are building the technologies that could do it if they're, if you're just asked for. Was that reasonable? Did I get some of that right?

Speaker B: You, you're great, you're doing great. And uh, you hit it all right on the button, my friend. I, I, the thing is, look at it this way, right? When, when, when printers first came out, everyone had their own little pin connector, right? It was an absolute nightmare to navigate through. Then the pin connector became standardized, and then they adopted Bluetooth and then they adopted WI Fi printing. And now you can print from any device anywhere, for anything, anything you want at any time, just send it to the printer, right? That's the evolution that needs to happen across our departments because right now everyone's got their own pin connector. And, and it's 2026. It's, it's absolutely asinine. There needs to be the standardization process that I just went through with the printer for all aspects, um, uh, of our program adoption.

Speaker A: That's great, Travis. Thank you for talking to us today. You're welcome.

Speaker B: Thanks for having me.

Speaker A: I want to thank everyone for joining us for another episode of Emerging Tech Horizons. If you enjoyed this podcast, please don't forget to like our episodes and subscribe to our channel to stay up to date with all of our latest content. This podcast is available on YouTube as well as anywhere you get your podcast. If you'd like to see more of what we're up to here at the Emerging Technologies Institute, please check out our website@ndiaeti.org Also, please be on the lookout for information on the upcoming NDIA Emerging Technologies Conference, which is going to be held September 8th through the 10th in Washington D.C. with September 9th and 10th being at the Washington D.C. convention Center. Conference is now in its fourth year and this year we're going to have great keynote speakers like Under Secretary Emil Michael, Undersecretary Michael Duffy, and Assistant Secretaries Mike Dodd and Joe Jewellery. There's also going to be speakers from EUCOM and Africom and the Services and lots of different defense agencies and other OSW offices. On top of those keynotes and those organizations that are participating, we're going to have breakout panels and sessions which are organized by NDIA's technical divisions. Actually the systems engineering division is going to be doing a lot of work, uh, talking about kinds of issues that Travis talked about on, um, modern systems integration and mission integration. We're also going to have technical presentations and posters by subject matter experts. This year we're going to have tech demos. As well as hosting our second annual global hackathon for the first time this year, NDIA and the Society of Defense Financial Management. We're also co sponsoring a uh, data analytics and decision support conference which is going to be co located right with the Emerging Technologies conference. It's going to have discussions about how emerging technologies can support data analytics and decision support for the financial management, contracting and audit community and the budget community as well. Registration for the conference is now open. Please visit our website@ndia techexpo.org I want to give a special thank you to Emily Hayward for producing this podcast with the support of Mary Edens Maccabee and intern Abigail. Thanks so much for tuning into Emerging Tech Horizons.