In Free Flight, the seminal book on the forthcoming reinvention of air travel, James Fallows tells a story about Bruce Holmes, who was then the manager of NASA’s general aviation program office. For years Holmes clocked his door-to-door travel times for commercial flights, and he found that for trips shorter than 500 miles, flying was no faster than driving. The hub-and-spoke air travel system is the root of the problem, and there’s no incremental fix. The solution is to augment it with a radically new system that works more like a peer-to-peer network.
Today Bruce Holmes works for DayJet, one of the companies at the forefront of a movement to invent and deliver that radically new system. Ed Iacobucci is DayJet’s co-founder, president, and CEO, and I’m delighted to have him join me for this week’s episode of Interviews with Innovators.
I first met Ed way back in 1991 when he came to BYTE to show us the first version of Citrix, which was the product he left IBM and founded his first company to create. As we discuss in this interview, the trip he made then — from Boca Raton, Florida to Peterborough, New Hampshire — was a typically grueling experience, and it would be no different today. A long car trip to a hub airport, a multi-hop flight, another long car trip from hub airport to destination.
In a few weeks, DayJet will begin offering a different kind of experience for travel within a trial network of small Florida airports. If all goes well, the network will then expand to the entire Southeast, and eventually — I sincerely hope — will reactivate small airports around the country, including the one that’s two miles from my home.
In this interview, Ed describes how he worked through a false start, realized that on-demand air travel would require a platform, decided that Eclipse Aviation’s line of precision-engineered, mass-produceable, and affordable jets would be the platform’s equivalent to the personal computer, and then conceived and created its network operating system and software service infrastructure.
There were two major research and development challenges. First, how do you find an optimal routing solution when there’s no fixed schedule and when every new reservation ripples through the entire network?
It didn’t take very long to figure out that if you replace one 25-million-dollar plane with 25 one-million-dollar planes, it fixes a lot of problems. And if you couple that with doing it by the seat instead of by the plane, that lets you interleave packets, or payloads, and increases the efficiency even more. So it became very clear that we needed to build a large, self-optimizing network that would take a lot of other factors into consideration, like the physics of the airplane, the temperature, the loads. The beauty of aviation is that it’s like physics meets business, right? How much you can carry depends on temperatures, altitudes, runway lengths — and safety is all expressed in terms of parameters that the optimizer has to take into account as it starts shuffling around customers. It’s not a straight optimization, it has to be done in real time, and it has an incredible number of constraints.
So I hired mathematicians, really smart guys, and we brought them on and gave them the challenge of their lifetime — really, for the rest of their lives — because you’ll never find a solution to the problem, it’s what mathemeticians call NP-hard, which means you can take every computer made between now and the end of our lives, and run them until the end of our solar system, and you’ll never find the optimal solution. You have to move from traditional hard optimization to heuristics aided by optimization techniques. So then we brought in an operations research group from Georgia Tech, real heavy hitters who did optimization for large air carriers. But optimizing assets around a fixed schedule is a vastly different problem from trying to determine the most optimal solution in real time for something that doesn’t have a fixed schedule and morphs with every new request that comes in. Their response was, “Nobody’s ever done this.”
If it were just chartering airplanes, that’s not very exciting. But now we’ve got new science, new math, it’s a lot of green fields in areas where we could get collaboration with major universities where topnotch people want to work with us, and assign Ph.D. students to work with us.
The goal was to be able to respond yes or no, within ten seconds, to a customer’s request for a flight between two participating airports, and that goal has been achieved. Given that capability, DayJet has been able to create a new business model that prices tickets according to the value of each customer’s time. If you value your time highly, you can request a narrow time window for your flight, and pay more for your ticket. If you’re willing to accept a wider window — say, you’re OK with leaving anywhere between 10AM and 3PM — you’ll pay a lot less. Ed calls this “time arbitrage” and it’s at the heart of what’s really revolutionary about this system from the customer’s point of view.
There was another big problem. As you build out the network of regional airports, you have to make big asset investment decisions. How can you model demand in order to guide those investment decisions?
Believe me, there are many more ways to go bankrupt than to make money. What we’re really building here is a value network, and the composition of that network determines the load. If I have a network of nodes A, B, C, and D, and I add a new node, E, that can have an impact on all the nodes at various times of the day. But if I add F, that could impact some nodes differently than others. It’s an interrelated loading problem that’s very difficult to model. So I thought, OK, we’ve got these guys taking chaos and organizing it into order, so we can file flight plans and make it all look organized, or actually be organized, on the back end. What I need is another group of people to create organized chaos, or complexity, to mimic the behaviors of a region of travelers, that can be used to test how well we can reorganize that chaos into order. That’s not simple either, it’s going to depend on pricing, and time/value tradeoffs, and density of your transportation network, and what nodes you introduce, and what the interactions between the nodes are, because every city you introduce has a different effect on the others.
I realized we needed the kind of thing that SimCity represents. When I was in school we called it discrete time simulation, but then it got a biological twist and became complexity science, and at one point chaos theory, though complexity science is the more accepted term. Along with one of my directors I had a served on the board of the BIOS Institute in Santa Fe, an offshoot of the Santa Fe Institute which was biological or evolutionary modeling of large complex systems. So I got in touch with some of those guys and we offered them a job. We said, hey, come on board and we’re going to build the most sophisticated regional travel model that’s ever been built, and we’re going to use it not just to postulate the future but to build a business.
So they came on and worked for about four years and came up with this other piece of technology, which is married to the optimizer, and the simplest way to describe it as SimCity on steroids, very targeted on the problem of regional travel. So we’ve got nine different types of agents or sims, populated using IRS statistics, operating in ten-square-mile zones, they all have different rules on how they book trips and what flexibility they have. Then we loaded on top of that a bunch of demographic data — some we bought, some we got from DOT, some from IRS. And then we loaded all the schedules for all the airlines between all the airports in the contiguous 48. And then we developed algorithms so we could estimate driving times, and added time-of-day congestion through various nodes. And then we added train schedules. The result is a very sophisticated, very high-fidelity model of the transportation options you would face if you lived in one ten-square-mile region of the US, and needed to go to another one.
The story so far sounds like a high-tech dream come true, and if DayJet succeeds that’s just what it will be. But there are a couple of big reality checks. First and foremost is regulation. Although DayJet’s technology is built to exploit the benefits of extreme virtualization, the FAA places severe limits on how far that can go. So while DayJet would have preferred not to own and operate its entire fleet, hire and train all its crews, and manage all of its airport facilities, that’s exactly what it must do to meet current regulations. The business can only succeed if it works within the current regulatory regime. Of course if it does succeed on those terms, and if that success paves the way for regulations that are friendlier to a more virtualized approach, DayJet’s travel-oriented network operating system will become all the more valuable.
Another reality check is the customer’s experience. Because there are no fixed schedules, there’s much more fluidity than you can reasonably present to a customer. Internally the system may reschedule your trip a dozen times, but you won’t want to be flooded with rescheduling notifications.
This is what we’ve been wrestling with for the last six months. What it means is that you just add more constraints. We won’t flip you around all over the place. You start by negotiating as big a window as you can accept, because the bigger the window, the cheaper the ticket. And it’s not a departure window, it’s a window in which we will complete the mission. Then the challenge operationally is how to shrink those windows down as you get closer to flight time, leaving enough space for disruption recovery. We’re learning, and we’ve discovered that the night before we can crunch that window down. So we notify the customer the night before that you have to be at the airport by time X, and you’ll be at your destination by time Y.
It’s all music to my ears. I’ve been dreaming about this for years. Ed’s actually doing it, and I can’t wait to see how things turn out.