When people and companies grow wildly successful, we often forget that they have the same number of hours in the day as everyone else. Yet, we often find ourselves speculating, how do they do what they do…and how do they do it so well?
For Amazon, the answer might not be so clear-cut to the everyday user. Yes, Amazon’s CEO Jeff Bezos is a visionary and fearless leader. However, his company–as big as it has grown–seems to change, bend and release new products and services faster than everyone else. How is it possible?
I believe Amazon’s transformation from an online bookstore to one of the world’s most successful internet companies started in 2002. More specifically, when Jeff Bezos issued the infamous Bezos Mandate to his internal development teams regarding how software was to be built at Amazon:
- 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 interprocess 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 they use. HTTP, Corba, Pubsub, custom protocols – doesn’t matter. Bezos doesn’t care.
- All service interfaces, without exception, must be designed from the ground up to be externalizable. 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.
- Anyone who doesn’t do this will be fired.
The mandate was key to Amazon’s success, and it was undoubtedly triggered by the rising cost of teams within Amazon not having consistent and well-managed ways of exchanging data and capabilities between each other. Given this was drastically slowing down Bezos’ big plans, he realized they needed a new approach if his company was going to be agile and drive innovation through technology. The mandate outlined this different approach that required IT to scale its technology assets with APIs–externalizable services–so the broader organization could independently reuse and leverage the assets to drive business outcomes. Essentially, Amazon created its own internal API economy.
Establishing internal API economies can help businesses change the way they operate by empowering more technical employees to connect, discover and reuse IT assets. The goal is to enable self-service channels for accessing data that’s required to do anything from reporting and analytics to building new apps to creating and modifying processes–all without breaking IT along the way. This self-service access to data and resources enables more developers to complete projects faster, increase operational efficiency and deliver new customer experiences, while IT can focus on the bigger, more strategic initiatives.
Of course, if you are not Bezos, then you need to soften your enforcement of the mandate to govern with a carrot not a stick. However, that doesn’t mean your mandate can’t be as effective. Here are six key steps to get started so you can have your very own Bezos moment:
1. Acknowledge your IT blockers
Are you saying “no” to your business partners more often than you’d like? Are you running breathless on a project treadmill rather than focusing enough time on the bigger challenges? As software proliferates every corner of the enterprise, IT is often crushed by project demands from business users who require applications and data to be always available and always connected. As a result, IT often bottlenecks the business trying to deliver all projects themselves.
To keep up with demands, it’s time for a different approach that shifts your mindset to delivering reusable, self-serve APIs as part of standard project delivery. Just as Amazon did, these APIs can be discovered and reused by other teams across your business and provide the only way going forward for teams to exchange data and capabilities.
2. Set up your API strategy and IT delivery model to enable self-service
It’s important to define an API-led strategy for connecting your applications and data. Every time you need access to one of your core systems, you create an API for the data or capability so that the next time it is needed, the consumer uses the API. You start small with your first project. A project may only expose one, two or maybe three assets. The delivery of this project puts your internal API strategy into action and helps build out the delivery pipeline for creating APIs. Don’t turn this into a large architectural project. The initial team should be small, focused on getting a couple projects under their belt and evangelizing these successes.
3. Educate your team and the business on the benefits of self-serve APIs
Chances are you and your team may already be going down this route. In a recent MuleSoft survey of 951 IT decision makers (ITDMs), a growing number of ITDMs indicated they are implementing APIs to integrate new software with existing systems and applications (60 percent), to increase speed (57 percent), and to unlock existing data silos (54 percent). And of those with an API strategy in place, 94 percent credit it with allowing them to deliver products and services faster.
However, to your business stakeholder, the term API may just be technical jargon. Invest time in working with your partners in the business to understand the value of this strategy and how it will help drive agility and innovation. The benefits of self-serve APIs (i.e., unlocking key enterprise assets and making them self-service) are not obvious if you haven’t had them before, so it’s critically important to keep educating your stakeholders, your team and your consumers.
4. Make it easy for your consumers to use and adopt
The point of shifting your delivery to reusable assets is to get a broad range of consumers–not just your core IT team–to use them on their own without needing IT. This is critical, yet almost all IT organizations don’t have people who are employed to make sure consumers can find, use, access and be successful using an API or template. This is new for organizations. The key things to consider here are:
- As part of your API strategy, you need to design the consumer experience. A standard way an API is presented to the consumer is with tools for trying APIs out without having to jump through hoops.
- You need a single place for your consumers to discover and browse assets available to them, as well as to provide feedback and connect with other consumers.
- You need a small team that’s responsible for helping consumers to discover and get help using an API or template.
What you are doing is building communities around your assets. Those communities provide feedback to IT and will often help fellow consumers when they get stuck.
5. Identify KPIs to measure against
Given how many companies are going through digital transformation, there is very little measurement going on. When IT shifts to delivering reusable, self-service assets to enable their business to be more agile, there are two types of KPIs to measure:
- Production KPIs to measure delivery capability. Project delivery speed is useful, but it’s better to break it down into the modules you are building. Starting to measure how long it takes to build an API, microservice or integration will give you better insight into any bottlenecks and where to invest. Also, measuring quality of individual components provides clearer signals on where it can be improved. If you are already running small agile teams, the goal should be to baseline your key production metrics so that you can measure cohort performance. This is important to invest in the right places and can also be used to gamify delivery.
- Consumption KPIs to measure how much leverage you are driving from your assets. One of the most important metrics for an API is how many consumers are using that API. This metric directly correlates to leverage versus the effort put into building and maintaining the API. Developer engagement is also important to measure: How many developers have access to your assets versus how many are using them? Which of those developers have been enabled to discover and use your API assets? These metrics give you good indications that your APIs are working or you need to invest in improving the asset or your internal enablement. Consumption KPIs are critical when building an internal API economy and shifting IT up a couple of gears.
6. Hold your teams, vendors and partners accountable
By mandating that your team unlock data and automate processes through self-serve APIs, you can significantly remove IT as a bottleneck and empower the entire organization to self-serve IT. Driving an internal API economy allows IT to securely open up legacy systems and free business-critical data that the wider organization relies on to achieve business outcomes faster than competition. Use KPIs, like the ones above, to align on what’s important and to set targets (and owners of those targets) beyond getting a project delivered. Then use those targets to measure progress monthly or more frequently. The point here is to have real conversations around data without biases or beliefs to get to your outcomes.
Innovating at the edges never really works if an organization’s core systems are locked up. In 2002 Bezos realized this and transformed the core of Amazon by making sure every team communicated through APIs, which he described as externalizable services. I can’t help but draw a strong relationship to the Bezos mandate and the launch of AWS in 2006. And given the staggering rate of new services offered by Amazon, it proves that if you can move quickly at the core, you can move significantly faster at the edges.
This article first appeared on CIO.com.
