It was not long ago that I was very likely in your shoes at a company that builds software to manage APIs integrations, and the next product platform and its associated APIs. Currently, I oversee full lifecycle API Management, integration and Low-Code independent software vendors who sell their software products and services through the AWS marketplace. So first, I’m going to cover five assumptions that you can use in your organisation to help you assess whether or not API strategy is a first class citizen. So, when an API strategy is a first class citizen, that’s when things are going very smoothly, and you’re able to achieve better customer results faster and there’s basically a lot less friction. So these five assumptions have both up and downstream effects. So I’ll be sharing real world examples of what happens from a human psychology standpoint, when you hold these views and choose not to keep API strategy as a first class citizen and just as an afterthought. So, for the first two assumptions, here’s some of what I’ve heard, when I worked at software companies and enterprises and organisations across the board, as well as from consulting clients when I was an independent API strategist.
Assumption one: I can just skip the public APIs, creating them and publishing them, since developers aren’t using my product yet. Assumption number two, my private APIs are just good enough for internal use, since the end users have a software UI. So what happens when we think in this way? With the first assumption, here are three up and downstream types of symptoms that help you as you score, whether or not you’re treating your API strategy as a first class citizen. If you skip thinking about public APIs, here’s what happens. Say you get to a point where the community and your customers and your partners really want to be able to use part of your data or functionality in their products or platforms. Say you want to expose it using a developer portal or even a service catalogue. What happens is if you were only focusing on an internal APIs, now you basically have to comb through the backlog and understand all of the dependencies that you’ll need to deal with. The other thing that’s really tricky is if you’ve got an internal product backlog that basically competes against your public API, then that’s another piece that’s very difficult to balance. Finally, retrofitting security is incredibly painful. Whereas if you design with security in mind, even when the API is a private or an internal API, then it’s a lot easier to expose the external or public version of the API when you’re security-minded in your design. Then you’ll also get the effects of the fact that business development, partnerships, and being able to create customizations for your ecosystem, what happens is, you basically lose speed, because those public APIs don’t exist yet. And, you know, having them rise to the top as a priority is very difficult. Also, you have the case, right back in 2013, where we saw that a development community may just try to build an unofficial or non-sanctioned API, since the official ones aren’t yet available. What happens then is the actual organisation will have to decide how to gracefully balance the fact that they want to publish official APIs, and work with the development community to take down those non-sanctioned APIs. And then, the other case is, you’ll have a successful company that has built their own business model on the fact that they’re writing scripts, scraping interfaces and grabbing data from publicly available sources where again, it’s not the official API. For the second assumption, my private APIs are good enough for internal use, since end users have a UI. If you have an internal team that’s using your API to create custom integrations, because your customers rely on you to do those, now that customer is integrated with your API, and if that API is updated, then the internal team needs to know. And because the customer is integrating, and using the private APIs in production, that traffic is easily found and so it’s really no longer truly an internal API. The other piece that’s really interesting as a downstream effect is unanticipated end users. If the private APIs are just being used inside, then externally, it can’t be done. Say you have some customers with very sophisticated analytics, they want on-demand real time reporting, and capabilities that are very systematic and programmable. When you don’t have a public API, then it’s very difficult for them to be able to achieve the jobs to be done. Finally, if you just have a UI, think about how many portals you have to log into today. Anytime you have context switching… that reduces productivity!
Assumption number three: End users interact with my product via the UI so I don’t need to spend time on API design. You can see these assumptions are very different, but in a very granular way. And here’s what happens when a company thinks this way or organisation thinks this way. From an integration standpoint, if there isn’t intelligence in your integration platform, the architect or the organisation has to really understand the two or the multiple, different APIs that you’re integrating with to where you have to map the data fields. And it often takes quite a long time to learn a new API, especially if they’re from companies that have very different business models. So think about the fact that you might have Workday, HubSpot, Marketo, Salesforce, these kinds of connectors that we typically see in integration platforms. You have different styles of APIs and it’s very difficult to basically integrate quickly. The other piece that’s very interesting is just because there isn’t a cost to access the API, it’s not a direct monetization model. If you’re actually integrating with that supposedly free API, how critical is that free API to your actual core business model as well as your business performances? If that API is down, how is it going to affect you and your customers? The other piece that I’m definitely not doing justice to is basically architectural mismatch. We need to find ways to repair, detect and avoid interface mismatch. So when I mention this, it’s basically talking about the components in context. Whether it’s runtime or rather, whether it’s during the integration, what happens is that, contextually, the APIs don’t match, even if you compile the code and it runs.
Assumption four: Integration with the API is too difficult and automation value is tough to capture. I.e you have a very influential leader where they have to decide whether to use precious Development and Engineering resources on the product itself, or to be able to do a third party integration or to expose APIs for the greater ecosystem. You’re competing with different priorities, scope, ROI, and key performance indicators. And basically, you have a job to be done and you want a quick fix. And so you think “let’s just try to avoid doing that”. From a human perspective, you’re then really missing out on automation that removes undifferentiated, heavy lifting, so repetitive tasks, and you miss out on the very strategic ways that you could be able to get there faster. So all the concepts that Mike covered in his keynote, who is going to get there faster? Because all of that technology exists but getting there first as the first mover advantages is just as important as network effects. Finally, new motions of doing business mean that, as an organisation, you need to adjust the human psychology to find new ways for product adoption, and to reach your end customer basis, we all get more sophisticated. If you don’t have the automation that you need to scale everything, then you won’t be able to build that sort of flywheel effect.
We’re almost done with the assumptions. #5: So creating an API is very difficult and expensive to maintain. Let’s just do it later and work around it using what I call duct tape. So things like spreadsheets, emails, anything that’s untrackable, auditable, maybe it’s just on your desktop? To say, Oh, well, I really want to get something done quickly. Therefore, organisations continue to become more siloed. And it’s very difficult because that piece of information does exist, but you just don’t know where to find it. The other issue is, leaders really find it hard (if they’re a really data driven organisation) to be able to capture the value that the team is delivering. And when you have that delay, then it’s tougher to communicate that internally, as well as get the kind of thought process that you need to build what you need and expose it to the outside world. Thus, this particular assumption is also very detrimental, because most companies have retention policies, all software and hardware have an end of life. It’s not just about tools that you can use either, it’s within an organisation to reduce any sort of shadow IT or to mitigate it all together, you want to lock things down to more secure ways of collaborating. So how can you solve, using reuse and scale, being able to build and test it and run it everywhere? I’m going to tell you a story from the early part of my career. I was in grad school, and I was very grateful that I was studying technical communication, while I was also working as a tech writer. And so what’s really interesting, and especially paying homage to the fact that we do have a chip shortage in the world right now, is the fact that one piece of silicon that was designed and produced and created physically back in the early 2000s could be marketed in different ways to create and design wins in an OEM so for example, this one piece of silicon, depending on how you write about its capabilities for reuse and scale, could be used in a NASA spaceship, in a car, in a phone, in a computer, in a smart home, but it was just one piece of silicon. And so to me, that’s really interesting, because it’s all about the context that you’re working in.
So I created a construct that’s a little bit different to the dots and the loom that Mike talked about in the keynote, but basically, it’s a very high level of abstraction of what I call the code spectrum. And as mentioned, I’m working with full API Lifecycle Management, iPads, as well as Low and No-Code ISVs. And the reason why that’s important is, if you think about integration platform as a service, it typically contains API Management and integration, which includes data integration, API integration, application integration. And then usually, there’s components of Low and No-Code capability, where you can drag and drop to be able to abstract yourself from the code. However, if you do need to access the IDE within the Low-Code environment to troubleshoot, you can, in certain circumstances where you need to. So the reason why I created the code spectrum is because currently, we’re in a state where we’ve got interface mismatch. So you might have an Alexa device, or a phone or slack or a web browser, or 10 different portals where you need to log in just to be able to talk to someone, and then there’s multi factor authentication. And there’s so many different interfaces that just physically don’t talk to each other, and then digitally also don’t talk to each other. And so the reason I mentioned that is, I created the framework of the coach track spectrum, to help companies solve a couple of questions. So I’ll give you an example. So for Low and No-Code, the value, I think, isn’t really in the fact that there’s a user interface that abstracts you from the code. I think the real value of Low and No-Code is the fact that you can have more accessibility and people can contribute to an application or build a new application from scratch, without affecting the back end architecture and creating more technical debt. And so the reason why that’s incredibly important, is that, when Serverless was initially launched, many people were asking if DevOps practices could still apply? And the answer is yes. This code spectrum basically helps you focus more on what you’re trying to solve, and how much code you need to be able to access. And I’ll show you a real example to better illustrate what I mean. So we’re gonna play a quick, fun local game. I’ll give you two sets of clues. Can you guess which Australian ISV was founded in 2013, is based in Sydney, has 55 million monthly active global users across 190 countries in 100 languages and was valued this year, in April of 2021 at $15 billion US dollars? The next clue is that they do have an API and a developer portal, so that the community can create smart integrations and powerful apps. They have multiple databases that run upwards of three terabytes of data. And to the point in the keynote, this particular ISV is aiming to be available to the 3 billion internet users in the world with an eye on accessibility to every culture. And they’re being used very prevalently in Brazil and Indonesia, for example, where there’s quite a bit of population and emerging cultures. If you guessed Canva, you’re correct. 100+ designs are created per second. And today, users have created over 5 billion designs. It’s just such an amazing example of a company that, whether you’re non-technical and you want to create designs, or you’re a developer and you want to be able to make designing available and what you’re trying to build for more customised experience, you can do that.
So let’s go back to this code spectrum framework to see what I was talking about. You can see that Canva offers content, editing and publishing capabilities, right in the form of extensions, they have something called design with Canva button. They also have partnerships (for example, you’ve created a digital book, and you want to be able to work with third party companies to make it physically available).
Going back to some of the key takeaways of what we covered in the section about Go to market with APIs. You’ve learned five ways, right? Probably the tone is a little bit cynical, but I wanted to be very real because in this day and age, API strategy is very difficult to push up to be a first class citizen, like it is at a company that’s cloud first and all in on AWS, like Capital One. And so making a first class citizen, having an API strategy means that there’s both up and downstream effects that you definitely have to make your company aware of, and carefully look at each of those effects to basically prevent them and just prevent pain right down the line. The reason why you want to do that in a positive, non-cynical way is that you tend to delight your customers, your employees and your partners, which is really important. That’s because whenever you have a delightful experience, you tend to remember it really well, even though a negative experience tends to stick with you deeper. Yet, if you can delight someone, it’s really key for retention. I provided a real life example of an ISV with a very successful platform like Canva, that also has a UI that’s accessible and developers can also use it. They’ll continue to march towards adoption of 3 billion users. I also introduced the framework of a code spectrum and why it’s key to explaining that Low and No-Code interfaces still mean that you want to start from the beginning and design your API properly. At Amazon, we basically have a concept called one or two way decisions. And it’s very interesting to see your thoughts of whether or not you think APIs are a one or two way decision, meaning is it reversible? Or is it something that you can continue to try and iterate on. The reason I introduced this sort of framework is that the six most successful business outcomes are really going to include automation capability, and faster integrations that are only possible through APIs, as well as detecting and fixing that sort of interface mismatch that I talked about.
Finally, I would like to dedicate this talk to all of the consulting partners and independent software vendors that make my role at AWS marketplace amazing. There are 50 other category leads like me, who manage across different categories, as well as industry verticals. I also just wanted to highlight a few of the folks that I have had the pleasure of talking to who are part of AWS marketplace today. I recommend that you find their product listings on a diverse marketplace and take a look. Some of them have free trials, or you can click to subscribe to see them on your AWS bill. If you’re an organisation or if you are in procurement, then you may want to contact them directly to do what we call a private offer. And then another type of private offer that’s available is also with system integrators and global system integrators. So thank you very much, I hope you have a great conference.
Q: We can just have a quick conversation around, in particular, how you address businesses in terms of making the business case, to establish the market place and start putting in these kinds of capabilities that you talked about, especially for organisations who might be a bit more project centric in the way they approach their funding. Because this can be a strategic capability that needs to be nurtured, and led over time over different programmes of work, and just any insights you might have as to how you approach it.
A: Absolutely. So AWS marketplace is a global team. And so the reason I mentioned that is that it reaches people both in a self service way and also in a very high touch strategic way. There are over 10,000 listings on AWS marketplace and there’s 1000s of ISVs and consulting partners. We basically tell a new marketplace seller to focus on exactly what it is as a company that they’re trying to achieve, and then basically, they can use AWS marketplace as their go to market vehicle. Every AWS customer, anyone who has an AWS account, could click to subscribe, right? So there’s almost no barrier of entry there. Nevertheless, for a consulting partner, or an ISV, to be able to offer products and services, it does require an API integration. It’s very simple, at the time of writing, currently, it takes about two days, depending on the type of listing. However, the way that you would justify or prioritise that product to the front, is to work like a head of sales, because marketplace also uses that high touch sales motion that I touched on earlier, when we talked about private offers, and it’s basically that, as an ISV, your Field Sales just to go to negotiate to deal as they normally would. They then basically put the terms of those deals on the back end of the product listing. This is software, basically, it’s the AWS marketplace management portal, and the customer accepts that private offer. They were probably going to purchase your product anyway, right? Or maybe they’re just now discovering your product, and if they don’t want their 1000s of employees just to click to subscribe, what they want is for the organisation to have governance, and to reduce risk, in a way to reach right sanction software within the company. And so meaning, it really depends on the ISVs particular strategy, what they’re trying to achieve? Is it $10 million gross software sales, annual revenue recognition every year? So it just depends on what that ISV is trying to do. And they can basically be as hands on as they want. If they want to be very self-service, they can do that. Say it’s a developer that wants to create a listing, they can! But if it’s a massive enterprise, and they want to be a part of marketplace, they can as well. So it’s all about scale.