Slack, Chatbots, and Voice: At the Intersection of Humans and APIs

Over the last year, we have seen growth in messaging platforms for business. These platforms have changed the way we communicate within and across teams. But why have these platforms succeeded where others have failed to gain the same kind of traction? This article explores the growth of messaging platforms, how APIs and chatbots are changing the way people interact with software, and what it means for digital transformation as well as the future of application development.

Chat: Not just for humans

The previous generation of messaging platforms offered very little in terms of integration solutions. Many focused on connecting humans, but didn’t extend the platform to allow for automation and integration.

The recent generation of messaging platforms, from HipChat to Slack, expanded their definition of messaging and collaboration to include software outside of the platform. Combined with the abundance of open, web-based APIs, these platforms have taken on a life outside of their original design.

These new products demonstrate what happens when you release the choke hold of a closed software system and embrace the true definition of a software platform. By allowing it to be extended through API integrations for emitting and receiving messages, businesses can change the way they collaborate. Entire business workflows can be viewed and coordinated inside of the messaging platform. And chatbots are leading the way.

Chatbots as a User Interface

Chatbots, or bots for short, are agents that can interact with humans to perform a task. The interactions may be simple and follow a pattern-based approach, such as ‘Add milk to the shopping list’. Or, it may be more sophisticated and able to understand human speech and interact in a conversation.

Bots are nothing new. In fact, they have been around for quite some time and used in different settings. The explosion of chatbots is due to several reasons:

1. The rise of messaging platforms, such as Slack and Hipchat
2. The growth of web-based APIs used for mobile and partner integration
3. Recent advances in AI, including natural language processing (NLP) and cognitive computing
4. Application fatigue from the overwhelming number of applications required to keep teams in sync and get jobs done
5. The growth of mobile devices that extend the reach of applications beyond the desktop

Messaging, combined with the power of APIs and chatbots, are changing the way we interact with software. This iteraction is becoming more reactive, contextual, and automated. To fully understand where this is heading, let’s first revisit where we are today.

Software Silos

The traditional view of software applications is that they are built to solve one or more problems that is either common across all kinds of businesses (i.e. horizontal) or for a specific kind of business or process (i.e. vertical).

When we need to look something up, we start the application and perform a search. When we need to enter data or perform a task, we go to the application to get something done.

The changing landscape of the user interface

Over the last 30 years, the user interface has changed – both in how we interact with it and where the interaction occurs. We started in the batch world, where humans had to share the hardware. Hardware became smaller and available for personal use, resulting in command-line and graphical interfaces.

Most recently, mobile devices have gained significant market share. No longer do we have to sit as a computer. The computer now comes with us, and can integrate context, such as location, into application usage. However, we have continued to live in a world of the graphical interface, although applications have become more distributed.

Over time, the user interface has become more disconnected from the source of data, requiring a dependence on the network to do our job. We have seen a huge rise in APIs that are correlated to the rise in mobile computing. This is a result of the user interface moving away from the source of the data.

Same APIs, different devices

What hasn’t happened yet is a change in the way we view applications. We still go to an application that is built to solve problems for a variety of use cases, contexts, and people. The application is still pretty generic, all things considered. Designers are required to find ways to ensure that the user interface can accommodate the most number of people possible while remaining useful for the experts – no easy task. This is starting to change, however.

We are now seeing the desire for different interfaces that build upon our network and API-driven world: device-based IoT, voice-command (e.g. Alexa), messaging (Slack with a command-line integration), and agent-based that combines NLP + voice/chat (e.g. Siri, Google Now, and Alexa).

This is breaking the tradition of application interfaces, no longer requiring users to go to a web or mobile interface. Instead, these interfaces are allowing application capabilities to go to where the users are active. And APIs are making it happen.

Enter: Slack

Slack has become one of the most popular ways of doing this, likely due to its considerable growth as a team messaging platform. This chart from Business Insider demonstrates their amazing growth:

Slack’s daily active user growth (via BusinessInsider)

While Slack is being used to connect tribes across business boundaries, it is primarily used for  more effective team communication. Separate channels are used by product teams, marketing and sales, and development to collaborate without interrupting others. These channels may be occupied by employees as well as contractors and vendors to expedite communications outside of the organization.

Chatbots: From Communications to Integrations

Slash commands bridge the gap between humans and APIs, sending the required data and displaying the response (e.g. obtaining current weather conditions by postal code). Some APIs may require a token or API key to prevent abuse of their service, but often that requires a simple one-time setup. Other slash commands may require an account on an existing application (e.g. a hosted Jira account) for the API to integrate properly with Slack.

Slash commands have a specific format or syntax and are best for specific API integrations, often transactional in nature. In the example above, we are using the built-in slash command for adding a reminder. Slash commands don’t monitor conversations, they simply respond to the given command, validate the input, and take action if the request could be processed.

Slackbots are then used to extend the capabilities of Slack by becoming part of a conversation or discussion channel within Slack. Rather than slash commands, they can listen for specific words or patterns and then participate in the conversation. Where slash commands are proactive and require direct interaction by a human, slackbots often are more reactive by responding to the conversation as it occurs. Below is an example interaction from Blockspring’s Weather Slack Bot:

Notice that there isn’t a slash command required. Instead, the bot monitors the channel for specific keywords and then attempts to interact with an individual or a channel based on what it sees. This is a simple example, but it demonstrates what is becoming possible. Things like Slackbots are starting to transform the way we interact with software and conduct business. We are now seeing application interaction move closer to where the humans are solving problems.

Where humans and APIs meet: the job-to-be-done

It bears repeating: We are now seeing the early stages of a transition from users going to the application, to applications going to the user. This is a result of the convergence of several things: Internet-connected devices such as Amazon Echo, conversation platforms such as Slack, and the APIs that extend their capabilities and connect them to external systems. Together, they are allowing user interfaces to meet people where they are getting things done, rather than forcing users to go to the applications to solve their problems.

Applications are most relevant when they meet humans to create and enhance the job-to-be-done. APIs are what make this possible. Applications are only relevant to the job they solve. Today, we see this primarily as a web or mobile application solution. Perhaps it is a device that captures data and summarizes it via a web or mobile application (where the mobile application might even run on a smart watch or other connected device).

With the introduction of platforms such as Slack for team messaging, combined with API-based integration for bots and voice interfaces that support command and natural language, things are dramatically changing. We are starting to see the focus shift from building applications to building capabilities via APIs and connecting them to any number of other applications and devices.

APIs deliver capabilities and context

If applications are most relevant when they meet humans, then the traditional application boundaries become less important. This creates a fundamental shift in the way products are viewed and constructed within an organization. Steve Willmott, CEO of 3scale, expressed this best in a recent interview:

I always feel a little conflicted about the idea of the “API as a product”. On the one hand it feel like progress that the API gets serious product management type attention. On the other, it plays into what I think is a fallacy that the API is a “separate” thing from what the company does. I would say in fact that it is not the case that your API is a product, instead that “it is part of THE product”, and specifically part of the “most important products” your company delivers.

What are your most important products in your organization? They probably aren’t applications. The most important products in your organization are the business and technical capabilities your applications enable people to do that they previously couldn’t without considerable effort. These capabilities can be combined into a variety of applications and integrations based on need, resulting in a customized workflow to complete the job. Rather than viewing applications as a series of use cases and stories with points, applications become the intersection of your capabilities with the capabilities of others into a solution that best meets the needs of your customers.

Believe it or not, your applications are not important. The single most important aspect of your organization is the problem you solve better than anyone else. Applications can be copied. APIs will be duplicated. The understanding, expertise, and insight you provide is unique and valuable.

Your applications and APIs are just the delivery mechanism.

This is the most compelling reason to move toward microservices, as it extends the agility of an organization beyond application delivery. APIs will emerge from one or more microservices that offer business capabilities, that can then be combined into applications.

When we start to build applications with this mindset, our perception of applications will start to change. Applications stop becoming a single installable download. Applications as we view them will become the combination of devices, integrations, and bots that collaborate to produce the necessary user interface and experience to meet the need at hand or the job-to-be-done.

What do companies, product teams, and developers need to do to prepare?

This is the real opportunity for digital transformation in today’s business, not just “going paperless” or building a few partner APIs. Companies that start to view their business and technical capabilities as part of this new wave of applications, made up of bots, devices, and third-party platforms, stand the most to gain from their digital transformation.

So, what can businesses and product teams do to prepare themselves? Five key things:

1. Companies need to focus on capturing their core business and technical capabilities as services, exposed as internal and external APIs. We’ve seen this happening for over 10 years with Amazon, from both their ecommerce and cloud businesses. Now it is time for small and mid-size companies to see their capabilities and unfair advantages as assets as well. Companies must move beyond IT-oriented web services and into capabilities exposed as APIs.
2. Business leaders must begin a top-down API strategy to expose business and technical capabilities to internal teams, partners, and public developers. This was Twitter’s early strategy and it resulted in Twitter apps being built for a variety of mobile platforms and devices that they couldn’t reach with their limited resources. APIs have the capability to impact the business and product lines – beyond partner integration. However, it requires buy-in from the CEO-down to be the most effective.
3. Product teams must reorient their thinking around constructing solutions that are multipliers of their business and technical capabilities. This means thinking beyond applications and into platform and device integrations that meet customers where they are are facing their problems, from Slackbots to Alexa Skills and beyond.
4. Product teams should look for ways to extend the reach of their products through voice, bots, and other integrations. These new channels reach beyond traditional web or mobile applications, opening new opportunities for engaging with customers in a variety of situations.
5. Development teams must learn to construct solutions from capabilities again, either through microservices, lightweight SOA, or modular monoliths. It is time to get back to the “first make it work, then make it right, and, finally, make it fast” often attributed to Kent Beck. We have no problem with the first step, but often miss the last two, short-changing our product and business agility in the goal of going fast and being agile. Teams that are able to find the balance of knowing when to simply make it work and when to make it right and make it fast will have a distinct advantage.

Where is all of this leading us?

Over the long term, I believe that applications will become more situational. In the future, many of the applications we will use may only exist for a limited time, perhaps only for a few months, weeks, days, or even a few hours. Then we will dispose of them and replace them with something else that is more appropriate to our current set of jobs, workflows, or team collaboration needs. Given the right tooling, development teams would no longer bear the burden of developing situational applications, instead focusing their time and effort on services and solutions critical to the business.

Unfortunately, today applications cannot be discarded today without losing data. Alternatively, if APIs are the center of computing, applications become a personalized integration that combines capabilities to solve transient problems. The API owns the data and capabilities instead of the siloed applications. Product managers start to track customer and developer engagements rather than requested features on a backlog. Businesses are able to unbundle and rebundle their capabilities to innovate and engage customers in new and exciting ways. We will get there and in less time than you think – will your company be prepared, or left behind?