Tech Transforms with Mike Beckerle-20251219_090310-Meeting Recording December 19, 2025, 4:03PM 55m 50s Ford, Carolyn 0:05 Welcome to Tech transforms and happy holidays. I'm your host, Carolyn Ford, and today's episode is a special gift not just to me, but to anyone who's ever worked in data security or standards. We're joined today by Mike Beckerlee, chief software architect at Owl Cyber Defense Co-creator of the Daffodil Standard. Mike, when it's DFDL, do you say the acronym out or do I say Daffodil? Beckerle, Mike 0:35 Yeah, it's a little confusing. Thanks Carolyn for hosting this. And welcome to all the people who listen and view this. So DFDL stands for data format description language and a long time ago when that acronym was first coined, someone said yeah, we can use daffodils as our logo and pronounce it daffodil. Then someone started. An Open source software project. And they about an implementation of this and they named it daffodil, spelled out right. And this has done us no favor, of course, because. But the two are tightly related but different things, right? One is a spec, the other is a body of software. Ford, Carolyn 1:23 Yeah. So when I see the acronym, do I see, say DFDL or do I say Daffodil? Beckerle, Mike 1:30 I say DFDL. Ford, Carolyn 1:32 OK. Beckerle, Mike 1:32 That's what I've chosen to do because I have to work on both of them. So I tried to distinguish them. So I daffodil, I usually use to mean the software, the DFDL I use to mean the language. Ford, Carolyn 1:39 Yes. OK. Well then let me get back to our intro. So Mike, you are the Co-creator of the DFDL standard and one of the driving forces behind the daffodil Open source project. Is that right? OK. Beckerle, Mike 2:00 Yes, you got that right. Ford, Carolyn 2:03 Mike's career is like a Rosetta stone for understanding legacy data systems, and he's been quietly solving some of the hardest problems in information sharing and secure interoperability. For decades, he's been a driving force behind DFDL, a champion of standards that actually work in the real world. And now he's heading into retirement, though we're not entirely convinced he'll stop building cool things. And this is our holiday episode and I couldn't think of a better guest. I've been looking forward to this since Mike agreed and just getting to talk to behind the scenes superheroes like Mike is a gift to me personally, and I hope it's a gift to everyone who's worked with or learned from him over the years. As one of Mike's longtime peers, Steven Lawrence put it, "Mike didn't just solve hard problems, he helped the rest of us learn how to solve them too." So whether you know him from Tresys, Owl, the open standards world or the Apache Daffodil community, you'll hear why Mike's legacy is so lasting. And why his approach to collaboration, mentorship and big thinking is exactly what this season is all about. So officially, welcome to Tech transforms, Mike. Beckerle, Mike 3:22 Thank you. Ford, Carolyn 3:24 So let's start at the beginning. What pulled you into the world of data formats and the secure systems in the first place? Beckerle, Mike 3:33 OK. Well, so the there's two parts of that. There's data formats and the secure systems and I got into data formats actually long before I got into cyber security. The first part of my career, once I got out of Graduate School, I spent a little bit on artificial intelligence, but that was long before The current flurry of artificial intelligence. But then I did some work in big data before anyone coined the term big data and started talking about it as a thing. And that's where I got into data formats because any system that wants to deal with data has to be able to import it from somewhere. And there's a million different data formats out there now. Some people are fortunate that you know relational databases have become more and more common, and more and more data is in those kinds of systems and is better structured that way. But there's still tons of data in the world that's in various kinds of file formats now. Use the term earlier about. Legacy data formats and it's true some of them are legacy, but in many cases the word legacy has a pejorative connotation, right? It's like old formats. No one wants to use them. Ford, Carolyn 4:45 Really hard to use. Beckerle, Mike 4:45 I prefer to view them as the most successful data formats ever. Ford, Carolyn 4:52 There you go, lasting. Beckerle, Mike 4:52 Things that were invented in 1970s that are still delivering value today. Are amazingly successful and are worth some effort to continue to use right. So anyway, so I spent from about 1995 to 2007 in big Data and. The importing data into enterprise data systems and processing it fast. It was the problem and data formats was a big part of that problem. Right, much bigger problem than people. It was always underestimated how difficult that problem was. Beckerle, Mike 5:34 You end up writing lots of custom software to deal with people's data, and it was so we ended up writing some sort of description language that would allow us to describe data formats, but it was never really complete enough. We were always having to add stuff to it and it turned into one of the biggest pieces of the whole software package we were building. Beckerle, Mike 5:59 So I started realizing that that not only was my company investing in all that everybody else in the enterprise software was investing in that too, right? So this is a problem because everyone's reinventing the wheel. Now imagine your work for Oracle IBM, one of these big companies. Microsoft, right? And you're acquiring smaller companies in the enterprise software space. Everyone of them comes with their own whole data importer that describes data. You've got IBM has probably 25 of these things in their product portfolio and they're all different, right? So this is just a huge waste of reinvention of wheels inside of the software industry, right? So you know that that became pretty clear to me that we really needed a standard here that we were just. Reinventing the wheel endlessly and, you know an awful lot of enterprise software systems for data visualization or data cleansing, whatever. Therefore the data import side is much harder than the other problem they're trying to solve, right? Just because people have been very creative over the years about all the clever ways of laying out data and passing data around and so forth. Beckerle, Mike 7:21 And the data description problem of getting that into your system is as large as that whole legacy of invention from people for decades. Your business problem you're trying to solve with your software is probably a lot more specific, right? So nobody wants to invest most of their engineering team on this problem that most people don't even recognize. No one buys a data visualization software package and requests new features that are just about the data. The importer, right? Beckerle, Mike 8:00 They just expect that to work, right? So that's how I got into data formats. It turned out to be a huge thorn in our sides and working in enterprise software. Then, interestingly enough, when I left my data integration company, which was a startup that had been acquired and I wanted to go off and do something else, and I got involved. And found this daffodil software project. And this was an open source project already existed. It was run out of the University of Illinois open source thing and I started working on it and the at right about that same time I found out that. Tresys, which is a company that has since become Owl Cyber Defense, was working with the government on this unrelated to data integration and enterprise software systems largely. It was about cyber security and I was like, well, that's interesting. What's going on here? Cybersecurity is kind of the killer app for this technology, right? 'Cause, people are tired of data coming into secure systems and crashing them, right and bad data can crash systems, right? And so that was that's become the killer app. So that's how it happened. Ford, Carolyn 9:26 Listening to you talk, I imagine a meeting of the United Nations like we've got hundreds of people all speaking different languages. We're trying to solve a very important problem, but we can't because we can't understand each other. And you really did help invent the Rosetta Stone to solve these hard problems. Beckerle, Mike 9:52 Well, kind of. It's DFDL was the the language DFDL was actually created. Ford, Carolyn 9:54 OK. Beckerle, Mike 10:01 Kind of the way standards ought to be created, which is we were just looking around at all these different tools that different companies had made and essentially making a Union of their capabilities and deciding what the right name should be. So there's lots of names of properties and things in DFTL that are directly from some Microsoft product or some IBM product or whatever. Beckerle, Mike 10:30 So much of it was a synthesis from existing technology, so that part isn't invention as much as standardization. Ford, Carolyn 10:39 You made it accessible, yeah. Beckerle, Mike 10:41 Yes, accessible and standardized now. Ford, Carolyn 10:43 Yes. Beckerle, Mike 10:45 That has a lot of advantages. I mean once something is standardized and then people can invest some career cycles into learning it because they know they'll get some leverage out of it in their career, right? Ford, Carolyn 10:56 Mm-hmm. Beckerle, Mike 10:59 Whereas if it's oh, I'm just using this IBM tool on this job, but in the future my career it'll be something else. Well, they don't want to worry about how data formats work in just one little corner of this whole space. So by standardizing it, you're making it into something that that gives people more personal and career leverage and it's worth it for they and their companies to invest in them learning it. So that's one of the things that is important about about DFDL is it's not good when there's 46 different implementations of essentially the same idea, right? Ford, Carolyn 11:30 Hmm. Beckerle, Mike 11:43 You know, we depend on that every day in our lives. I mean, you know. You drive a car. The brake is to the left of the gas pedal. Everyone knows that. Ford, Carolyn 11:53 That's right. That's right. Beckerle, Mike 11:53 OK. And if it wasn't the case and there was five different orientations of petals and so forth, it would be a lot harder to drive a car, right? Ford, Carolyn 12:01 Yes, every time I go to the UK, just having the steering wheel on the other side, that's right. Beckerle, Mike 12:01 Yes, wrong side of the road. Yet at least the pedals are the same positions, right? There we go. So over the years, was there a particular moment? Maybe a win or a failure that really shaped your approach. Beckerle, Mike 12:23 Yeah, it was both a win and a failure. So this is about the year 2000. I was working on a big data data integration problem with a company called Axiom and Axiom is one of the big data provider companies you can buy data sets from them that allow you to market products better and so on and. They of course process lots of data. And I was working for a company, we were selling them a framework for scalable computing, big data processing, and they made tremendous use of software from ASAAS institute, This is a statistical and data processing package and we were trying to interface these things together. We had some problems with that. They had these big complicated record with 700 fields and it's something going wrong in the middle. Debugging this problem is hard right? And one of their senior engineers basically said, you know, if this was a standard interface, we'd use a lot more of your software. And that's the reason why you want to do a standard, right? It's not because it's commoditizes something and then you can't make any money with it because it enables people to use it more, right? Beckerle, Mike 13:44 So, so that was an aha moment for me. Was just like, Oh yeah, this would be good for us to be the company that builds a standard thing and opens it up to other people. Rather that you know, so that was and now in in the long run, we did not build a standard thing and give it to them. It's taken a lot longer to get that right, but they remained a customer, so it wasn't a win that day, but in the long run it's to our benefit, so. Ford, Carolyn 14:12 Mm-hmm. Yeah. So as you prepare to retire, what stands out as your proudest contribution or the thing that you are most glad you stuck with? Beckerle, Mike 14:30 There's two sort of two answers to this. First is, just the technical achievement of building the staff at all software with the team of people. Many at Owl. Some people also from outside all the open source team getting it to be accepted as a top level project at the Apache Software Foundation. That was a really important achievement because at that point things can snowball. People can find it. So that's been that's been pretty important and I I think probably this is the major achievement. The the other though, I would say I'm really proud of the teaching that I've been able to do and the engineering leadership. It's really satisfying when you see people latch onto and start practicing ideas that you've through your career are hard won. Eventually you had to go through lots of things before you landed on a set of practices that really work. And as you promote them, you see them being uptaken by the team. It's really satisfying to see. And of course, I mean all teachers in the world go through this experience of how satisfying teaching is. And engineering, especially as you move to the later parts of your career, is a lot about teaching. Ford, Carolyn 15:52 I quoted Stephen Lawrence, one of your peers. That's one of the things that he called out is your mentorship. And I talked to a few of your peers and they all mentioned that. I will say that one of them said, I'm going to paraphrase here, "an incredible mentor and a lot of us have become really good at the craft because of him, but there will only ever be one Mike Beckerle. Beckerle, Mike 16:22 Now there will only ever be one of me. But there are plenty of talented people who they just need the right direction and encouragement. And I'm always about encouraging people to, you know, especially engineers need to trust their intuition and trust themselves and do things the way they think they should be done. And It's always satisfying when engineer pings you on teams or something. They want your opinion. They're not asking about something trivial. They're asking about something deep, right? That's what you want, right? Ford, Carolyn 16:57 Mm-hmm. Beckerle, Mike 16:59 The trivial stuff, they've got that down now, right? The things they ask you about are the things where it's not clear what to do, right. Ford, Carolyn 17:02 Right. Beckerle, Mike 17:07 So that's that's always that's satisfying. Ford, Carolyn 17:08 Mm-hmm. Well, and I know that you're, you know, your primary mentorship is towards engineers. But I remember the first time I reached out to you. You're incredibly generous with your time. You were incredibly patient with me, who had never heard of Daffodil or DFDL, and you broke it down for me in a way that I I got it. I was like, yeah, this is amazing and. So I mean, you mentored me, this woman in marketing. Beckerle, Mike 17:43 Well, I've had to deal with a lot of people in marketing throughout my career. I mean, I've been, I've been in front of customers every day of the week or many times. I have been the traveling CTO that everyone in sales dragged around in front of the customers and did their job in PowerPoint, you know. Ford, Carolyn 18:03 Yes. Beckerle, Mike 18:04 I lived that life for quite a while and communication is probably the most important thing that's been in my career. It's really helpful to be able to talk to people. Oftentimes people have requirements, but they're not that clear on them. They need a technical sounding board to really talk through them to understand what's really a requirement or to refine things. And. And that's the flip side of the marketing problem. How do you take these requirements or that system? Turn it into something people recognize, right? Ford, Carolyn 18:44 That's right. Beckerle, Mike 18:44 So. So that's been something I've done throughout my career and I'm proud of it. Yeah, I'm very happy of that. I've been able to do that for for this organization, and others. Ford, Carolyn 18:59 Yeah. Well, I personally appreciated it very much. You did not make me feel stupid. You were incredibly patient and like I said at the end of our conversation, I got it. Beckerle, Mike 19:12 Yeah, well, I'm glad. Ford, Carolyn 19:13 So. Beckerle, Mike 19:13 I'm glad you did, and I probably would have been very frustrated by the end of it and would have been nagging you afterwards if you hadn't. Ford, Carolyn 19:23 Well, I feel like you've explained really well what DFDL and daffodil is. Is there anything else that you want to add or what the impacts Re that you've seen come from this project? Beckerle, Mike 19:39 Well, I think, the impact of this project it's. I mean cybersecurity I mentioned is kind of the killer app for this, right? People don't understand that, but, but that is going to really have some impact because and I do it by analogy, you know, 15 years ago using the Internet everything was unencrypted because, oh, encrypting everything would be too slow. Right now, everything's encrypted on the Internet. It's very hard to even find a website that does not have a secure connection immediately, right? Ford, Carolyn 20:17 Mm-hmm. Beckerle, Mike 20:18 And the next change of that kind is going to be this cyber security based on a data descriptions because it went before you allow data to connect we're gonna rip it apart based on its specification, put it back together, validate it, put it back together, then we'll let it throw. Right. And people say. Ford, Carolyn 20:40 It sounds like CDR Is that what you're talking about? Beckerle, Mike 20:43 CDR I'm not sure. Ford, Carolyn 20:46 I think I might be getting the acronym wrong. GlassWall does it. Beckerle, Mike 20:51 Well, it's glass walls. Another vendor in the cybersecurity space, yes, but the this is what what Owl and other vendors are all doing using DFDL. The idea is you you don't allow data in unless you've proven what it is. You. It's not like what is it labeled? What is it tending to be? Ford, Carolyn 21:10 That's right. It's true, zero trust. Beckerle, Mike 21:11 You're gonna take, it's true Zero trust. You're gonna rip this data down to its atomic pieces, strings and numbers, and so on, put it back together according to specification. By construction, it definitely is one of those things now, and if it doesn't survive that, you don't let it through, right? So that that is the next level of security above the encryption layer, right? Is the data has to be what it says it is, and otherwise it's not allowed through and that that's gonna actually make a huge difference because there's this thing called a Denial of service attack and it doesn't matter if you're a website or a military system. If data is coming in, and flawed data might just depending on how it's loaded, crash that software, that's a denial of service attack, a successful one because you got to restart that system or reboot or something. Ford, Carolyn 22:06 Right, right. Beckerle, Mike 22:10 It's offline for awhile, right? Ford, Carolyn 22:12 Mm-hmm. Beckerle, Mike 22:13 And so it's not a computer virus. It's not malware, it's just bad data. Right. Boom. You can actually have significant impact. Ford, Carolyn 22:21 That brings it down, right? Right. Beckerle, Mike 22:22 Yeah. So that's gonna have some real impact because systems are just going to be more robust as a result. Ford, Carolyn 22:31 Yeah, OK. I did my fact checking. It is CDR its content disarm and reconstruction and that's what you just exactly described, right? Beckerle, Mike 22:34 Mm. Exactly. Yeah, that I, I didn't coin that acronym, but it's what I refer to been referring to as rip and rebuild. Ford, Carolyn 22:42 So. There you go. So you're saying that's your prediction that that's gonna come for every website, every interaction online is going to include rip it. Beckerle, Mike 22:47 Right. Yeah, yeah. Ford, Carolyn 22:58 What did you say? Rip and rebuild? Beckerle, Mike 22:59 Rip and rebuild. Yes, it's. Ford, Carolyn 23:00 Rip and rebuild R&R, I like it. Beckerle, Mike 23:03 Yeah. So the idea is that that basically, you have to trust the data. It works on the outbound side too, when people are sending data out. You want to make sure the data you're sending out is in what we call canonical form, which is to say, it meets all the requirements that anybody could be expecting of that data. But furthermore, you know there's a lot of data formats. They've got little sections in them that are unused. Or they have parts where they you know it can be, we can have carriage return, line feeds or regular line feeds. Any kind of those things is allowed. Well, Canonical forms standardizes all that. And what's really important is that blocks covert channels. So that's another important aspect of cyber security is that if data can be exfiltrated from a secure environment by using all these little bits and parts of the data. Then they've really got an exploit they can steal from you, right? Ford, Carolyn 24:08 Mm-hmm. Beckerle, Mike 24:08 And using DFDL and this rip and rebuild process you get canonical data. All those little things they're trying to exploit are gone, so they can't exfiltrate data that way. Ford, Carolyn 24:19 Yeah. Beckerle, Mike 24:21 And so that's, you know, it's important that way as well. Ford, Carolyn 24:24 Oh, I just had ah-ha moment. I think so. When you rip and rebuild, you rebuild in DFDL. Beckerle, Mike 24:33 Yeah, yeah, that's what we. That's what DFDL is for. We write a description of the data format. Ford, Carolyn 24:36 OK. Great. Beckerle, Mike 24:39 We use it to break the data down into a data structure. Where all the little strings and numbers and everything are all separated out. Then we use that schema again to put it back together into its original form. Ford, Carolyn 24:48 Mm-hmm. Mm-hmm. Beckerle, Mike 24:53 But it's not exactly bit for bit identical. It's in canonical form, which is to say like, let's say you had some data you could separate the fields with either a comma or a semi colon. Well, pick one of those. Ford, Carolyn 25:05 Mm-hmm. Beckerle, Mike 25:06 One of them is going to be what you're going to get out. It's going to be all commas or it's going to be all semicolons, but it's only going to be one, and that prevents you from transmitting information based on comma versus semi colon. Ford, Carolyn 25:20 Right, right. Beckerle, Mike 25:21 So that's the that's the killer app for DFDL is parse the data, break it down, put it back. It was like, oh, well, you're gonna parse the data, but then just put it back together. What do you do? This is the value it's providing in cybersecurity is that the data is guaranteed to be what it says it is and bad data generally just doesn't survive the process. Ford, Carolyn 25:55 Right. Talk to me about doing this in open source. I it feels like it's counterintuitive to building a business, first of all to just give it away for free. It also feels like it could be incredibly insecure because you've got, you know, dirty little paws touching it so. Beckerle, Mike 26:18 Yeah. Ford, Carolyn 26:18 Help me understand. Beckerle, Mike 26:20 Yeah. So that's actually been a really rewarding experience for me because you know I've been at big companies and even companies as big as IBM had a terrible time trying to build reusable software components and have supported business units that does that. That makes them on behalf of all the other products that need them. It's because they very business units are very reluctant to ascribe some of their revenue to a different business unit, right for all the business reasons, right. And so, so even organizations, I mean, I haven't worked for them for a long time. But when I worked there they couldn't make that work right? They had these blue dollars thing where it's not real money, but you're paying, you know. It it boils down to they, at that time anyway, it wasn't really successful. But what has been successful is open source software. And it's successful for two reasons. One is because you don't have to pay for it and therefore people can use it right? And so there's no resistance to using it. In some sense, it just has to be of high enough quality. So then that brings them to your second point about people's paws being all over it, right? So that cuts both ways, right? People's eyes are also on it. Their paws are kind of restricted because open source projects use a software development lifecycle with enforced code review. You know, there's a trusted team of people who only bring in new contributors. Ford, Carolyn 28:04 Hmm. Beckerle, Mike 28:09 Gradually. Based on their proof of, they can actually you know, they make some contributions. Which other people integrate into the base for a while and eventually people become trusted to contribute high quality code, but everything goes through a life cycle where two people who are authorized. There's a lot software development lifecycle where two people trusted contributors to project half the review every change, right? Ford, Carolyn 28:56 All right. Beckerle, Mike 28:56 So there's absolutely no way someone can inject, you know backdoors or other things or just crappy code. Most open source projects have like daffodil, for example, a policy that, oh, you can't check in stuff if it doesn't also include tests that show it works right? And that show both sides of positive and negative examples and so on. Ford, Carolyn 29:22 Hmm. Beckerle, Mike 29:27 So it allows you and since it's open source, there's no the pressure to just put it in and hopefully it works. That's gone. Ford, Carolyn 29:40 Mm-hmm. Beckerle, Mike 29:40 You, basically have to say no, no, You're gonna prove it works. For us, because we know we have to keep it working too, so the tests are every bit as important as the code, right? Ford, Carolyn 29:45 Mm-hmm. Beckerle, Mike 29:51 And so the test driven development is one of the things that throughout my career I've learned is really essential, right. Ford, Carolyn 29:51 Everybody's got some skin in the game to make sure, yeah. Mm-hmm. Beckerle, Mike 30:02 You have to make people think about the problem from the testing and build right into every change they make. Think about oh, how am I going to test that this actually works, and sometimes that even affects the design of the thing 'cause you have to design it not only to work, but so it can be tested and you can show it works right. Ford, Carolyn 30:17 Mm-hmm. Beckerle, Mike 30:28 And that's so open source really encourages all of that and enables all of that. I've been very impressed by the sort of state-of-the-art Life cycle and software development methodologies that just come out of open source development particularly. Ford, Carolyn 30:51 Mm-hmm. Beckerle, Mike 30:52 I've only worked with the Apache Software Foundation, but they have a methodology that is referred to mystically as the Apache Web. But but this is allpart of it, right? And it's a meritocracy. People are admitted based on their merit. There's all this built in code review. Ford, Carolyn 31:13 Oh wow, it's like a club. Beckerle, Mike 31:16 It's a club. Yeah, it's not. I wouldn't. it's not a cult. It's a club. But it's it's become a very big club. I mean is this software is now in use? Ford, Carolyn 31:29 Yeah. Beckerle, Mike 31:31 There's hundreds and hundreds of these open source projects under that umbrella, and they're in use. I mean, you hardly use anything in your life anymore that has technology in it that is not using open source software. I doubt you could find something that doesn't have any open source software in it. Ford, Carolyn 31:55 Well, and it makes me think of what you said earlier. This standardization is incredibly valuable and necessary for us to continue to progress. Beckerle, Mike 32:07 Yeah, without it, you reinvent the wheel too often and slows you down. Ford, Carolyn 32:07 I think we would kind of just be spinning. We would just churn, right? Beckerle, Mike 32:14 Yeah. Yeah, exactly. Ford, Carolyn 32:17 You've worked in some highly constrained environments defense systems. Beckerle, Mike 32:23 Yep. Ford, Carolyn 32:23 Legacy data which we will rename seasoned data. Beckerle, Mike 32:28 Yeah, high value data or something, yeah. Ford, Carolyn 32:28 Because high value data that's really stood the test of time. Secure domains. What's your approach when you're faced with a problem? That most people would just say, yeah, that's impossible. Beckerle, Mike 32:44 I have made that observation in some cases in my life, but I do believe few problems are too hard. If you really understand them and you drill into what are the requirements? I mean, paint it very broadly, you know, artificial intelligence is too hard. Ford, Carolyn 32:58 Hmm. Beckerle, Mike 33:03 People have built systems. They're clearly intelligent, right? So they figured out what, how to refine that box and do things that are really useful. Right, and most problems are like that. If you have to bring an engineering mindset to how do we break this down to make it not too hard? So you know, I like to bring, you know from my educational background, I did a lot of work on languages and compilers and I bring that toolkit with me to almost every problem I solve. I and I like to use that to solve problems that. Most people would try to solve just by coding and having more programmers work on the problem. So that's that's kind of been a good example is there's we deal with a lot of these very large high value data formats and they have big specifications. Ford, Carolyn 34:00 Mm-hmm. Beckerle, Mike 34:02 I mean one of them. The spec is 13,000 pages. OK, I kid you not. Ford, Carolyn 34:07 Oh wow. Beckerle, Mike 34:07 It hasn't been printed out in decades because no one could ever print it. Right now I had heard estimates from one of the aerospace contractors that, you know, oh, implementing that thing is, you know, twenty $30 million, right? Ford, Carolyn 34:11 Right. Beckerle, Mike 34:22 So. So what did we do? Well, we wrote a parser for the format specification document using DFDL to parse the that document, treating it like a very loosely structured piece of data. Then we converted the output of that into a DFTL schema that implements that format. So we are compiling that spec into the thing that we need, right? Ford, Carolyn 34:48 Mm-hmm. Beckerle, Mike 34:50 And that. That approach, as opposed to a bunch of people, are reading the spec and just trying to write code for it, you know, has tremendous leverage. Ford, Carolyn 35:00 Right. Beckerle, Mike 35:01 Huge numbers of quality assurance issues. Just because programmers will make mistakes in sort of random places, right? Ford, Carolyn 35:09 Mm-hmm. Beckerle, Mike 35:10 Go away. Because what comes out of this compiler approach is much more uniform. You know, a whole aspect of how the thing works. Is either gonna work everywhere or fail everywhere, right? So and then you fix it in the compiler in one place, and now it works everywhere, right? And so it changes it. It changes the approach to that and of course we spent, you know, a fraction of $1,000,000 on that. Project so you know it's a. Ford, Carolyn 35:36 Yeah. Beckerle, Mike 35:38 It's a it's a. It's a high leverage approach and engineers who glom onto this and start using it immediately catch on to the idea. They're like, oh, yeah, of course. This is the way you should do this, right? Ford, Carolyn 35:49 Mm-hmm. Beckerle, Mike 35:49 But and so that's one of the things that of course the teams I've been working with all take away is that, oh, we should definitely be thinking about compile something, don't write it. Ford, Carolyn 36:03 Right. So you took a different perspective like to use the horrible adage. Ford, Carolyn 36:09 There's more than one way to skin a cat. Beckerle, Mike 36:11 Yeah, that's right. There's more than one way and and sometimes you can come up with a way. That has a huge benefit over the ordinary way. Ford, Carolyn 36:26 Well, you've mentioned many of the cultures, organizational cultures that you've been part of. IBM Tresys, Owl. What do you think makes a truly good team? That can really cause technical transformation or affect technical transformation. Beckerle, Mike 36:48 That's a interesting point and one of the things is having a, It's been referred to as a good geek culture. Engineers get to be pretty geeky, and but the key is not just to, you know, Be Socially awkward In the way many of us, DP types are now, the idea is that the engineering drives a lot of the decision making right engineers in some sense have to learn to listen to their own counsel as much as they listen to outside influences. Asking them to do. Ford, Carolyn 37:27 Mm-hmm. Hmm. Beckerle, Mike 37:37 Stuff, right? Ford, Carolyn 37:38 Mm-hmm. Beckerle, Mike 37:38 Because oftentimes what you have to do the code half of that is in the code. You know it has to have, right? Ford, Carolyn 37:46 Mm-hmm. Beckerle, Mike 37:46 And you just have to say no, this actually has to get done before we can do that other thing. You actually have to. You have to let the engineering drive the agenda, not exclusively. Businesses are in business to do something right, but once you start building a piece of software in order to achieve something, it starts to have its own structure and shape. Ford, Carolyn 38:03 Right. Beckerle, Mike 38:14 And you, you actually have to pay attention to that. So that it otherwise it you end up. You end up with a group that doesn't really. You're not really working on something that has any cohesiveness to it, and that's really important because once you've built something, it's got such cohesive to it. Ford, Carolyn 38:31 Mm-hmm. Mm-hmm. Beckerle, Mike 38:37 Now you can get some business leverage from it, right? Because it's not a big monster that no one really understands. It's something that you can actually bring to bear on lots of problems. Ford, Carolyn 38:51 And it makes me think of what you said earlier about the importance of being a good communicator. Beckerle, Mike 38:57 Yeah. Ford, Carolyn 38:58 So you just mentioned, you know engineers are, it's really important to have the geeky aspect, I agree. And you have to be able to communicate the value of what you're doing beyond. The Beyond the geek group that understands it into you know intuitively. And it's, you know what they live and breathe. You have to be able to communicate that value and it's something that you do very well. Beckerle, Mike 39:22 Mm-hmm. Yeah, that's been my role. But there's plenty of engineers. Ford, Carolyn 39:29 Yeah. Beckerle, Mike 39:33 Who are very, very excellent programmers, not an excellent engineers and not as good at that stuff. And you do have to sort of nudge them to do more of it because they might be fine at it. They just don't think they are right. Ford, Carolyn 39:48 Right. Beckerle, Mike 39:49 And the other Thought is that you know you need, you need some diverse people in in engineering. And then people gravitate to the roles that their talents, you know, select for them. And that's all OK too, right? Not everybody has to be the spokesman for the group, right? Ford, Carolyn 40:07 That's right. Beckerle, Mike 40:07 Or the customer interface for the group, not everyone so. Ford, Carolyn 40:10 That's right. That's a very good point. As you step away from the day-to-day, what advice do you want to give to the next generation of architects and system engineers? Beckerle, Mike 40:23 this is something I have been giving some thought to and the lesson I've learned across my career is don't be too clever. numerous times in my career, and recently even I was advising another engineer at Owl about this. Ford, Carolyn 40:42 Mm-hmm. Beckerle, Mike 40:52 As the business comes to you with a customer problem and so you think about it for a while and you go, you know we could just do this and this and this and this and you come up with some very clever way to. Ford, Carolyn 40:56 Mm-hmm. Beckerle, Mike 41:05 To enable some aspect of the software system, you've got to address this new endeavor that customer has and the challenge is you figured out how you can make it work. You have not taken into account that that is gonna live forever once you put it in the code base, it has to be documented. Ford, Carolyn 41:24 Hmm. Beckerle, Mike 41:25 Other people have to understand it. Can you sell it again or you're doing all of that for one deal, right? Because one of the challenges with engineering is you don't get to scale your engineering workforce with your customer base. You get to grow it, but you're supposed to get some leverage from it. Ford, Carolyn 41:40 Mm-hmm. Beckerle, Mike 41:43 You're not building custom one ups for everyone, right? Ford, Carolyn 41:44 Right, right. Beckerle, Mike 41:47 I've designed some very clever things in my time that in hindsight I was like, we really shouldn't have done that. We should have just focused on what was more important for the product that we were selling in, volume, not helping to close that one more deal or you know, whatever. And it may not even work to close that deal or, and you might not even know how important it is, right? Ford, Carolyn 42:13 Right. Beckerle, Mike 42:17 Like if you if you had just told the salespeople and executives who came to you with that problem, you said that's pretty hard to do. I'm gonna need a week to go think about it. They may never have come back to you, but instead you spent all this time and effort coming up with this very clever thing and maybe even prototyping it and all this stuff. That is just gonna create a headache. Or your whole organization down the road. So that's why I say, don't be too clever. Ford, Carolyn 42:41 Yes, to maintain it, yeah. Beckerle, Mike 42:48 Really, the notion is because being too clever bypasses too much of what you really have to think about as an engineer, which is this gotta be maintainable. How are we gonna test this, you know? Is there, you know, and those things, a lot of them have the fact that you're building something you're gonna sell multiple times. Ford, Carolyn 43:08 Mm-hmm. Beckerle, Mike 43:08 Is it drives that right? If you're just building something for one use, well, you could test it on site or something you know you could. Ford, Carolyn 43:12 Mm-hmm. Right, right. Beckerle, Mike 43:19 You could. There's shortcuts like that, but you know you're gonna end up with your engineering team on site to do this one little thing instead of getting leverage from the engineering. Ford, Carolyn 43:31 So don't be too clever. It makes me think of Doctor Seuss analogies specifically. My niece loves the newest Grinch. It's been out for a few years, but it's animated Benedict Cumberbatch is the Grinch and he builds all these inventions and they're just like these crazy, really clever. Beckerle, Mike 43:51 Mm-hmm. Ford, Carolyn 43:56 Inventions really complex to make a piece of toast. And you, you know, and they break really easily. And so as you're. Beckerle, Mike 44:03 Am I dating myself? These are called Rube Goldberg. Ford, Carolyn 44:10 Yes, yes, exactly. Beckerle, Mike 44:11 Contraptions, right? And I think they I'm not even sure where that comes from. Is from cartoons in The New Yorker or something. Ford, Carolyn 44:13 Yes.I mean, I've seen some of his, like mazes in action, and they're fascinating to watch. Beckerle, Mike 44:28 Yeah. Ford, Carolyn 44:30 But they're kind of a piece of art to look at rather than solving a problem. Like just put the toast in the toaster. That that's all you need to do. Beckerle, Mike 44:34 Yeah, yeah. Right. Yeah, yeah. And when engineers are being clever, they're not, not necessarily creating new Goldberg contraptions, but, but the analogy is apt because they're building something that is not gonna be maintainable, at least not easily. And that is not gonna be easy to explain to anyone because it's got so. Ford, Carolyn 44:46 Mm-hmm. Right. Beckerle, Mike 45:01 Many. Aspects to it. Right. And and so yeah, it's, it's clever. It's inventive. You may get good ideas out of it, but it's not really engineering. Ford, Carolyn 45:04 Mm-hmm. Beckerle, Mike 45:13 Right. I mean engineering has we have to you know if you're trying to? Ford, Carolyn 45:13 Right. Beckerle, Mike 45:19 You have to do something that is gonna hold up to scrutiny when you're engineering, right? So. Ford, Carolyn 45:23 Right, right. What do you hope continues to grow from your work on DFDL and daffodil? Beckerle, Mike 45:33 Well, the, the cybersecurity. Enhancement that I talked about earlier that people doing the rip and rebuild on all the data and so forth. You know that's the legacy of this, that I think should I'm hoping will you know things always take longer than you expect, but I'm hoping that's one of the least long legacies from this stuff because it's really you know that's been what. Ford, Carolyn 45:58 Mm-hmm. Beckerle, Mike 46:03 Owl and other companies in the US government have been investing in. By trying to get this DFDL technology out there. So that's I think that's the that's the thing. I'm really hoping to watch as I as I go through the next cycle of my life here. I will be a little bit my fingers in this stuff a little bit, still no question, but. Ford, Carolyn 46:27 I know I'm thinking that I'm like, we both know that you're not done. Is that the? Is that the problem? Beckerle, Mike 46:33 Yeah. Ford, Carolyn 46:35 If you could solve one last problem is that it? Would you do the rip and rebuild? Beckerle, Mike 46:40 You know the Rep and rebuild is happening. Ford, Carolyn 46:43 Yeah. Beckerle, Mike 46:43 I don't need to do that. There is a sort of a barrier to the uptake of the DFDL on that field stuff and It's because it's highly dependent on XML and XML schema technology and that technology is modern engineers nowadays. They have a love hate relationship with that stuff. A lot of them just try and avoid it like the plague is like one more thing. Ford, Carolyn 47:07 Hmm. Beckerle, Mike 47:11 Baroque thing I don't have to learn. Ford, Carolyn 47:13 Mm-hmm. Beckerle, Mike 47:14 And other people are using it effectively and like it but. If the, there's certainly plenty of people I've run into in the Apache Software Foundation at their conferences and so forth, and I explained to them what the DFDL is about and they're all about it. They think this is great. I wanna use this until they realize it's using XML and XML schema technology and then they're like, oh, I don't wanna have to, you know, I mean, literally you could see it in their faces, they're just not that interested in that stuff. They want something more familiar, easy to use than that doesn't have the learning curve. All that stuff has. And so, so we have this on our road map for the Daffodil project, which is to invent a different, more. Familiar kind of syntax for describing these schemas and not making people have to use XML Schema and Silverton do this. I think that's important to the success of this technology. You know 'cause, there's a lot of, there's a lot of people who don't Want what DFDL does? They don't want to do it in terms of the whole XML technology stack. Ford, Carolyn 48:28 Right. They want it to be easier. Beckerle, Mike 48:29 And yeah, and they want it, well, easier and and free of. There's a lot of stuff that comes along with using XML. Ford, Carolyn 48:37 Mm-hmm. Beckerle, Mike 48:38 It's verbose. It has some overhead problems. You have to buy into that the the syntax is pretty verbose, so it's it takes you a while to even get to learn to read it, because it's kind of verbose. And if we can fix that, then I think lots more people would latch onto this. So you know, there's a group of engineers who are kind of on the fence about it, and I'd like to. Ford, Carolyn 48:57 OK. Beckerle, Mike 49:03 I'd like them to be able to adopt it enthusiastically. Ford, Carolyn 49:06 All right. Well, We'll be watching for that. So now we're to our tech talk question part of the show, this is rapid fun. You know, just rapid fire, fun questions. Beckerle, Mike 49:09 Yeah. OK. Ford, Carolyn 49:18 So if DFDL were a tool in a sci-fi toolkit, what would it be used for? Beckerle, Mike 49:25 Sci-fi toolkit. Ford, Carolyn 49:28 Mm-hmm. Beckerle, Mike 49:29 So in my mind is an episode of Like a sci-fi show like spoof, like Doctor Who and in the backroom there would be like this. These two ancient computers with this cable that they have to connect them with and guys on the trying to type the DFDL schema. Ford, Carolyn 49:34 Yes. Ah. Beckerle, Mike 49:47 For the data interchange you know, in order to keep the spaceship from crashing or something, you know it would be and it would. It would be, you know, some. These ancient computers that they have to keep working because no one knows how they work anymore or something, you know. Ford, Carolyn 49:58 Right, right. Or could it be Doctor Who's Sonic? Is that what DFDL could be like? His Sonic can do anything. It can translate anything. It can fix anything. All right. Beckerle, Mike 50:17 There is a saying in the engineering world, which is if you have a big enough hammer, everything looks like a nail. Ford, Carolyn 50:24 There you go. Beckerle, Mike 50:24 And so the DFDL is like that. It's like, oh, well, you can describe that kind of data well, then you can do all this other stuff too, you know, so it can do a lot, you know. Ford, Carolyn 50:33 All right. OK. That I feel like I feel really happy about saying that it would be Doctor Who Sonic screwdriver because it can do anything. Yeah. Beckerle, Mike 50:43 Almost. Ford, Carolyn 50:44 All right. What's 1 ancient technology you admire for its cleverness or durability? Beckerle, Mike 50:45 You know. OK, well I. The the one of the data formats we deal with is A is a thing called Link 16 which is this thing invented in 1970s for communicating between aircraft. Ford, Carolyn 51:05 Mm-hmm. Beckerle, Mike 51:06 And it's intended to be unblockable, unstoppable and the radio layer that's in this. I mean, it's incredibly clever. I mean they jump frequencies, which is this thing that was invented by by this actress, Hedy Lamarr. She was actually an inventor, so they done only jump frequencies. Ford, Carolyn 51:24 Oh. Beckerle, Mike 51:25 They have time slots and then they jump around the time slots. So any given communication. Is in this this hodgepodge of different places in in the spectrum and the time. That that data is moving. I was just very impressed by it. It was like that's one of the coolest things I've seen in a long time. This is just there's no way you can block, jam or intercept this stuff. I mean, it's just unfathomable to me. Ford, Carolyn 51:50 Wow, yeah. Beckerle, Mike 51:52 So I thought that was really, really cool. That's certainly one of the most clever things. When I read that spec, I really liked it. Ford, Carolyn 52:04 Alright, last one. What's a myth about data standards that you wish would disappear forever? Beckerle, Mike 52:11 This about data standards. People think data obeys its specifications. The most part we have never, I would say in my entire career I have never seen a project where the data actually matched the specification perfectly. Ford, Carolyn 52:31 Child. Beckerle, Mike 52:32 Well, well, the specifications are documents written by people. They have mistakes in them, right? Ford, Carolyn 52:38 Yeah. Beckerle, Mike 52:40 And so the the de facto data, the data that's on the wires going between the computers. It's right. Seldom matches the spec completely, so that means and so you if you have just the specification and you build a schema for parsing that data format, it's not gonna work. There will be something you'll have to debug in right and people somehow think that if you just have the spec, you've got what you need, but you actually have to have de facto test data because there's always a discrepancy, right? Ford, Carolyn 53:01 Mm-hmm. Yeah. Right. Beckerle, Mike 53:18 And that's a certainly a myth. People think that data. Is in better, coherent? Is better matched up to the? They think that, you know, it's only it's only data that's. Really, really old and specifications that have gone through many revisions that you have any chance of them actually lining up perfectly. Ford, Carolyn 53:41 Mm-hmm. Yeah, it is. It's like being a parent. You you read these books, your child does not follow one of those rules, right? Not one. Beckerle, Mike 53:52 Oh yeah, not even one, right? Well, yeah, no, in data, it's not as bad as that. Most of the time the spec is, you know, probably 95% correct, but it means that when you get. Ford, Carolyn 54:03 Hmm. Beckerle, Mike 54:07 The the My friends in the in the military say you know no plan survives first contact with the enemy and this is the data version of that. Ford, Carolyn 54:13 That's right. That's right. Beckerle, Mike 54:16 It's no data schema survives first contact with real data. Right. You have to plan to debug it with real data. Ford, Carolyn 54:26 I love it. All right, Mike, where can listeners go to learn more about your work or the Daffodil project? Beckerle, Mike 54:33 You know the the best starting point. If you is, you can Of course you can go to Owl's website, but I always tell people go to Wikipedia and you should donate $10 a year for Wikipedia because it's the best thing ever. Ford, Carolyn 54:45 OK. Beckerle, Mike 54:49 But go to Wikipedia and type DFDL that. There are some other things in the world named DFTL so. But if you type DFTL data format at Wikipedia, that will take you. To an article about the FDL with links to all the different stuff. Our implementation, Apache daffodil. The spec. There's other companies that have implementations. IBM has three different implementations, right? Ford, Carolyn 55:14 Mm-hmm. Beckerle, Mike 55:14 And there's links to all of that stuff. That's the easiest place to start. Ford, Carolyn 55:19 OK. Well, thank you so much for doing this with me today. Beckerle, Mike 55:23 You're welcome, Carolyn. Thank you so much. Ford, Carolyn 55:25 And thank you listeners for joining. Please share this episode, smash that like button. Leave us a review so we can continue to share this kind of content. Tech transforms is produced by show and Tell. Happy holidays. Until next time, stay curious and keep imagining the future.