By Jen Schellinck and John Stroud

Analogy 1: Rockets and Planes

In my job, I’m often asked to talk about and explain AI to non-technical people. I really enjoy doing this, and I strongly believe that non-technical people shouldn’t be expected to learn all of the nitty-gritty technical details about how AI (data science, data analytics, machine learning, etc.) is implemented in order to make good decisions about AI. I think analogies are a powerful tool that can help with that because they tie new technologies and ideas to something people are already familiar with, which makes the technology more relatable. I also think that it’s up to us, the technical people, to create realistic and intuitive analogies – ones that are validly similar and legitimately helpful to the people who need to make decisions about these technologies.

To lead with one of my most recent analogies, let me start by talking about rockets – those typically slightly cone-shaped objects designed to shoot straight up into the sky.

To make a successful rocket you need: rocket fuel + materials to build the rocket + skilled people who know how to design and build rockets (knowledge of physics, engineering techniques, etc.)

I see AI, right now at least, as being very similar to rockets in a number of ways. On the AI front, data is the fuel, relevant hardware and software are the materials and the data scientists (machine learning specialists, business analytics specialists, etc.) are the skilled people doing the building.

When it comes to rocket building, you have amateur hobby rocket people building plastic pop bottle rockets in their backyard, you have people like this guy who take ‘hobby’ rocket building to a whole new level, you have companies sponsoring hobby rocket makers in the hopes of a new breakthrough, you have companies making commercial rockets (e.g. to get satellites into the air, or for military purposes) and then you have NASA and other space programs building giant rockets designed to carry people to the moon and the space station. And of course you have people doing research on how to build rockets, and developing theories about rockets in universities.

If we flip over to the AI side of things, you see much the same: you have people using their home computer to have a bit of fun with some pre-built neural net or bot, you have people who are technically doing AI only as a hobby, or on the side, but in a very serious way (see for example many of the people who enter Kaggle competitions) you have companies and organizations sponsoring these competitions, you have smaller AI companies developing new products and then you have the truly massive companies who are building AI on a massive scale (e.g. Google). You also have many AI researchers in universities.

Now, to take what might at first seem like a sharp left turn, you also have people building airplanes.

Are airplanes rockets? Arguably, no. But still, it’s a bit confusing. Rockets and airplanes both fly through the air, they both use specific types of fuel and some airplanes even have rockets attached to them. We also might imagine that, in a pinch, if someone gave you the materials that would be used to build a plane, and some airplane fuel, you probably could build a rocket. You’d just have to configure things a bit differently. As well, it seems like there would be a significant overlap in the knowledge, theory and techniques required to design and build airplanes and rockets.

Where am I going with this? Here I want to suggest that you can draw a distinction between standard IT and AI in the same way you can draw a distinction between airplanes and rockets.

Why do I want to do this? Because I often see a situation in organizations that can be illuminated by this analogy.

Let’s say we live in a world where every company has its own private airplane, or even fleet of airplanes (don’t ask me why – maybe in this alternate reality the earth is ten times bigger, and we just need them to get around). The larger organizations might also have airplane hangers, a stable of airplane mechanics, etc. Less well-off organizations maybe try to make do with just a hang-glider and a really big drone.

Now let’s suppose that, for some reason (again, alternate reality) everyone suddenly realizes that rockets are also, possibly, a very useful technology, and everyone wants to add ‘rocket capability’ to their company.

First of all, we might imagine the decision-makers in these organizations saying a number of things, including:

• But we don’t need rockets, we already have planes!
• Planes, rockets, eh, what’s the difference?
• Rockets are super cool – in fact, we can replace all of our planes with them!
• Okay, fine, but can’t our plane people just do rocket stuff?

You can see that the response to these statements might be yes, no or maybe, depending on the exact situation.

There’s also the question of where to put the ‘rocket people’ – do we add a new division to the plane division? Do we add them to the part of the organization they will be directly supporting (e.g add them to weather forecasting, because the rocket will be used to get good weather forecasts?) And do we provide the rocket people with their own budget and equipment, or do we ask them to get what they need from the airplane people?

We can see some issues arising here:

Airplane people and rocket people are similar but different – treating them the exact same way won’t work, but keeping them completely separated would seem to miss out on useful synergies – maybe someone who has always worked with airplanes turns out to have a flair for rocket building, for example.

Rocket building needs similar but different (and often more expensive) equipment and fuel. If they keep pestering the airplane maintenance staff with esoteric demands, or blowing the entire fuel budget, relations will not be good. On the other hand, if they’re only ever given enough parts to build tiny toy rockets, they’re not going to be much help to the weather department.

Rocket building is more experimental and often more explosive. Having people build rockets in the airplane hanger might not be a good idea.

Piggybacking the new rocket building admin and infrastructure (materials supply chain, budget, contracting) on the existing airplane structure is going to add more work to what is probably an already overburdened airplane department, that executives and other members of the organization are relying on to get to their meetings over on the neighbouring continent. On the other hand, adding this to the relevant functional department might not work either (i.e. sorry rocket folks- we don’t know how to buy rocket fins here in the weather group, we normally just buy things like desks, ball point pens and weathervanes)

Arguably, these questions, and situations, represent organizational growing pains, and presumably organizations will find ways to incorporate the new rocket technology into their structure overtime.

For instance, it’s true that airplanes and rockets need a lot of the same physical infrastructure, equipment and gear. So why not capitalize on that similarity and share some of the relevant basic infrastructure? This is maybe only possible if the existing infrastructure is already sufficient and well organized, however.

Here, my purpose is just to make the point that rockets and airplanes are importantly different but also importantly similar.

Analogy 2: Electric Power

The rocket analogy is useful at a high level, but to get into more details – e.g. what is AIaaS, PaaS, IaaS, etc. – a different analogy is more apt. One analogy that I often use, and which I think is particularly relevant for organizations, is comparing the IT and AI situation within an organization to the situation about 150 years ago when everyone was just starting to use electricity to power everything, and beginning to create amazing electrical machines.

In the same way that people in the last, say, twenty-five years, have really started to see the usefulness of data and computers, not long after the electrical generator was invented some companies realized how useful electrical power could be, and started setting up their own private electrical networks for their company buildings and manufacturing plants, using banks of onsite generators to provide electricity throughout their space, that could then power a number of different electricity driven machines. These organizations were the early adopters of electrical power.

Over time, the situation evolved. Some entrepreneurs, rather than just using electricity within the context of their own specific businesses, realized that electrical power was so useful that they started up separate companies that existed as privately owned power-plants, selling electricity to a range of clients – in some cases an entire municipality might be a client. Sometimes these companies might sell not just the power, but provide equipment e.g. the streetlamps, as well. Eventually after a fair amount of time had passed, we ended up with publicly owned electrical companies and a public electrical grid that everyone taps into. We now have a few large power companies, backed by public projects (e.g. hydroelectric dams). Everyone else – organizations and individuals alike, hook up to and builds on top of this.

The situation with data networks is extremely analogous (at least if you don’t squint at the details too much, and even then it’s not too bad). We started with the similar situation of many companies running their own intranets – stand alone, on-prem computer networks, just as some companies in the early days ran their own electrical grids using generators. Now we’re starting to having external ‘cloud companies’ saying – hey, don’t run your own intranet, let us supply you, and other clients, with the necessary data infrastructure and elements. Eventually, it’s possible we’ll see ‘the cloud’ become more of a public utility (the analogy here is a bit complicated by the fact that ‘the cloud’ is built using the internet, which is already kind of a public utility, but ignore that for now).

I imagine that the team running the electrical grid for a private company back in the day might have been in a similar position to IT teams running on-prem intranets for organizations today. In one sense, these networks are absolutely critical infrastructure, responsible for supporting critical operations – back in the day they literally ‘kept the lights on’ and also even more importantly the manufacturing machines running. Similarly, today, if an organization’s intranet goes down – no more inter-office e-mail, or critical kiosk reference guide or catalogue until it comes back up, and meanwhile no one can do their jobs properly!

At the same time, IT aren’t themselves operations. And they are probably frequently understaffed and underfunded – at least from their point of view! Nonetheless, if anything doesn’t go smoothly, they still hear about it immediately and are expected to fix it ASAP.

Now I’m imagining some keener coming to them (back in the day) and saying “Hey – we just heard about this cool new thing called ‘desk-lamps’, and if we could get desk lamps for everyone, instead of having electrical lights in just the hallway and bathrooms, that would be amazing! Also, I hear that these days you can just buy electricity from someone else – can we do that too? Maybe then we’d have enough electricity for everyone to have desk lamps!

I’m imagining the response from IT here being similar to that of an over-worked and under-paid parent dealing with an enthusiastic but unrealistic teenager – they don’t want to say no, but they’re really terribly busy just managing to keep the machines running and the lights on. So they say – okay, okay, I’m looking into the whole ‘electricity provider’ thing, but right now my priority has to be to keep the on-site generators running. In the meantime, maybe you can find an off-the-shelf DIY kit to build yourself your very own desk lamp, for your room. If you can find that, then you can have one in your room (but just in your room), as long as you don’t bother me about it too often, and fix it yourself if it breaks.

I think this is a very understandable outlook. The problem comes when it turns out that if everyone had a desk-lamp, productivity in the company would go up 200%, because people would start working twice as many hours. So, in the long run, it would be very worth it to get everyone desk lamps, but it’s also clearly a tough thing to do under the current circumstances, where the technical infrastructure staff is just trying to keep the critical machinery running day-to-day.

To me, a solution to this dilemma on the part of the organization might be to say – okay – we get that you’re very busy doing critical stuff that you can’t interrupt. You definitely keep doing that. In the meantime, we’re going to stand-up a specific team, made up of (electrical/data) engineers, just like you, but their specific mandate will be to investigate and implement novel developments in this fast-moving area – things like electrical providers and desk-lamps – and then work to integrate these novel developments into current operations and infrastructure.

It’s not clear if IT would like that solution, but ultimately, IT is saying – you want us to do something new and different, while still doing everything we’re doing now? Then we need more resources to do this.

It’s important to note here that this proposed group’s functionality is different from what any potential AI research group is doing. In this analogy, the AI research group is building exciting new types of complicated manufacturing machines that also need to run on electricity. They aren’t worrying so much about how these new machines might integrate into current or future infrastructure. But we could see how such a group might usefully liaise with the proposed new group above.

So where does AIaaS (or SaaS) fit into this analogy? I maybe have to stretch the analogy a bit, but a SaaS here is basically a company that says – don’t worry – we’ll give you all desk-lamps AND we’ll supply all of the power for these desk-lamps. We’ll connect all of the desk lamp wires together where they leave the building, connect that to an electrical provider that we already have an arrangement with, and take care of everything for you – including maintenance of the desk lamps. You don’t have to worry about a thing! However, if you stop paying us, we’ll take all of the desk lamps back.

From this point of view, a SaaS could actually be a great stop-gap measure, or even a permanent solution for an organization – IF the desk-lamps being offered exactly meet the specs required. The issue here is that many government organizations actually want super specialized very unique desk-lamps (e.g. architectural desk-lamps with a fully adjustable 18 piece arm and blue light filter), plus they have a huge number of safety and security measures that are required (for example, all of the lamp shades must be made of metal or rock, so that they can’t accidentally catch on fire).

This means possible SaaS options likely have to be much less off the shelf, and thus likely harder to get and more expensive. And also require much more work on the part of the technical team, which they’ve already explained, as discussed above, isn’t that feasible.

I do personally think there are legitimate solutions and options to be found in all of this. The main thing, when proposing these solutions to an organization, is to fully understand where the concerns are coming from on the organization side and fully addressing them before proposing these solutions – and just be very open about the risks and benefits of each one.