It’s 2018 and software is all about connectivity. These days, our clients expect not only to be able to access their web applications through their browser, but also via their phone or from within a different application such as SalesForce, Outlook or Microsoft Dynamics.

Without knowing how we make these applications talk to each other, it can be difficult for clients to understand exactly where their “application” begins and ends, so I thought I’d write up this blog post to try to demystify some of the contents.

A donut factory

Let’s quickly digress and talk about a factory. A donut factory in fact. Here it is now…

Dan’s donut factory is superb - in fact it makes the best donuts in town. The trouble is, it has been built in the middle of nowhere and nobody can get to it:

Dave, Ben and Cath all want to buy Dan’s donuts, but there’s no way that they can get them from the factory. So, Dan digs deep and builds a road to his factory…

…and now he can ship donuts to other people and companies that want them:

This is great, but the job is not done yet. Even though other people can now get Dan’s donuts, they can’t just dump them in their shops and hope they sell. No, they need to be packaged and presented in a safe and attractive manner. Look at the beautiful display Dave has made in his deli:

And now that both Dave and Dan have more control over how the donuts are presented, they can finally be sold to the public:

I don’t mean to get too Miyagi on you, but the donut factory actually represents…your software (gasp!). See, you’ve been learning all along. Here is how everything fits together:

Your application

This is the donut factory. It exists in complete isolation when it is deployed to the internet.

Your API

This is the road. It opens up a pathway to your app, and allows other software applications to communicate with it automatically.

Widgets, packages & plugins

Different vendors may label these as different things, but they all mean the same. Basically it is a bit of configuration that is done by other software in order to a) connect to your API (security, authorization etc); and b) display information from your application in a nice and useful manner.

It’s worth noting that even though the widgets/packages/plugins are displayed by other software (such as SalesForce), your own developers are often able to build them themselves and upload or install them using special tools provided by the vendor.

Other quick questions

Here’s a few other points that sprung to mind while I was writing this:

What is an ‘app store’? Often the other vendors will sell your widgets, splitting the profit with you. In these cases, the vendor creates a store which lists all the different widgets that are available - yours included hopefully!

What is a development platform? This would refer to the software that the vendors provide, allowing your developers to upload/install your widget.

How does a mobile app fit in here? The mobile app would be the shelf in Dave’s Deli. Dave’s Deli represents your mobile phone.

Which is the best Karate Kid movie? The first one.

What does API stand for? Application Programming Interface. It’s just a set of rules that two pieces of software (your factory and Dave’s Deli) follow in order to understand each other.

Does it cost extra to have an API built for my software? Yes. The extent of additional cost depends on how your application has initially been developed. These days, it is common to actually build an API-first application, and make your website a consumer of your own API.

What does it mean to “eat your own dog food”? This is a phrase common in software development. In this scenario, it describes the point above - where your own software does not have any special access over and above that provided to third-party vendors.

Summary

When I was kid, I used to wonder whether the Karate Kid producers found a black belt that could act, or an actor that could fight. In hindsight, I realize they did neither.