Every so often I get asked the question of how did we come up with our name "Inductive Automation." I think Carl first suggested it and and it stuck. This is probably because it's such a fitting name - let me explain...
From Wikipedia "Inductive reasoning, also known as induction or inductive logic, is ... commonly construed as a form of reasoning that makes generalizations based on individual instances. " That's precisely what we did when we created the framework for what was to become the Ignition platform.
Before we wrote a single line of code, I developed a philosophic stance in response to my specific experiences in the controls integration business. In other words, I established generalized principles from my specific experiences and observations. Therefore the "Inductive" part of Inductive Automation is very appropriate.
The Observations
My experiences and observations were many and varied but they boiled down to the following:
1) I was frequently being asked to develop or integrate database applications into industrial systems but industrial software just didn't deal with databases and when it did it was ugly. Developing "one offs" with custom code was not economically feasible, nor was maintaining it in the longer term.
2) Unreasonable pricing for industrial software alone was killing way too many deals. I lost one customer (for a few years - he's back now) because he thought I was trying to rip him off. The whole job was $105k but $85k of it was software which we had to buy. I'd already pared down my labor to $20k due to the high overall price tag. In retrospect, it's better I didn't get that job because my labor was so low I would have lost money.
3) Installing industrial software alone was a huge time consuming process. For an integrator you would think this would be a good thing because it's usually billable. But I would rather be putting my time toward developing a better app - not installing software.
4) Most industrial software only runs on certain versions of Windows and when IT wants to upgrade, the whole process usually becomes a nightmare – if not impossible – forcing IT to maintain different flavors of Windows.
5) Realizing the full potential of industrial software wasn't possible due to lousy deployment models and lousy licensing models.
6) I observed that standard IT software and technology was inexpensive and worked better than what I saw as expensive, non-standard, convoluted, odd-ball industrial software.
7) I also saw that the simple task of logging PLC data to an SQL database server was being portrayed as rocket science or something. Why should it take hours or days to setup a process historian? Our programmers who came straight out of the university at first had a hard time understanding what the big deal was. Nor could they understand why a historian should sell for $30k or more. They finally concluded that this industry has had the wool pulled over its eyes for a long time and that it's about 10 years behind the IT industry in general.
8) When I even mentioned the possibility of a web-based solution to customers it instantly hit a chord with them.
9) Most industrial software scaled poorly, strictly from a technology standpoint. In fact, at a certain point of scaling up maintaining it effectively usually becomes impossible, whereas normal IT technology scales very well with little effort.
10) Industrial software security was non-existent or oddball at best whereas standard IT technologies pretty well have security figured out.
11) Generally speaking, canned middleware applications offered by industrial vendors are totally out of touch with anything customers actually need. In reality, every manufacturer already has its own processes developed out of its own experiences in dealing with situations. The point is not to redefine these processes, but rather to automate them in software.
The Principles Concluded
So what are the general principles I derived from all these experiences?
1) Don't reinvent the wheel. Well established, proven and inexpensive IT technologies already exist. Use them.
2) The more eyes on the data the more useful a system is. Accessibility is paramount. Therefore leverage web-based technology.
3) Be database centric. This aligns with the principle #1 above. IT departments can support database servers (which do need backups and maintenance from time to time). Be able to support any database server an IT department uses. Database servers form the ideal interconnection point between different software applications and greatly increase the usefulness of any software application. Islands of information and proprietary data repositories are a bad thing.
4) Avoid software that imposes arbitrary limitations just to make more money. From observation, this really jacks people up.
5) Be cross platform. This includes every flavor of Windows as well.
6) KISS (Keep It Simple Stupid). Software should never be more complex than is necessary. Avoid bloatware. Avoid heavyweight installations. Software should seem lean and mean and refined.
These are the general principles I started with and when I did so I wasn't even planning to start a software company (look at the first principle again). All I wanted to do was find software out there that met these criteria. I spent several months looking exhaustively and only found isolated bits and pieces out there. Therefore, I took the plunge and started a software company. Our guiding light has always been the above principles and they seem to be good ones because we now have thousands of installations in over 50 countries.
