What a Retired Navy Pilot and a 50-Year-Old Fighter Jet Taught Me About RPA Development

Brandon Nott is senior vice president of product at UiPath.

I had the opportunity to tour the USS Midway when I was in San Diego, CA. On the flight deck sits one of the most iconic aircraft ever built, the F-14 Tomcat. Though most people came to know about the F-14 from the movie Top Gun (1986), the Tomcat earned its place in the annals of history on its own merits.

Background

The F-14 is a bit of an anomaly in the aviation world. Making its first flight almost 50 years ago, it was built to be an attack fighter, a defense interceptor, and a reconnaissance airplane. This three-in-one platform made it one of the most versatile aircraft in history.

This flexibility came at a price—the F-14 was the heaviest and most expensive fighter of its era.

To meet the speed requirements of the U.S. Navy, the first version of the F-14 was fitted with dual Pratt & Whitney engines generating over 40,000 pounds of thrust, allowing it to reach Mach 2.34 (1795 mph).

To put that in perspective, that is about the same amount of power as many 737 airplanes in operation today.

Aircraft carriers

As a Navy jet, the F-14 was aircraft carrier-based which means it had to land and takeoff from aircraft carriers repeatedly and without incident.

For landings, carriers are equipped with arresting gear which is essentially a few cables (arresting wires) attached to a massive piston that is capable of safely stopping a Tomcat traveling at 150 mph (at full throttle) in just two seconds.

In fact, arresting systems are so powerful, they can absorb over 57 million foot pound-force of energy in a single use.

The arresting hook

As I was on the USS Midway walking around a retired F-14, it occurred to me that the linchpin of this whole operation is the arresting hook, or tailhook. It’s not much to look at but it gets the job done.

When the F-14 lands on the carrier the arresting hook hangs down and grabs one of the three arresting wires.

It blew my mind that the entirety of the force from this heavy airplane, traveling at 150 mph with full throttle, is applied by this one, modestly sized hunk of metal with a couple of bolts. Crazy.

A history lesson

As I was standing on the deck of the USS Midway, I struck up a conversation with a retired F-14 pilot who was volunteering on the ship. I was asking him about landing on aircraft carriers and if that tailhook ever made him nervous.

He told me that the tailhook is made of unbelievably strong alloy steels and the technology for building the arresting hook systems had been perfected for decades by the time the F-14 came along. (Although he did recall one incident of an F-14 tailhook breaking as it was landing on a carrier, which caused the fighter jet to crash into the ocean. Luckily, the pilots were able to eject prior to impact.)

The bigger concern was something called a “hook skip bolter” in which the tailhook bounces off the deck and misses the wires altogether. Despite a complicated hydraulic system that acts as a shock absorber to help prevent a skip, it does happen, and that is why pilots apply full throttle during landings—so that if they miss, they can takeoff and try again.

The takeaway

In the end, this little hook on the back of the F-14 had an enormous amount of engineering and decades of trial and error that went into it.

From its alloy steel composition, to the hydraulic mechanism that held it in place, to the raised position of the arresting wires, to the giant piston that absorbs the force of the plane, all this engineering comes together in two very critical seconds to safely stop the plane.

How this applies to RPA development

Touring the USS Midway and specifically the F-14 Tomcat, I couldn’t help but be humbled. The business and engineering challenges that I face daily feel almost child-like compared to what it took to engineer landing an F-14 on a moving aircraft carrier.

I started thinking about how some of these principles applied to my Robotic Process Automation (RPA) journey.

1. Build components out of alloy steels.

Well, don’t literally build them out of alloy steels, but build components and sub-systems in such a way as to make them as hardened and durable as possible to account for extreme and repeated stresses.

When I built my first RPA process (ordering appraisals for home mortgages), I spent weeks breaking the process out into a dozen modules and hardened them by adding retry loops, error handling, logging, etc. so that they could recover in the event of an unexpected event and increase the chance for automation success.

2. There is elegance in simplicity.

The single tailhook of the F-14’s arresting system seemed inadequate at first, but after learning about the engineering and decades of learnings that went into it, I began to appreciate the beauty in the solution.

Using the right tool for the job is essential in RPA.

There are many ways to perform an operation using RPA, perhaps there are too many in many cases. Look to reduce the number of activities, components, and add-ins you use and keep your solutions as elegant as possible. For example, if you need to pull some information from a simple website, there is no need to bother with multiple activities to navigate the site and extract data if you can use a simple HTTP Request activity to download the page, then parse the return.

3. Have a backup plan.

When the F-14 touches down on the carrier the pilot immediately applies full throttle so that if the plane misses all three wires, the plane can takeoff and come around for another landing. 

Robust solutions make use of retry strategies, alternate communication channels, and intelligent routings to ensure the desired action happens correctly. In your designs, do not code for the happy path. Code for failure. Anticipate how the application is going to respond if you lose internet connection, data is returned erroneously, an element doesn’t exist on a page, a page takes too long to load, etc. and code your process accordingly.

Thinking through the ways your process can fail due to existential influences can be the difference between a failed or successful run. Over time, reducing process failures makes a material difference to your bottom line!

4. Have a backup plan for your backup plan.

In the event of catastrophic failure, have a plan. When the tailhook broke on that F-14 and it crashed into the ocean the pilots were able to eject and survive. You can see the incredible footage: 

Code your projects so that just like the lives of the pilots could be saved, your most important assets can be salvaged. In the case of my mortgage appraisal example, a process failure should not harm the loan.

Attempts should be made to save the data being worked with, generate logging/telemetry data about the failure, and most importantly if a user is involved, give them as graceful an experience as possible by letting them know what happened and what to do next.

Conclusion

Building RPA solutions with robustness, simplicity, and redundancy in mind are key to the long-term viability of your automation program.

When starting to architect or code your business use cases ask yourself, "what are all the things that can go wrong?"

Take that list and for each item determine how likely is it to occur, and what is the impact on the business? From there you can determine if you want to proactively try and resolve it, reactively account for it, or simply do nothing if you determine the risk to be inconsequential.

However you chose to mitigate your process risks, consider the experience that your users, admins, business owners, etc. are going to have. After all, automation exists to elevate the human experience, not to detract from it.

Want to know more about how automation is elevating the human experience and reinventing how business is done?

• Watch our on-demand webinar "What is Robotic Process Automation?"

• Learn how to successfully prepare for a journey with RPA

• Find out how savvy organizations are using RPA to thrive in the 'automation first' era