On The FAA's Slow And Steady SWIM To Open Source
After my talk earlier in the week about open source in health care, I turned to a parallel discussion -- using open source in a federal agency that's long been hidebound by closed-ended legacy systems. Namely, the FAA.</p>
After my talk earlier in the week about open source in health care, I turned to a parallel discussion -- using open source in a federal agency that's long been hidebound by closed-ended legacy systems. Namely, the FAA.
Yesterday, I had a conversation with Ahmad Usmani, program manager for SWIM at the FAA. For those not in the know, SWIM means "System-Wide Information Management" and is a project to link together all the disparate information systems the FAA uses. Each of these systems was custom-built for the FAA with point-to-point interfaces that didn't talk to each other, and are now being reworked as open, interoperating systems built in standard protocols like TCP/IP. The project is still in its first phase or "segment", and it's going to be a long time in coming together, since they can't simply junk one set of systems and replace them with another the way you'd dump your old Acer for a shiny new Dell. This is, after all, the FAA, and everything they're doing is a textbook example of mission-critical, real-time work.
Much of what's in segment 1 is built on top of Progress Software's FUSE open source solutions, and I asked Ahmad if FUSE had been the first use of open source within the FAA. Turned out they had been making good use of open source long before that: "Before we awarded the contract to Progress last year, there were other FAA programs like TFM [Traffic Flow Management], our weather-monitoring programs, and a new terminal program, TDDS [Terminal Data Distribution System]. Those program are and have been using Linux. We had a total of five such programs in SWIM Segment 1, and now that we have FUSE in place, that's a total of seven."
How is software like this tested? I asked. I imagined testing something this far-reaching would require at least as much care and redundancy as the planes themselves. Turns out I wasn't far from wrong.
"We've got a federated approach in SWIM. We do some validation on our own, and then the other seven programs follow their own individual test processes to make sure the software meets all their requirements. What our folks do -- the folks at the SWIM test center -- is take the software, build it themselves from source, and then compare the build report to the build report they get from Progress to make sure it's the same thing and that we're providing the right code to our SIPs. Then they run some regression tests to make sure it all works. And when new functionality gets added, they have to come up with new ways to validate that, too.
"And on top of all that, once the SWIM tech center folks in Atlantic City are done with their validation, the developers for the seven other applications do their own work on top of that. Clearly, there needs to be a lot of cross-checking and valdiation. We are talking about software that's being used to manage the national airspace system, so the more testing the better!" Most of the testing is done either with custom in-house suites or with third-party testing tools like Maven, Ahmad told me.
The advantages of using open source for SWIM ought to have been self-evident, but I asked Ahmad to elaborate on them. "Being able to look at source code is a huge benefit, instead of just getting a black-box executable we can't even look at. We do count on Progress to provide us with formal updates, though, and when we do find issues on our own we can submit a trouble ticket to them and have fixes provided in a timely fashion. But it's always nice to be able to modify something on our own. We count on Progress to do the heavy lifting, but we do keep our own options open."
Another benefit, familiar to most anyone reading this: the developer community as a whole. "I used to program in Jovial, for GPS systems, and there's not that many of them around anymore. By having open source and standard IT stuff as our baseline, we can take advantage of everything out there if we need to."
The timeframe for the whole project demands that this work be done with open code and open standards. Segment 1 is ongoing, and segment 2 of SWIM will extend out to 2016 and overlap with the first. Whole companies can emerge and die off in that time frame, so open source simply makes sense when you're planning for decades into the future, and beyond.
InformationWeek Analytics has published an independent analysis of the next-generation Web applications. Download the report here (registration required).
Follow me and the rest of InformationWeek on Twitter.
About the Author
You May Also Like