Brig. Gen. Luke C. G. Cropsey, the Air Force’s program executive officer for command, control, communications, and battle management, oversaw a panel discussion on ‘Operationally Focused ABMS,’ looking at how the military and industry are defining and refining the connected battlespace at the AFA Warfare Symposium on March 7, 2023. Panelists included Elaine Bitonti, vice president and general manager of connected battlespace and emerging capabilities mission systems for Collins Aerospace; Dan Markham, director for Joint All Domain Operations / Advanced Battle Management System in Lockheed Martin’s Skunk Works division; and retired Lt. Col. Ron Fehlen, vice president and general manager for Air Force and Space Force programs at L3Harris. Watch the video or read the transcript below.
Brig. Gen. Luke C. G. Cropsey:
Well, welcome to the session on an Operationally Focused ABMS. My name’s Brig. General Luke Cropsey, and for the next 40 minutes you’re going to be exposed to an absolutely amazing set of questions and answers. So strap in for the ride. I will also say that it’s somewhat ironic that they put the acquisition guy in front of the Operationally Focused ABMS discussion, but I assure you I’ve got plenty of accountability here in the audience. So as we move this conversation forward, recognize that I am now building off of a whole series of conversations that we’ve had over the last six hours in regards to what C2 looks like inside of the evolving operational context that we’re going to be discussing now.
And then it’s my privilege to introduce our panel members. So I’ll just run through the ranks here real quickly and then hand it over to you to give brief opening comments. So Elaine Bitonti is joining us from Collins Aerospace and she does business development for their mission systems. Welcome. Next to her we’ve got Ron Fehlen. He is coming from the L3Harris side of the business and owns the Air Force portfolio over there. And then rounding out the back end of this conversation is Dan Markham and he’s the director for Lockheed Martin joint all domain operations and advanced battle management system efforts. So without further ado, Elaine, let me turn it over to you for opening comments and we’ll just kind of go down the road here.
Elaine Bitonti:
Great, thank you very much. So I just took a new role. BD was my old role and with all good organizations we have changed. So I’m now responsible for our connected battle space and emerging capabilities at Collins Aerospace, which encompasses how we’re going to address JADC2. So we’re excited to be on the panel today. Collins Aerospace is part of Raytheon Technologies. Raytheon Technologies is one of the performers on the ABMS Digital Infrastructure Consortium. We’re also one of the performers on the Common Tactical Edge Node Consortium, which is looking at how we’re going to bring together the networks required for ABMS. So we have a really good deal of expertise. We’re excited to participate on the panel today. We also have a large amount of commercial expertise inside of Collins Aerospace. And so, one of the things we’ll talk about are business models that can be leveraged from the commercial sector to solving problems like ABMS. So thanks for having me on the panel today.
Brig. Gen. Luke C. G. Cropsey:
Absolutely. Ron.
Lt. Col. Ron Fehlen, USAF (Ret.):
Ron Fehlen, I’m the vice president and general manager for the Air Force and Space Force programs at L3Harris under broadband communications systems out in Salt Lake City. Long title, all that really means is I get the privilege of ensuring connectivity for our war fighters. We look at the networks, whether it be the tactical side and how do we get information forward to folks that need it at the right time, or how do we get information back to the operational centers or even to the strategic level. How do we do that in a manner that ensures a security of the data as it goes back and forth, resiliency of the network as a whole through various forms of connectivity and assurance, assurance that it’s actually going to get there.
Basically, the things that any of us would want if we’re in the middle of a fight and we don’t want to think about whether we’re connected to the network, we want to make sure it’s there. So that’s primarily what we do out of our business, as far as L3Harris, of course, we supply not only that level of connectivity all the way down to the tactical in the hand radios, and then as well on the sensor side and platform side and ensuring that we can apply those mission effects, as well as being the right place with the right sensors to pull the data back to make decisions on. So thank you for the opportunity to be on the panel, I’m looking forward to the discussion.
Brig. Gen. Luke C. G. Cropsey:
Dan.
Dan Markham:
I’m Dan Markham. I’m out of Lockheed Martin Aeronautics out of the Skunk Works ADP organization. As Luke mentioned, I run the JADO and ABMS portfolio for the company. That’s a broad set of initiatives across space, the rotary mission systems, aero and our missiles and fire control group and trying to corral all of those efforts. We have a number of different activities going on relating to the legacy, I’ll call it, of the ABMS program and what is built up to what General Cropsey is running now, in a number of different efforts on how to both bring the legacy platforms, which obviously Lockheed has a strong delivery history and interest in enabling into those systems, as well as enabling the data access, data processing and the software associated with those as part of the ABMS program. So thanks for letting me participate as well.
Brig. Gen. Luke C. G. Cropsey:
Okay, great. So just a little bit more context here for the audience. So I’ve already forewarned Elaine that she’s literally the only person that’s got a business background here. The rest of us are all card carrying members of the nerd herd. So three engineering degrees on my side with a mechanical engineering degree and two double E guys sitting over here on the other end. So you’re just going to have to take all of these comments with a grain of salt as we go through it, but Elaine’s going to ground us here as we get into this. The other thing that you should know is that we’re going to use a little bit of Thunderdome rules here, so I might ask one of you a question, but it’s like open season on how you want to jump in on it.
All right. So let me set a little bit of perspective for everybody when we start talking about what it means to be operationally focused. Within the broader construct of what we’re doing for C3BM, there’s kind of a ditch on both sides of the road that we’re trying to avoid. On the one side of the road, we have this thing that I’ll call status quo, and I think the room in general understands that doing what we’ve always done is not going to get us where we need to go when it comes to the future fight. The problem is that when over correct, when you hit the ditch on the other side, you end up in the ditch on the other side of that road. And the other side of that road looks like trying to boil the ocean. It looks like trying to connect everything everywhere all the time. And that isn’t going to work either.
In fact, if you talk to the secretary, he’s got a long litany programs that went with what I call the big bang acquisition theory in this problem space and it ended poorly. So the question is, how do you stay focused and aligned down the middle of this road? And what I’m going to offer to you in terms of the way that we’re focused between the PEO side of this conversation and the ABMS/CFT side of this conversation and the cross-functional team is headed up by Brig. General [inaudible 00:07:00] and Major General Olson with regards to the air and the space operations side of this business. So the way that we stay down the middle of the road, is by making sure that we are laser focused. I mean ruthlessly focused around the operational problems that need to be solved in order for us to win the next fight.
And when we talk about an operationally focused ABMS, what we’re talking about is a program that starts with the operational problem that needs to be solved and then works from that point back through the system. So as we talk about the conversation today, it’s grounded inside of this fundamental belief that if we can identify, clearly articulate the operational problem that we’re trying to get after and do that in a way that allows us to all share the same vision of what that problem looks like, then we can figure out how we back our way through the rest of that kill chain and the rest of the mission threads that are going to be required in order for us to solve this.
But from my perspective and set in the context here for the panel, when we say operationally focused, we mean operationally focused. Because, the alternative is what? Not operationally focused. I mean it’s like doesn’t even make any sense. So we’re all about solving operational problems and the things that we’re going to talk about, and I’m telling you that now, because you might hear words like system of systems and architecture and some things like that in the conversation, but you have to know that they’re all grounded back inside of that operational picture.
So with that, I’ll lob one over to Dan at the other end of this. And Dan, there’s a lot of conversation around how you design and engineer system of systems as opposed to what we’ll call the classic platform centric view of the world has been historically and what the implications are with regards to being able to solve these very hard operational problems at a system of systems level. Can you just give us some perspective from your corner of the world on what system of systems engineering looks like and how that plays into what we’re talking about today?
Dan Markham:
Oh, absolutely, and thanks for the question. Lockheed in particular, it’s interesting to start with that question, because we are traditionally very platform centric and we like to look at problems from a platform point of view. And as this has evolved, as ABMS has evolved and as the integration of those platforms work into the solution set, the ability to think about a number of different things, those platforms need requirements that participate, as that starts to boil up into the smaller systems of systems, how they participate with other platforms and then how they contribute into the larger C2 network or data processing network and data access network and how all those things start to play together and they start to, as I mentioned before, those platforms are both enhanced by the access to that data and contribute to that solution is all part of the way to look at that problem.
As we’ve started, in particular one of the contracts, you all are working the digital battle management network. How do we connect those things and start down the road, to your point, without boiling the ocean, think through individual mission threads. How do I task this system through this interface with access to this software and touching this particular piece of hardware? And all of those things can be from different companies, which is also a unique experience from a lot of our perspective that, that collaboration is critical and making sure that we are enabling that and partnering with both industry and the government is a unique experience that we’re all working through.
Brig. Gen. Luke C. G. Cropsey:
… Go ahead.
Lt. Col. Ron Fehlen, USAF (Ret.):
So I was going to say it is interesting too, as you described it sort of I’ll say bottoms up platform by platform sewing together the Legos so to speak. And it is actually very heartening to see the CFTs work. As they walk through that work the other day because it truly is at the top level asking what’s the task and the processes associated with being a battle manager. And the fact that you can describe it at that level then goes to your earlier point on, okay, but what problem am I trying to solve operationally? The functional decomposition, you can do that construct on the operational side because the beauty of it to tie into exactly what you just said, is as the CFT produces a model produces things like, again, as you pointed out, we’re going to be a little nerdy at some points here, but interface exchange requirements, IER, something that’s been sort of in the system but hasn’t been pulled forward for a long time.
Now suddenly it’s identification of, well I need this platform with this sensor to provide this information at this time. Okay, that’s now a at retractable problem from a system engineering perspective that as Dan said, we can take, well is it this platform or this platform that’s going to provide that? Who’s going to be in the operational environment at that time and whether it’s a highly contested environment or not, how do they operate within there and how are we going to be able to pull that information out? So having that upfront work from the CFT to describe what it is they need from an information and where within their processes is a key part of that. And now the next piece is really how do we get that information either as Dan said, either forward to the operator or back from the systems and sensors out there. And it really boils down to how do I connect those things. So at least we have some operational construct on the functional side to derive what’s important first.
Elaine Bitonti:
I think the other thing to add there is as you understand the operational construct and you think about actually how do you decompose that into a product that you would offer, really thinking about operational analysis on the industry side and how do we do that operational analysis, very left word in that process, not just at the platform level, but also at all the subsystem levels that have to interoperate the com system, the C2 system. Because, in doing those operational analysis and doing that type of modeling and sim, in a digital engineering environment up front, we can actually find a lot of things before we even progress to experiments and then further would progress to an acquisition. So I think that chain of events is also important to how you field system of system capabilities.
Brig. Gen. Luke C. G. Cropsey:
So let me follow up with that a little bit from the perspective and going back a little bit to Dan’s point that we typically think about designing fielding sustaining weapon system platforms at the platform level. And historically companies have made money over the fact that they’ve kind of owned the data around doing that sustainment work over time. And as we heard in the last session in this room, a lot of times those data lakes turn into data landfills. And in regards to how the data becomes ubiquitous across the system. Can you provide a little bit of perspective from where you’re sitting in the ecosystem as it relates to business models and how you’re going to monetize the capability you bring to bear when you’re no longer paying for the data, because data’s ubiquitous. So what does that look like as we move in the future?
Elaine Bitonti:
I think there’s some very interesting models from the commercial side. So in our commercial business, we run the largest global C2 network for commercial airlines. And as we looked at how that was done, the airlines actually came together and created the infrastructure, I’ll say they didn’t really charge for that because they knew they had to have the infrastructure to run all of the data. But then once the infrastructure was created, there’s many different ways that you can actually monetize the data. So on the commercial side, you can monetize the data by charging for the criticality of the data you pass.
There can be different tiers based on that. You can also look at a service based model based on how much data are you facilitating being transmitted. The third way that we look at it is sometimes the access to data, while it is ubiquitous and that can threaten certain revenue streams actually as an industry member, if you now have access to all of that data, you can reduce it down, you can use it to inform your future product roadmaps. There’s value in that. So I think there’s multiple different ways that industry can look at creating business cases. And there’s a lot of lessons learned we can take from the commercial side where that’s already being done successfully.
Brig. Gen. Luke C. G. Cropsey:
Yeah. Ron, Dan, interested in your thoughts from your perspectives.
Lt. Col. Ron Fehlen, USAF (Ret.):
So I would agree the bandwidth, quality of service type metrics, being able to incentivize that particularly, nobody wants to be out of the edge, not have any connectivity at all. You should have been able to design into that ahead of time. It’s not unusual for networks and systems to have, how many nines do you want from an availability standpoint. And of course air traffic control is one where we want a lot of nines. And certainly from an operational perspective we want that as well. I think as well, it opens up additional opportunities. It really is about suddenly as industry members, we may have access to data that we didn’t have before. So there is a little bit of that. I only had this much, but now I can see it all. How can I add value on top in exploiting that data for the benefit of the customer, again, from an operational perspective and within that framework, there’s a lot of value there and it can drive investment on our part.
Dan Markham:
From Lockheed’s perspective, the fact that a large portion of our business model is focused on the platforms and the integration of subsystems, with additional providers and through those partnerships. The access to the data, if I broke it down into the logistics components, we certainly value from maintaining a fleet, but from an operational execution perspective, which don’t get me wrong, logistics is absolutely part of operations. So y’all know I can’t really see all you.
So the angry faces of all the logistics folks coming at me, we can’t see. But from the operational data and the delivery of the sensor data, data as a service, and we look at that absolutely as how can we facilitate the connections through commercial providers, through commercial space providers, how does that mesh with the space systems that we are building that have different security levels and how do those things come together? All of that work still has, I think, value to the government and expertise that we can bring that helps us. We’re a business, we want to generate more business and we think we can provide that in a great way for y’all.
Brig. Gen. Luke C. G. Cropsey:
So as we think through, and this is a little bit of a sidelight, so I’m off script now, Thunderdome rules. We were talking about the data flow inside of this construct. And in order to do the kind of scaled problem that we’re talking about from a system of systems perspective, we’re not going to be able to do that with flat file paper. We’re going to have to be in a digital engineering environment. We’re going to have to flow those interface requirements, those data requirements, the logic, the multi-faceted, multi-layered set of things that have to all come together for an end-to-end system of systems to work, in to some kind of a digital space that allows us to segregate, modularized, partition the workup in a way that we can get at individually and know that when we bring it back to the table, it’s all going to work together.
Can you comment on any concerns that you might have from your individual perspectives about either the ability to get that operational environment into that space? So Ron, you commented on the CFTs work for that functional decomposition and where that may help or hurt as it relates to being able to pull that now into the engineering side of that and then use that as a way of scaling from a systems’ perspective, what you need to do with regards to that operational objective and how you tie that back to that problem that has to be figured out here at the end of the day. So Ron [inaudible 00:19:18].
Lt. Col. Ron Fehlen, USAF (Ret.):
So it’s a great question and I think one of the things I liked most about some of the briefings with the CFT, is taking those IERs and some of the chicklets essentially, and assigning those to systems that are platforms. I mean, we’re going to have platforms forever, because those are the end defects and so forth. So now it really is a, but what do you want from it? Because, the question really we’re trying to answer is not from a sensor and an effector perspective, what do I want from that system, that platform, from a data perspective, it’s no different frankly than the cell phones that we carry around every day. I suspect nobody in here has a flip phone anymore. There might be one or two out there, but I’m sure you’d rather have the latest and greatest from a cell phone perspective.
It’s because we demanded more data and more processing out of the platforms that we had. So by taking those IERs, by identifying them against specific platforms, it is the first step in developing what do I need from that platform? What does that platform need from me? And if now you take that to the next level of engineering and say, well, I only need a track file passed back and forth, so this is nineties AOL dial up type of speeds, versus, oh no, I want full motion video and I want to stream it to all the teenagers. So all of a sudden I’m thinking about Netflix and the house kind of thing and the streaming that we do there. I want that type of full motion video coming off the platform. Well, that’s a different bandwidth requirement, there’s a different security wrapped around that. And it may be now you’re in a different environment operationally, so you’re able to use high bandwidth, whatever the case may be, and there’s solutions there.
So it really boils down to as you go through that process of being able to identify that we can take it to the next level, match against it, and now say, okay, you want X out of this platform, this is how we can help you get it out of that platform. And now you can get to the point where going back to a little bit of what you were saying in the beginning is, okay, now we’re swimming in all this data. We’ve figured out what we need, when we need it and where it needs to go either whatever direction, and now what do we do with the data when we get there. And applying the CFTs work on top of that, now you’re down to the software applications piece of whether it be fusion, artificial intelligence, some sort of learning algorithms, whatever the case may be, that will drive you to be able to exploit that data to the benefit of the war fighter.
Dan Markham:
Ron’s done a great job of describing a little bit of the theory, I’ll go after, at least from industry’s point of view. And one of the challenges that I think acquisition, the acquisition community is going to have is the smaller you make that granular, either the government or becomes responsible for some of that interaction. And that’s a challenge. And there’s been various different perspectives on that and approaches to that. It also starts to drive, you mentioned kind of the business models and how we think about that problem on the industry side. The more those are exposed, the more challenging it is to build things internally. The smaller the projects the harder they are to monetize over time and get value from on the backend, the harder it is for us to justify further innovation.
So there’s a sweet spot in there that allows us to build things, sell things, innovate things, and deliver things that fit into this architecture when the boundaries are defined and there’s an understanding and an agreement, if you will, on how those things are going to be protected and competed, we welcome that opportunity. I’ve never met an industry partner that says, “I want to just protect it. My thing’s not as good, but I’m going to protect it and prevent competition.” And we all want to make sure the best is out there for the war fighter. So defining those interfaces is critical. Understanding the granularity is very important and as we go forward and build this and as the CFTs work and the models come forward, I think we’ll find that sweet spot over time.
Elaine Bitonti:
I think it’s also important also maybe even left of that process, is how is the open architecture defined and what are the standards that eventually define those interfaces? I think in our experience at Collins, whether it be communications system, avionic systems, we’ve integrated systems across multiple different platforms made by different OEMs. And many times the challenges happen where the government believes that they have specified the architecture to an appropriate level, but they left I’ll say a lot of interpretation.
And so, that can really lead to things where you get into these different data models and the interfaces don’t work and you run into significant challenges in integration. So I think a key part of that is how are we doing the consortiums that eventually set up the architecture, how are those interfaces decided and do you have a robust sampling of industry? There are people that do build platforms, people that build subsystems, because I think in that type of collaboration is how you’ll eventually get the outcome that you’re after. So I think that’s one of the biggest challenges we’ve seen from our experience.
Brig. Gen. Luke C. G. Cropsey:
So let me pull on that a little bit more. So obviously getting the, I’ll say the packet size, how you decide to do your modularity inside of some of these conversations becomes a primary driver with regards to how the rest of this conversation flows. From your perspective, and maybe going a little bit deeper on the defining interfaces and standards conversation, but in the broader context, what do you need from guys like me to be able to do that effectively? And in terms of the context where those get set a little bit to your point, is there a better way to get after those kinds of things with regards to how we set those up?
Dan Markham:
I’ll jump in first, because then it’s easier than you guys can try and figure out the hard problems. Call it communities of practice where those standards are propagated. I think by and large, the Air Force has done a very good job of that in establishing what they want to do from an architecture and a messaging perspective, making sure those are set and I’ll say demanded from industry to keep things consistent, security support. Anytime we’re crossing these boundaries between whether they are SAP, all the way down to [inaudible 00:25:27], frankly, all of those things require government approval and active participation in the development of how those things are going to traverse.
And then the last thing, and this is almost a throwaway line, it happens a lot. The interfaces between the Air Force and the Navy and the Marine Corps and the Army, we work those on the industry side all the time, but ensuring that there’s active partnerships and communication with those other services ensure that those things are participating in what we are trying to deliver to the war fighter early, such that we don’t show up and try to connect to something with the army and then have to do translators. It’s not effective, it’s not efficient. So those are the three things that immediately come to my mind, the easy ones. Good luck.
Lt. Col. Ron Fehlen, USAF (Ret.):
And I think it’s fair, vision wise would love to organically no matter what service you’re in, be able to step into a joint force and turn on and now all of a sudden you’re connected. Great vision. To your point, there’s two ditches there and you got to stay in it. So how fast do you want to go and what are the first four steps that have operational value from that perspective. On the interface side and the modularity piece, I guess one, I was an acquisition officer for 18 years, so active duty. And one of the things that we always struggled with or talked about and wrestled with was how small of a box do we define? How big of a box do we give industry to define? And in the end, is it enough of a black box?
And I’ve defined the interface as well enough that I will have a sufficient level of competition within there over the time horizon that I want to, but it’ll enable me to go fast. And I think some things that I’ve seen in the past, and I think some of us have experienced is a little bit of the over specificity. There’s some things that we’re doing on our side, whether it be in cooperation with other services or other partners that might be unique and innovative, but if you make the box too small, then now suddenly it rules it out simply by how you define the box. So finding the right side of the box from a modularity perspective allows us to compete and gives incentivization for innovation within that black box.
Elaine Bitonti:
I think the other thing to build on what Dan said is, as you step back and think about it from a business case perspective, when you’re an industry and you’re trying to build a business case, let’s say you’re trying to sell a communication system. If the open communication system standard for the Air force is different than the Army, than the Navy, that impacts how you build your business case. And sometimes there’s good reasons that there may need to be differences for operational reasons, but other times I think one of the things we would request from you is it is more so lack of communication, lack of coming together on what is the actual need?
Because, I think many times we see as industry where things could be more common, it just wasn’t set up that way. But if they’re more common, you can draw more industry partners. Industry can build a bigger business case over more instantiations, whether it’s a platform or a network or whatever. So I think that that piece is, many times I think when we speak to customers they say, “Oh, we didn’t actually know the other service was doing it this way.” We’re the ones telling them as we try to go make the business case.
Brig. Gen. Luke C. G. Cropsey:
So we’ll kind of wrap up with this one. It’s a humdinger, so feel free to take it wherever you want to, but where do you see the biggest barriers to us getting to the kind of capability that we’re all talking about being able to deliver, whether it’s from your interactions with us on the government side or broader industry related kinds of things. And then any observations about thoughts on how to fix it? So major barriers and then any thoughts on where to go from there?
Elaine Bitonti:
I think two major things from our perspective. One, is I think industry is going very fast. We can go very fast, we can develop capability, but there’s a lot of supporting or enabling entities. You have to have IATTs, you have to have crypto certs. So your organization is trying to move fast, but there’s all these other supporting entities that have to have things happen in order for the entire process to change. And I think one of the barriers we see, is we see increased speed in certain parts, but those enabling supporting partners maybe still are not moving at the pace that’s needed for what the war fighter requires. And so, I think looking at how do you accelerate that entire chain is maybe something that hasn’t been focused on that would be helpful.
The other barrier we see is are glad to see things like your organization and the authorities that are in it. I think from an industry perspective, what we’re waiting to see is what are those first platforms where the platform PEOs, because those are the ones that still exist, actually take what you specify and how do we see that manifest in acquisitions for platforms, because that’s the way that things are done today. And so, I think from our side’s, it’s not as much a technology barrier, as it is barriers within the current system and how it operates.
Lt. Col. Ron Fehlen, USAF (Ret.):
And I’ll offer a slight variation, is that there is the model of you hand out requirements. Sounds like an easy job by the way. Probably somebody’s going to want you to pin a check to that requirement as well as it goes over to PEO to actually implement. And then there’s other models where it’s more centralized. You want to be a part of moving the data, this is the system you need to have on your platform and whatever level. Again, what size box do you want to put that in? And then you are delivering from a GFE perspective. So part of the challenge is just understanding where that’s going to land, whether or not that’s more, again, specific by platform specific. Again, the platform centric type model, that’s the organization as it is or more of a centralized that distributes out. We’re very interested to see where that piece lands.
And then I’ll say, a little along the same lines is a unity of purpose. We all know, if we want to go fast, the number one thing you have to do is have the objective. Number two, is unity of purpose and it is some of those support organizations. And so, you’re in that enviable position of having some piece of influence over it, but maybe not direct control, no different than what I saw as well. But if you can get the unity of purpose, whatever functional, from contracting, to security, to finance, etc, sort of all on the same team, focused in the same direction. It’s not that things are a wave to go fast, it truly is. Everybody understands what we’re trying to get to. They play their role on the team as they should and you’re able to just move quicker.
Dan Markham:
I’ll build on. Security is always an issue, but I think we’ve hit on it a couple of times. I really love that Ron, that the unity of purpose problem and a lot of folks out here in uniform, what we have seen and observed as we put hardware and software and systems in the user’s hands everywhere from the specific line users, the enlisted troops executing on the edge, to the test community, DT and OT, to the acquisition community, to the leadership. It almost strikes me as someone at some level the messaging campaign, which it’s almost hard to do. You don’t want to feel like you’re going out there advertising your solution and that’s not really what I’m suggesting. It’s back to what Ron’s offering, making sure that everyone understands we’re giving you this piece of equipment so you can provide us feedback, because the users say, “I don’t want this piece of equipment, this isn’t what I wanted.”
No, this is part of the process. And the more they push back on that, the less value perhaps we get. And that is absolutely one of the barriers we see that we’re constantly working through. So that partnership to establish that clarity across all the spectrum, which is, I don’t have an answer for you other than just get it in their hands and take their feedback when it comes and have thick skin, which that’s something we all have to deal with, is really where I think one of the big barriers in addition to what we’ve already talked about.
Brig. Gen. Luke C. G. Cropsey:
Great. Well the good news is I know a guy who happens to have quite a bit of interest in figuring out how to get to the unity of effort piece that you talked to. And I think to the point that you’re making Elaine, there’s an open question. I’m as interested as anybody with regards to kind of how this plays out. To Ron’s point, is it more of a centralized and decentralized execution kind of a model or is it back to more of a platform basis? We’re working our way through that right now and should have better answers for you here in the near term.
But I think all of those things get after this underlying fundamental belief that we’ve got to figure out how to do the integration problem at the next level up from the platform. And we live in a system that was designed to do platform integration. So culture eats process for breakfast and it’s like brunch time right now. So we’re going to keep after it. I appreciate the perspectives that y’all bring into this and we’re going to absolutely stay tightly linked with all of you on the industry side as we go down this path together. So around of applause for the panel. Thank you.