What is an API?

In my current job, I’ve had a lot to do with our product’s Application Programming Interface (API) – namely documenting it. For those of us who live in the technical world, we’ve dealt with APIs for many years and take them for granted. However, for those who live outside the technical world, an API is just another techie-TLA. The documentation with any API tells us how to use it, but not fundamentally what it is.

So here is my attempt at a simplified, non-technical analogy of an API.

Imagine, if you will, a puppet. We want to make the puppet dance. To do this, we grab the puppet by the arms, lift it, and make it perform a dance. This is akin to controlling a product (the puppet) through its native User Interface (its limbs). In other words, it is controlling the puppet using the bits that the puppet-maker made.

However, there comes a day when we want to control the puppet using two wooden sticks in the shape of an X.

Why would we want to do this? Well, for a start, it gives us a lot more control over our interface to the puppet. Because we have direct control over the sticks, we can customise them to fit our hands perfectly. We can paint the sticks any colour we want without affecting the puppet in any way. We could, if we wished, connect the same part of the stick to both the right arm and the right leg, meaning that these limbs would both move in unison with only one twitch of our hand.

This allows full control over the look and feel of the controlling interface.

With this in mind, we design our two sticks in the way that makes them a perfect fit for our hands. This leaves us with a puppet, and a controlling interface. All we have to do now, is hook them up.

With what does one connect a puppet to a stick? String, of course.

These strings allow for the movements made with the wooden X to directly control the movements of the puppet. And, as mentioned above, those movements can be customised, depending on where and how one ties the strings.

So a standard product (the puppet) is being controlled (via string) from a customised interface (the two sticks).

In this case:
– the puppet is the underlying product/program.
– the sticks represent the interface – designed, built and customised by you, the user.
– the strings are the API – they are what connect the controlling interface to the underlying product.

The end of a string is a somewhat generic connector. In other words, strings can be connected to almost anything. They could be tied directly to your fingers, meaning you’re the only one who can control the puppet; they could be tied to some kind of robot, which could make the puppet dance automatically; they could be tied to the two sticks, and those sticks can be given to anyone (or anything), allowing control of the puppet by whomever has the sticks.

This is the same for an API. The API allows a custom interface to control a product using a generic/standardised method. This allows for the control of a product from a custom-branded portal/interface. The interface designed by you can be an intuitive interface for your customers’ needs, saving you the cost of developing the underlying product.

It opens up a whole new layer for user experience design – one that does not need to involve creating an actual product. If the product is good, and can be controlled via an API, then there’s nothing to stop you adding value through a more intuitive interface. This allows the product’s developers to concentrate on the core product, while you can create the interface. And, as Apple has shown, a good interface can go a long way.

Moreover, it opens up an easy route for partnerships between technical companies. A customer might want a whole solution, but the best companies might be the best because they have concentrated on one specific area (“core competencies”” and all that). Using APIs, an interface can be developed that will use the best products out there, and seamlessly integrate them via their associated APIs. This is a win-win situation – the customer gets the best products, and the companies get sales.

So, hopefully, this will demystify APIs somewhat for those from a non-technical background. They are simply a means to attach one’s own controlling interface to a product, allowing for custom designs and/or automation.

All that you need to worry about now is checking that the underlying puppet isn’t Pinocchio, about to develop a mind of its own and not obey the strings.

Advertisement

Marketing the Engineers

This article from the Irish Times mentions how engineers missed the “marketing boat”.

I firmly believe that this is true. Having completed a Smurfit MBA in order to get away from being “just an engineer”, I found that my transferrable skills were virtually unknown in the working world. Those engineers on my MBA course who wanted to stay in the engineering arena found jobs fairly quickly. However, those that wanted to get away from the “pure” engineering field were destined for a longer job search.

People talk about arts and commerce as “good, general degrees” (which they are), but that is rarely said about engineering. However, the critical thinking and problem-solving skills developed with engineering are applicable anywhere. Moreover, the ability to understand other people’s complex ideas that any engineer must have in order to get the degree is directly relevant to needs-identification in sales and marketing.

Furthermore, while not considered a “creative” discipline, engineering requires more creativity than people generally realise. The ability to break down a problem and then figure out a way to solve that problem is well understood, and the phrase “problem solver” is on everyone’s CV these days. But there is a difference between someone who solves a problem by going through a prescribed approach, and someone who solves a problem in a “creative” manner.

What separates a “creative” problem solver from a “by-rote” problem solver is a deep understanding of the underlying system (usually a very complex system). This understanding is a central point in coming up with novel (“new to world”) or creative solutions that have never been used before. Engineers spend a lot of time examining systems, so the interaction between elements is something that we don’t take for granted.

An example:
Coming from an electronic engineering background, one system that I would be used to are circuits. At the digital level, every element does a specific job, has at least one input (1 or 0) coming from another element, at least one output that goes to another element…and the whole thing creates a system. At a digital level, things can have quite simple causal relationships. But beyond that, an electronic engineer must take into account the real world. Signals that are analogue are not simply 1 or 0. Current flows around a circuit board following certain paths, which can interfere with the inputs and outputs of other elements if care is not taken.

At a Toastmasters meeting yesterday, one of the topics presented was, “Does the pressure on companies to reduce price also reduce quality?”. The answers given were all given by those who thought “Yes – a price decrease must equal a quality decrease”. We’ve all seen the “Project Triangle” at some point. This clearly shows us that it is possible to produce something a low cost and of good quality if we sacrifice time. The time element can, however, be minimised by having good problem-solvers involved, allowing for good, low-cost solutions with a low time-to-market (or at least lower than that of the competition).

In conclusion, the M.O. of an engineer’s brain can be useful in so many non-engineering arenas: CRM – a network of customers is a system; Sales – understanding of customer needs boosts credibility; Strategy – the market is also a system, with cause and effect; Marketing – a campaign is a series of linked occurrences, like a system; Project Management – a project is a system; etc.

Please remember that just because we’re engineers does not make us emotionally unintelligent Dilberts. Additionally, anyone with an MBA has fundamental business/economic/strategy understanding.

And, as I’ve mentioned above, the fundamentals are what really count.

—

Edit (14th March 2012): This article from the Globe and Mail tells of how engineers have overtaken MBAs in leadership positions. So just imagine what an engineer with an MBA can do. (thanks to Fergus for the link)