In Orbit: A KBR Podcast
Though produced by KBR, this series is for anyone and everyone, inside or outside our business. We speak to some of the world’s foremost experts about the great challenges facing humankind today and about solutions to those challenges — what they are, how they work, the people who are creating them, and why they’re important for people like YOU!
That’s because whatever the topic, our main focus is people. Our goal is to connect, educate, inform and inspire.
In Orbit: A KBR Podcast
Accelerating Decision-making Through Systems Engineering
Did you miss us? Don’t worry, we’re back with all-new episodes to close out the year. First up is Tara Shifflett, chief of technology for the MAGS (Missiles, Aviation and Ground Systems) division of KBR’s Defense and Technology Solutions business unit. Listen as Tara discusses the ins and outs of systems engineering, how KBR experts are using it to accelerate critical projects and democratize data and decision-making, and what’s on the horizon in this exciting and game-changing field.
IN ORBIT: A KBR PODCAST
Season 5, Episode 10
Accelerating Decision-making Through Systems Engineering
INTRODUCTION
John Arnold:
Hello, I'm John, and this is In Orbit.
Welcome to the podcast, one and all. It's been a little while, but we are back with some all new episodes between now and the end of the year. We're going to try to get four or five more episodes out to round out this our fifth season, so buckle up. Whether you're new to the podcast or a regular listener, as always, we are glad you're tuning in and staying in our orbit.
Back in May, I had the pleasure of speaking with Gus Jordt, Air Force Acquisition's digital engineering lead with KBR's Mission Technology Solutions business. Gus and I talked about digital engineering in general, current trends, and how KBR helps customers using its digital engineering lab. Well, for this first episode in our blitz to years end, we're going to pick back up on the topic of systems engineering.
And I am thrilled that we are joined by Tara Shifflett today. Tara is Chief of Technology, working with the Defense and Technology Solutions business unit, which is currently part of KBR Mission Technology Solutions. Welcome to the podcast, Tara.
Tara Shifflett:
Thank you so much. I am super excited to be here today.
INTERVIEW
John Arnold:
We're very excited to have you. As is our custom, before we get down to the nitty-gritty, we would love to just hear a little about yourself, your career, and maybe how you got into engineering.
Tara Shifflett:
Sure. So as you stated, I'm currently the chief of technology for our MAGS division — Missiles, Aviation and Ground Systems. I have been with KBR coming up on four years. It has been fantastic. I enjoy what I do every single day. Previous to that, I came out of the Future Vertical Lift office for Army Aviation where I was their chief architect for the Future long Range Assault Aircraft. So a big chunk of my career for the past 10 or so years has been in the Army aviation space, supporting both future vertical lift and legacy systems.
Prior to that, I worked for an OEM [original equipment manufacturer], a large OEM that makes the Blackhawk. And so I was the mission systems integration lead for that platform. Enjoyed that very much. Prior to that, I worked in large commercial aerospace. So think OEM box provider for Boeing, Airbus, Bombardier type things. Spent about a little over a decade in the commercial aerospace world, and I really, really enjoyed that a lot. It gave me the opportunity to work on pretty much every system that causes an aircraft to fly.
John Arnold:
Amazing.
Tara Shifflett:
And that I loved because that's my first love, and that's why I got into engineering. I wanted to make things that fly. I think it's the most magical thing in the world, the fact that we defy gravity and that we safely transport people from one place to another. It's absolute magic and I love it so very much. And so that really gave me a lot of exposure to the rigors that were necessary to make things safe to put people in. So a lot of system safety type work, a lot of FAA type work, my first exposure to doing the things that are required to certify for airworthiness, things that I took further into my career as I went on.
Prior to that, I worked at Robins Air Force Base. So that was in Central Georgia. That was really my first job out of college. I graduated from Mercer University in Macon, Georgia …
John Arnold:
Hey, nice.
Tara Shifflett:
… with a bachelor's in electrical engineering and a master's in electrical engineering and went from there to work at Robins, supporting what are now no longer flying aircraft. So I'm that old, as my kids like to tell me.
John Arnold:
No.
Tara Shifflett:
I graduated at the turn of the century, and so they like to bring that up a lot. So 25 years, over 25 years actually at this point that I've been in this space and working on pretty much every aspect of aviation, things that fly for both commercial and military. And I've just enjoyed every bit of it.
John Arnold:
That's fantastic. I'm just up the road from Macon in Atlanta.
Tara Shifflett:
Oh, that's exciting.
John Arnold:
Yeah. And in fact, was talking to some people from Mercer just over the weekend that went to school there. So that's very cool. Small world. I wonder, would you describe what you mean future vertical lift, what is that?
Tara Shifflett:
So future vertical lift is the Army's initiative to supplement their fleet. So you've got the traditional army aviation fleet, which was Blackhawks, Apaches, Lakotas, Chinooks, everything that is a vertical takeoff and land, VTAL. And in the past 10 years, there's been a modernization effort to create a vertical lift capability that went faster and farther than what their current fleet was capable of doing. So they started the Future Vertical Lift Office, which then got split into the Future Long Range Assault Aircraft, which we now know as the Bell MV75. It's been named. It's got a model designating series now. And the FARA program, which was the Future Aerial Reconnaissance Aircraft, or Attack Reconnaissance Aircraft.
FARA unfortunately got canceled, but FLRAA is moving forward. So very exciting times for army aviation. And here in Huntsville, we do support that to move that forward from a digital engineering perspective, and with the hopes of creating a digital ecosystem for the army that allows them to continuously transform their technology and be able to rapidly introduce capabilities in a way that they've never been able to do with their legacy fleet.
John Arnold:
That is so cool. Something you said a moment ago definitely hits home. Every time I'm in a plane or see a plane, I'm reminded of my older sister who just — dropped-jaw dumbfounded every time she talks about flying. Just how human ingenuity has led to getting something so big off the ground is still ... I know that there's a lot of science, a lot of mechanics and engineering that goes into it, but it's still always awe-inspiring.
Tara Shifflett:
It really is. And then the fact that we've just added so many, what we consider mundane human experiences to the most magical thing. Like, oh, and we have to certify the coffee pot. So here's the coffee pot certified for flight. And here's your in-flight entertainment system because we can't not have Wi-Fi. So adding all of these uniquely human experiences to aviation flight, I think is really exciting as well.
John Arnold:
Absolutely. Well, we'll move on. Listeners to the podcast might be familiar with model-based systems engineering [MBSE]. I think you and I spoke when we did our preliminary interview about having Gus Jordt on the program. Previously, Gus did a great job of talking about KBR's digital engineering environment. But for those who aren't familiar with MBSE, would you just walk us through the nuts and bolts or lack thereof, of what we mean when we're talking about MBSE and maybe some different approaches and methods as well?
Tara Shifflett:
Yeah. I talk about MBSE often. I really want to emphasize the fact that MBSE is at its core, simply systems engineering. It is my fervent hope that in five years time we're not talking about MBSE as its own thing, but it's just the way that we do systems engineering. But when we talk about MBSE, it is the tool in the vernacular. So it's how we are describing doing systems engineering from a more tactical perspective. And so when we are doing model-based systems engineering, we are applying a language to it. SysML, right? Systems modeling language. SysML has been around with us well over a decade, probably 15 years or so. And SysML grew out of UML. And because it kind of grew out of another software engineering language, it didn't really focus on what as systems engineers we care about with regards to evaluation and design of a system. There's been a lot of work over the past few years to release the second version of SysML, and that actually happened this year where we've had SysML V2 released, I want to say two months ago or so.
And the focus of SysML V2 is to really use systems engineering vernacular in a more precise way. Why do we want to model a system? We want to model a system because we need to make design decisions. Because what ultimately is systems engineering? It is designing a system fit for purpose. And fit for purpose can mean anything from it needs to cost this much and it needs to be done on this time, or I don't care how much it costs because I absolutely have to have this. Everything becomes a design trade-off in that space. And when we do model-based systems engineering, we allow for that trade-off to happen in the collaborative environment, in that digital environment. It gives everyone the same data to make decisions with.
And so I think, like I said, I fervently hope that in the next five years or so, we're not talking specifically about MBSE, but it's literally just the way we do our job. I kind of liken it to, if you're doing electrical design, you don't think about the fact that you have symbology for resistors. You just look and you know that's a resistor. Or symbology for a power supply. And as we move into systems engineering, having symbology and a specific vernacular to it, that that just becomes the way that the next generation of system engineers think about the design of their systems.
John Arnold:
That's fascinating. Yeah. It'll be interesting to see how that does evolve just from a vernacular standpoint. So as we know, digitalization is changing the way we do pretty much everything in the world. So what are some digital engineering advancements that you think will help take systems engineering further in the near future?
Tara Shifflett:
So I'm really excited about how KBR has embraced digital engineering, and then created what we call our Digital Accelerators, right? So we have digital engineering, data analytics, artificial intelligence, cybersecurity, autonomous systems, and enterprise technology. So these focus areas of ours for accelerating. And I think that's the thing I'm most excited about, about digital engineering, is that as we are creating collaborative spaces of information, and that information is distilled more rapidly through the use of one of our Digital Accelerators like AI, right?
So now we have large language models that allow us to query repositories of information and give us the ability to make decisions on that information more rapidly than we've ever had to do. I think that's an important aspect of what we're doing. And to me, one of the most exciting things. I give this example a lot, and so people that have heard me talk, have heard this example about digital engineering. Some of us are old enough to remember when we had to write interoffice memorandums.
John Arnold:
Right.
Tara Shifflett:
So you would literally have to type something up and you'd have to put it in an envelope and you'd have to write on that envelope, this is going to Tom in the finance department. And then you'd have to wait for a courier to come pick it up, take it to Tom in finance. Tom would open the envelope, read it, have to make a decision based on the data that you had written down on this piece of paper, give that information back to the courier, send it back, right? That's very analog. It takes time. So then along came email, and I can email Tom in finance. And hopefully if Tom gets back to me at his leisure, I can make a decision more rapidly than having to worry about that. But I can also send it not only to Tom in finance, but CC a whole bunch of other people so that they're aware of this decision making process.
Now we have [Microsoft] Teams and we have collaboration spaces so that Tom can query that information that he needs in finance at any time because a source of truth of that is in his workflow, is available to him as part of his workflow. And I think that's what I get excited about when we talk about digital engineering is we're shortening that distance between data and decisions. And by making that available earlier in programs, we are reducing risk. We're helping our clients make better decisions. We are becoming good stewards of their money, the taxpayer's money, our time. And we are creating repeatable environments where we're not doing one-offs, where we can't replicate that information again. So I think that it's agility, it's democratization of data and decision making, and ultimately leads to better outcomes in the end.
John Arnold:
I love the tagline, shortening the distance from data to decision. And thinking about this standardization, so just spit-balling as an example, is this a situation where a client comes to you with a specific request about a system and because of that data sharing and information sharing, you're able to plug in exactly what they are looking for from a systems engineering perspective into whatever, not machine, but whatever program that you're using? It's not a room full of computers, maybe it is a room full of servers now. And then getting a pretty immediate answer as to what it would take to meet the requirements that they're asking of you?
Tara Shifflett:
That's not really that far off, right? So we have clients that come to us and they have maybe either legacy requirements. Hey, this is a PDF document that was written 10 years ago that represents our system and we need to modernize the system, but we don't know the impacts yet. And so we can help them to create a model of that system with all of its performance requirements, and that allows them to start seeing linkages between their system as it exists in the world, and how they think it's supposed to act. You would not believe the number of times those two things do not line up with each other. And so this gives us the opportunity with those clients to say, okay, this is what you currently have in documentation. This is what you currently have in reality. How do we bridge the gap so that you can make technology upgrades, capability upgrades, insert this new sensor, deal with obsolescence?
Because that's where we spend a significant amount of time. We would love to be in a position where the money that our clients are spending is to help them with fielding new capabilities. If you're specifically talking about military, you want survivability and lethality. Those are the things that we would prefer to be spending money on, but we spend a lot of our time and money on this part's obsolete now, what do I do? This thing is obsolete. I need it to just keep flying. I need it to keep this system running. I need it to keep this little piece going in my overall system. And that's not an ideal use of funds.
So what we want to get to a point is where we are continuously evaluating things like the sustainability of a system through its model. You can query that each of these subsystems now has this lifecycle to it. So what does it look like next so that you can seamlessly transition something into that.
So that's one end of the spectrum. And then the other end of the spectrum, you have what we call clean sheet designs. And a lot of those clean sheet designs are now kind of, we call them born digital. Meaning that they have been designed out of some sort of MBSE representation of the system. And in those cases, we are doing what's called virtual prototyping, which means that we are doing evaluations on that system more to the left of the systems engineering V, that allows us to say, this is risk. What are my trade-offs here, before we even start bending metal. Before we start putting components in. Before we start ordering parts. So those are kind of the two ends of the spectrum of where we are helping our clients specifically in that space.
John Arnold:
That is fascinating. If any listeners are interested in learning more about KBR Digital Accelerators, you can go to the website or just do a quick search engine search and the info will pop right up. It's pretty fascinating what we are doing, and what our digital tools lineup looks like. Before we got started, you mentioned something called INCOSE. KBR has a strong connection with the International Council on Systems Engineering, also known as INCOSE. So would you tell us about what that relationship is and why it's important?
Tara Shifflett:
Sure thing. So in about 2020, then Senior Vice President Pete Green was very visionary in seeing that it was really in KBR's best interest to become a corporate advisory board member to INCOSE. So INCOSE's been around for quite some time, 20 plus years of INCOSE, and it's been obviously internationally recognized. But what its mission is to bring together the best practices for systems engineering and continuously refine those, especially in this brave new world that we're in where digital engineering is taking over a lot of what we do from a systems engineering perspective.
So INCOSE really focuses on top level competencies that are core competencies, professional competencies, technical competencies, management and integration competencies. And from that, we have the INCOSE handbook, and the INCOSE handbook kind of goes into how each of those competencies produces technical processes. And almost every large scale engineering organization aligns themselves with the systems engineering processes in INCOSE. We all talk about the systems engineering V. Any engineer is very familiar with the systems engineering V, and that is recognized out of INCOSE and the work that had been done there on what it looks like to create requirements, to design something to build, to verify, to field it, sustainment. So thinking about the entire life cycle of a system.
And so when we started our corporate advisory board relationship with INCOSE, we decided internally that we wanted to set up a systems engineering academy in order to align with the INCOSE teachings, INCOSE standards. And so we are now about to kick off our fifth year of INCOSE Systems Engineering Academy, sponsored by KBR. In which we give monthly SE Academy presentations that align to, or present some emerging INCOSE topic that we want to think about. So for example, in the last session, session four, we did focus a lot on model-based systems engineering and what that brought to the table from an INCOSE standpoint because that was a really big thrust of what INCOSE was looking at, at both international workshop and international symposium.
So they have kind of two international meetings a year. And out of those, there was a significant focus on model-based systems engineering. Now, KBR is in a great position for that because as maybe came up in your conversation with Gus, we teach model-based systems engineering. So we actually teach that to our clients. We have classes that we offer and we have OMG certified systems engineering practitioners. And so that's one aspect of that. But then the secondary aspect is that we really focus on and encourage KBR employees to pursue and apply for their Systems Engineering Professional certification, so a SEP certification.
So there are three levels offered ACEP, which is the Associate System Engineering Professional. CSEP, which is the Certified System Engineering Professional. And ESEP, which is the Expert Systems Engineering Professional. And I think that KBR's focus on that has made us actually one of the highest representative system engineering professionals in the entire INCOSE organization. So I'm really, really proud of that. And every year we're producing more certified systems engineering professionals. And I think that that speaks volumes to the value we bring as system engineering practitioners to our clients. Because it shows that we are recognized by an international board. That we've gone through the rigor of testing, of interviews, of evaluation to be recognized as a professional with this. And that then shows up in the work, not only the work that we do, but in the proposals that we write.
John Arnold:
Yeah, that's fantastic. Not only from an expert standpoint within the engineering community, but also from a growth and development standpoint for our people. That is fantastic. Sounds like a great opportunity.
Tara Shifflett:
Yeah. We really want to focus on providing that growth opportunity, right? So even if you decide that you don't ever want to go and get your certification through INCOSE, we do encourage internal KBR SE practitioner levels. So you could never go and take the exam and we will still recognize you as a KBR SE level one, two, or three. Based on not only attendance and recognition of going through SE Academy, but also of doing professional development units outside of that. So you go and you watch a webinar on systems engineering, write it down, send us your log. We would love to recognize you with the fact that you are doing professional development to support our systems engineering capabilities.
John Arnold:
That's awesome. I wish that I was a systems engineer. I would go do it.
Tara Shifflett:
They're all available on Workday. Anybody can go watch them.
John Arnold:
That's important to know. So if you're listening along and you want to get some further development systems engineering, go check it out. It's free, 24/7, 365. We previously mentioned the KBR Digital Accelerators, which is this suite of digital offerings and technologies. What is next as far as systems engineering in that Digital Accelerator's rubric?
Tara Shifflett:
So I think what we should keep an eye on is that we have the KBR digital engineering environment that we will be launching soon. And that gives us the opportunity to provide not only the digital engineering tools that will be necessary to perform work, but also an environment that is available to all of our engineering practitioners and potentially to our clients for them to utilize. And I think that's a really important step, like I was saying earlier, is that helps democratize what we're doing. So it's not that any one person, "Oh, I don't have Cameo. I can't get to Cameo. I don't understand how to do MBSE." We are creating a digital engineering environment that is going to democratize the tools, the systems, the languages, and the availability so that we can make more people, digital engineering practitioners within our organization.
John Arnold:
That's awesome. Definitely something to look forward to. What are you most excited about or looking forward to in systems engineering?
Tara Shifflett:
I think what I'm most excited about is what the next generation of systems engineers are going to bring to the table. I am seeing in my role in INCOSE CAB and I'm in the local INCOSE chapter and I serve as outreach for scholarship. And so I get to work with a lot of local colleges. And for those unaware here in Alabama, we have Auburn, we have Alabama, we have University of Alabama, Huntsville, we have Georgia Tech nearby. I reach out to my alma mater, shout out to Mercer. But seeing what they're already doing with the tools that are available. So they're growing up with these tools that a lot of us had to learn on the job and they're doing the most impressive things as interns, as collegiate systems engineers, and they're going to bring that skillset with them into the workforce.
And I'm so excited about it because I'm seeing how digitally native they are and the fact that they don't think twice about, oh, this person's going to do this part of the model. This person's going to do this part of the model. We're going to bring it all together and I'm going to use AI to stitch it and oh, I'm vibe coding this. So there is a inherent efficiency that's coming with them that we're going to see in that next wave of systems engineers. And like we're talking about where SysML is just a vernacular, they're going to be conversant in it. It's just going to be the way that they bring systems engineering to the table.
So I'm excited to see what efficiencies are gained, the way that they are going to approach problem solving. I think there will be initially a little friction as they come into the workforce, but overall that's what I get excited about. And I have this opportunity to work with some junior engineers that we've hired recently and they work in our digital engineering lab here in Huntsville. And the fact that they are absolutely fearless about attacking a problem and that is so impressive to see. I go in there and I write some big thoughts on a whiteboard and I'm like, "Okay, how are we going to make this happen?" And they just get to work.
And that's what's going to move the needle for us going forward is the investment that we make into that next generation of systems engineers, the outreach that we do, and giving them hard problems early to solve. And that's really kind of where I'm excited.
John Arnold:
I'm going to ask you one off the cuff if you don't mind. And that is knowing what you know in the world of systems engineering from handwritten memos, now to seeing digitally native college students doing incredible things because they are so fearless. What's something that you've seen in the last decade or so that truly has blown your mind from an systems engineering perspective? Is there an example that you can think of that just a few years ago you wouldn't have thought that that would have been possible either because of speed or scope of project?
Tara Shifflett:
Yeah. So a good example I have of that is something that we struggled with so much in my commercial aviation days, right? So I was working on a large jetliner that was a clean sheet design, and you don't think about the fact that there are hundreds and hundreds of subsystems. And so the requirements for all of those subsystems went out to each of those individual vendors. And there wasn't a lot of ways that we could ensure that the requirements between the vendors were compatible.
And so something that was off by a factor of 10 between two different vendors caused all sorts of issues in the field. I mean, we had to ground aircraft, people were unhappy because the flying public was being impacted. That is something that in our current environment, using the tools that we have, absolutely would have been caught. And so just knowing the struggle and the battle scars that came out of, we had to write individual documents for each of these individual suppliers and there was really, other than a human going through it and going, okay, this particular piece of equipment is looking for 60 volts and this one's looking for 600 volts, that's a big difference.
And now we would use AI to check that. Or we would have all of that rolled up into the model and the model would do the calculations for us and say, "You have a disparity here." And so we would have caught that way before we ever got into field. And that is such a short period of time that we got from the point of, we've already gone through integration and we've already built and people are flying on these. To I did all of this before I even hit print on my document. So I think that's a huge accelerator and a big difference that's been made over the past 10 years.
John Arnold:
That's very, very cool. Yeah. I had that conversation a lot with people about just the proliferation of technology just in a relatively short time about how much the world has changed just in the past two decades or so. So thanks for sharing that anecdote. Tara, is there anything else you'd like to share with our audience before I let you go today?
Tara Shifflett:
No, not really. I'm super excited to have been here and to talk about what we do because I think that we really are doing cutting edge things, whether it's in this space for aviation. Whether it's in NASA space, we're doing same digital engineering work in the NASA space. We're doing the same digital engineering work for Integrated Air and Missile Defense. We're doing this for Navy. We're doing this for Air Force. And I think that's the important takeaway is KBR isn't doing any of these things in a silo. We collaborate at a grassroots level like no other company that I've been in. And I love that about what we do here at KBR and the people that I get to work with that are leading in this field. So it's very exciting. So I'm humbled to have this opportunity to talk to you and grateful. So thank you.
John Arnold:
It was absolutely my honor to have you today and we'll look forward to hearing what happens with Mission Technology Solutions in the very near future, and with your segment in particular. Thanks so much, Tara.
Tara Shifflett:
Thank you. I appreciate it.
CONCLUSION
John Arnold:
Systems engineering, just one of the many ways KBR is shortening the distance from data to decision. Not a bad way to kick off this last bit of season five, right? We want to thank Tara Shifflett for her time and expertise. I really enjoyed speaking with her and I hope you enjoyed listening.
If you want to learn more about KBR systems engineering capabilities and our Digital Accelerators, head on over to kbr.com and feel free to snoop around. If you have a question for us or an idea for a future episode, please let us know about it by emailing us at inorbit@kbr.com. And before we sign off, as always, we want to thank you, our listeners. There's a lot going on in this world of ours. We appreciate you taking some time out of your day and keeping us in your orbit.
Until next time, be kind to each other and take care.