Think about the significance of the Amazon API mandate for a second.
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
- It doesn’t matter what technology you use.
- All service interfaces, without exception, must be designed from the ground up to be externalize-able. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
- The mandate closed with: Anyone who doesn’t do this will be fired. Thank you; have a nice day!
Instead of telling the humans which technologies to use, Bezos defined only the outcome of departmental systems deployments. These platforms became a network of business units that were integrated through the flow of data and information. From a software architecture standpoint, loosely coupled systems, data and software became re-useable across apps and departments. From a business perspective, Amazon has the agility to launch relentless attacks into new business domains at will.
If you are reading this and grabbing for an airsick bag because your company doesn’t think this way, know this; however complex your internal systems, moving your company toward an Amazon model will evolve from simple systems with an API that works. Because complex system designed from scratch don’t work anyway, you can avoid the massive systems commitments of the past, and find a way to start small and build on success.
APIs are the new web sites, and most companies need more than one of the following:
Private API — Companies use private APIs to make internal functions of a business run more smoothly and to accelerate innovation. In the Amazon model, humans made their technology selections as close to the user as possible, with the mandate that those systems, data and workflow were accessible to all other departments via a well-documented API.
Public API — Companies use public APIs to selectively expose the very same services, content or data a company uses itself. This is motivated by a calculated understanding that the platform can ultimately offer something of value to those outside the organization. A mark of successful public APIs is their ability to inspire and cultivate apps from newfound developer communities that expand brand, distribution and revenue opportunities. The faster the data can be accessed and processed, the faster its value can be extracted and gained.
Partner API — Many companies will offer a partner APIs that are open beyond the organization. These services are not entirely exposed publicly, retaining security and data control. Accelerated B2B dealings can produce large revenue and mutually beneficial data exchanges by spreading assets to established services with pre-existing markets with little incremental strain on internal resources.
Simple, right? Every system you have needs to be able to communicate internally, with customers and with partners. But if you’re like most companies, you’re running on an amalgamation of disconnected systems that likely include spreadsheets, databases, email, and other functional applications that may or may not be API friendly. If this is the case, where do you start?
It is for this reason that Slack has become an overnight sensation. Not only did the folks at Slack turn messaging on it’s head, they’re also making it easier for companies of all sizes to get their feet wet in API-land.
Slack took messaging, which was human to human, and moved it to topics-based messaging (Slack calls them “channels”.) So all messaging related to a topic, whether the topic is a prospect, a project, customer or partner, happen in the same place. For companies who need a fresh start, it’s hands down the best place to start. For zero money, company humans can create their own teams, identify the common work topics, and connect new humans to teams on the fly. Individually, people can elect to connect other applications and notifications to their Slack feed to keep all information flowing in one place, everything from Google Mail and Calendar events to Hacker News. With a capable developer, companies can create custom commands that drive information into back end systems that haven’t gained the adoption they might have liked.
Just as Bezos re-imagined how company systems should be designed 13 years ago, Slack has created a new purpose for an application as it has quickly become the universal user interface to the cloud. In the process, Slack has solved the bubonic plague of systems implementations … lack of user adoption.
So if we start there — coordinating your entire company around a simple, flexible, searchable, connected messaging interface — we have a foothold into what it means to work in an API ecosystem. Because the users are engaged in driving data into the same interface, the challenge moves from vendor selection to a more functional definition of how to support the data and workflows that result from the natural collaboration in Slack. Now, business platforms becomes more Amazonian — selecting or creating systems that interact easily with others, focusing on function vs. vendor, and avoiding the lock-in and expense of massive company platform deployments whose outcome is typically a demoralizing march of failure.
The API economy means economic prosperity for companies who embrace the challenge of technical transformation to become digital competitors.
Disclaimer: Grace is the CEO of SLINGR.io, an API-first rapid application development platform with an emphasis on driving workflow across connected third party applications. Competing with “out of the box” CRM solutions like Salesforce and SugarCRM, SLINGRPro connects disparate apps and data source to automate and orchestrate without centralizing workflow..