Peeling Back The Story: How Bananas Helped Launch An Industrial Automation Revolution

If you've ever been curious about the circumstances that led to the founding of Inductive Automation and served as a litmus test for the future Ignition — or what the importance of open standards in commercial industrial software has to do with either, then we've got a story for you.

It’s a story that begins not with a lightbulb moment of genius, but frustration over available SCADA and other software options, and a nudge from the potential waste of millions in bananas.

Yes, bananas.

This story is about how ad hoc pieces of software serving as the glue holding operations together created many of the industrial pain points that inspired IA’s mission to empower system integrators and automation engineers with a more practical and sensible solution.

When Custom SCADA Software Led to Vulnerability & Isolation

To tell this story, we need to take the Wayback Machine to a time when industrial automation solutions were frequently held together by the digital equivalent of duct tape and hopeful thinking. Imagine factories relying on orphaned bits of custom software with undocumented programming written in languages so ancient they'd make your modem seem cutting-edge.

Contrary to solutions built on open standards and supported by a company committed to being there, these temporary solutions were a trap. If the original developer was unavailable or the company went under, users were left with software they couldn't understand, fix, or integrate with newer technologies.

Most folks on the operational side were solving the same old problems using the same old mainstream methods — so-called solutions that ignored IT departments, and teetered on disaster.

But from disaster comes ideas and opportunities to build something better …

When IT & OT Didn’t Play Nice: A Pre-Ignition Tale

Enter Steve Hechtman, who in 2000 bought full ownership of the integrator business he’d co-founded years prior and found himself in the same boat as most integrators at the time. They did what they had to do to satisfy customers in the short term, which was creating custom code and solutions that would work for a while but weren't viable for long-term support.

After launching an exploration into IT practices and software, Steve knew the solution to this predicament was to adapt and apply modern IT to the particular requirements of the OT.

“The plant floor prior to Ignition was, frankly, inefficient and lacking in so many ways that it made you want to go pound sand,” Steve said. “Everything we tried to improve the situation simply wasn’t possible using available OT software that was at least 10 years behind the IT practices and software of the day.”

But after asking himself the question of why IT wasn’t being used on the plant floor, Steve quickly realized the answer: “The incumbent automation software companies didn't want it because it's difficult to monetize ‘simple, cheap, and open,’” he said. “Yet, IT was the most beautiful solution lying right there in plain sight.”

He recognized that using open standards fosters an ecosystem where different technologies can communicate seamlessly, and in turn empower users to choose the best tools for the job without being locked into (or out of) a vendor’s walled garden.

The lack of interoperability, affordability, and functionality of big-box proprietary systems was forcing Steve’s hand to do something.

But custom-written solutions are the things of nightmares for integrators. They’re fragile, barely proven, poorly documented, and unmaintainable. One power blip, one hard drive failure, and … crash! An entire factory can come down.

Steve was well aware of this. He’d witnessed production at a facility grind to a full halt when a dusty old PC that no one remembered — but that controlled a bar code reader and sortation system — went kaput.

He didn’t want to install more custom software, but customer demands sort of dictated it. Still, he knew he had a ticking time bomb on his hands with 50-plus clients relying on such precarious custom solutions.

"This was a tidal wave we all could see coming, and I wanted to stay ahead and not get crushed,” Steve said.

So at the end of each day, he’d spend from 10 p.m. to 2 a.m. researching and scouring the Internet for a solution to solve this mess.

His ideal solution was a theoretical commercial off-the-shelf software (COTS) that would not only offer functionality, but also the flexibility of interoperability and accessibility (ahem, key tenets of systems built on open standards).

“I just knew it was out there. And I was going to find it … that commercial off-the-shelf software that would give me a better night’s sleep,” Steve says with a grin.

Spoiler alert: it didn't exist.

When Factory Frustration Led to Industrial Innovation

Steve came to grips with the inherent limitations of previously existing solutions. And luckily, all he had lost was sleep.

So, he did what resourceful people do. In 2003 he founded Inductive Automation and decided to make his own solution — not as a one-off, but by leveraging IT software and practices into the OT environment, which was, of course, the key.

Today, Steve is proud of Inductive Automation’s major role in bringing such an effective solution to plant floors everywhere and unshackling integrators so that they can deliver unprecedented value to their customers. Ignition is so unlimited in what it can do that Steve likes to call it “the gift that keeps on giving.”

But revolutions don’t often bring change overnight.

Seven years were spent building the company’s reputation as an industry disruptor around the idea of unlimited everything and open connectivity by leveraging IT to the max. This improved security, throughput, and general understanding by leveraging well-known technology.

The IA team sent shock waves through automation and integrator circles with Factory PMI and Factory SQL before Ignition debuted in 2010.

Thinking back on the triggers that led to the birth of Inductive Automation and the idea of Ignition, Steve says he basically saw a huge functionality gap and wanted to close it.

“My customers wanted something better. I wanted something better. The answer was right there in plain sight, it just needed a few major gaps filled to make it work for OT. I couldn’t pass it up.”

And, he needed developers to build and support it all.

Enter Colby Clegg, the coding wizard from University of California, Davis (and future Inductive Automation CEO) who whipped up a prototype faster than you can say “system integration.”

Okay, maybe it was more like about a month. But that’s still impressive, and you get the point.

When Things Went Bananas … Literally

Though they felt good about the early prospect, Steve and Colby weren’t quite comfortable enough to say the new industrial tool was real-world-ready after three weeks.

But an urgent call came in like the Bat Signal from a major distribution center in Sacramento, CA, to push the timeline. A large grocery chain was in a real pickle regarding some ripening bananas that were about to be dumped if something wasn’t done ASAP.

The system running the refrigerated facility, including the banana ripening room, was three PCs running software custom-programmed by one guy. The guy unfortunately passed away and, you guessed it, the system crashed and took down the entire facility.

Steve recalls, “I got a call screaming ‘Help!’ because they weren’t sure what to do.”

Tons of perishable food – bananas and other produce representing millions of dollars, was on the line. A tough decision was on hand.

Even though it wasn't his system, Steve decided to jump into the fray. Why? Because this was the very nightmare scenario he imagined and wanted to avoid at the plants of his own clients.

So the barely-ready and yet-to-be-field-tested software was called into action. With an expedited coding sprint and the help of another UC Davis alum, Nathan Boeger, they managed to get the plant back into operation by afternoon to bring the bananas back from the brink.

Talk about a trial by fire.

And that, friends, is one of the cornerstone bedrocks of the beloved platform preferred by integrators and industrial automation professionals.

It wasn't born in a controlled lab environment with easy tests. It was battle-born — in a real-world predicament with real consequences.

The distribution center case wasn't the first time Steve and company were called to help remedy an industrial pain. But it was the first high-stakes scenario test for the pre-Ignition prototype. And it passed, proving the biggest innovations sometimes sprout from the stickiest situations.

When Resolving Past Predicaments Fosters The Future of Automation

Fact: Being a system integrator or running an integration company is a tricky business with a lot of pressure to keep plants up and data flowing. When computers and operating systems become obsolete, industrial software and closed architectures can leave users stranded.

And so the banana crisis is the perfect cautionary tale of the limitations of poorly supported or unsupported software not built on open standards.

That’s precisely why Steve founded Inductive Automation, which championed a simple solution to a complicated problem — and in the process blazed the trail to the next phase in industrial automation which he likes to characterize as “easy, fun and affordable!”

The plant floor improved by a quantum leap, and those ad hoc solutions of yesteryear became unnecessary.

Today, IA’s flagship product, Ignition, still stands out as the only truly universal industrial automation platform compatible with practically any OS and any device. Industrial operations are high stakes, but Ignition is low risk — and the ticket to a better night’s sleep, too.

So next time you bite into a perfectly ripe banana, think about the little pieces of software that nearly sent them to the landfill. And celebrate the open platform that rose to meet the challenge.