You may have wondered what the difference is between a bot and an integration! Or probably not, maybe you haven’t really cared…!
So, let’s take one step back, why should you care? There are by now a huge number of services that offer APIs as a way to access their services, i.e. that you can programatically use a service by writing software code. If you are a lawyer or works in a power company, you may not think in terms of code or APIs, you want to service your customers. But you should care about code and APIs as so-called micro-services have the potential of turning upside down on how you can engage with your customers if you understand how to. The most trivial example that most people now understand are SMS-services. Companies like Tropo (now part of Cisco) and Twilio offer ways of sending and receiving text messages, and you can make your own code to send or receive these messages. This allows power companies to send you a text message telling you it is time to read the power meter, and when you send a text message back, they register the value and adjust your bill.
Behind the scenes, a simple bot receives the text message from you, looks up your account based on your phone number and stores the value in a database. And the power company’s bot may use Tropo or Twilio’s services to handle the SMS parts of this.
You have also seen integrations through all sorts of plugins, apps, or extensions on Facebook, Dropbox, LinkedIn, Slack, Google, or others. You add a birthday app on Facebook, and you are asked if you want to give permissions to this app to read all your friends’ birthday information. That’s an integration, you give an app access to something in your account, and it will behind the scenes act as if it is you, using the APIs to collect all your friends’ birthdays and create a cool birthday calendar or something.
There is also a simpler version of an integration. Let’s say you have all your files in Dropbox, and you want your new Android or iOS app to be allowed to store something in a specific folder. The mobile app can then get a special web address (URL) where it will be allowed to read or store files only in that folder. In the first flavour of an integration that I mentioned, the app needs to present itself and get access rights that cannot be transferred to another app. The second version of an integration will allow anybody with the right URL to read or write files.
Ok, you actually should now understand the basic difference between a bot and an integration. But still, why should you care? Let’s go back to the example of the power company. Many power companies have installed “smart power meters”. These meters basically report home how much power you have used. Behind the scenes, the power company may still be using an SMS service to transport the messages, but maybe the smart meter is on a Wifi network instead. So, where did the bot go then? There’s no bot anymore as the power company controls every component involved, and there is no real need for a bot to communicate with a user. Instead the smart meter can contact the power company’s “report meter status API” directly. However, what if the power company wants to offer you smarter services, like the ability to check if you left the oven on. Or that you can check status on lamps and turn on light when you are away. Maybe even automatically turn on and off lights in your house. Burglar alarm companies have done this for a while, and what do they do? They make a separate app you install on your mobile.
But what if you want to turn on the lights whenever the alarm is turned off? Your power company controls the light switches and your alarm company the alarm and maybe even the lock on your door… They don’t talk to each other.
Now we are at the core of a service innovation that can be powered by bots and integrations. Solving a real problem for your customer means that you have to interact with other services that you don’t control. This example was from consumer services, but the same is true in business services. To deliver the business outcomes your customer desires, you need to go behind your stovepipe of services and integrate with other services. However, people are naturally concerned about giving their insurance company direct access to their health information. But in a life threatening situation, they will probably gladly give full access to the same information to emergency medical personell. Solving this privacy and security problem is of course non-trivial. Services like built.io, Zapier.com, and IFTTT.com do this by allowing you as a user to use integrations to connect services in new, smart ways. But in order to do that, you need access to what you want to share, so it would require each user individually to explicitly set up a connection between his or her health info and the emergency services.
As another example, Cisco Spark, the business messaging and audio/video calling service, has both bot and integration support. My Spark Army Knife app has used a Spark integration up to now. I will shortly post the code to show how you, in a very simple way, can also add bot capabilities, and how using both bot and integration capabilities give you great value when making a Bot app. Later, I will share with you how I’m connecting my personal instance of the Spark Army Knife app to my personal instance of a Box app, thus allowing cool, new functionality in Spark rooms without giving Spark (and thus Cisco) full access to my Box files.
If you have stayed with me all this way, you deserve a more explicit explanation on the difference between a bot and an integration: A bot has it’s own identity (e.g. an email address) and is given a long-lived security token (or password if you like) that it uses to communicate with the services on behalf of itself, but to do stuff for many users. Other (human) users communicate with the bot, and it can (with various smartness like natural language processing) answer the human user. This is why the power meter text message example is a bot. However, it is very simple. It hasn’t even a password, is fairly dumb, and it needs something like “METER 123455” to understand that you are sending in the reading of the meter.
An integration is to give an app or service access to use the services or parts of the services on one user’s behalf behalf. Either they are given a password or difficult URL to use (the simple flavour of integration like the Dropbox example) or each user needs to go through an authorisation where the user grants the rights to the app/service. In this latter case, the service also needs to be known to the owner of the services you are granting access to (like Facebook). This gives an additional level of security, and this is what is typically used to grant access to applications to services like Facebook and Google.
So, stay tuned for an update to the Spark Army Knife code! You can try it out live already now: if you are a Cisco Spark user, just create a 1:1 room with armyknife@sparkbot.io!
RSS - Posts