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 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. 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, 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. If you want to expose it using a developer portal or even a service catalogue, 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. You’ll also get the effects of the fact that business development, partnerships, and being able to create customizations for your ecosystem will be slowed down because those public APIs don’t exist yet and 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 weren’t yet available. The actual organisation had to decide how to gracefully balance the fact that they wanted to publish official APIs, and work with the development community to take down those non-sanctioned APIs. 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.
Assumption two:
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. If 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 get the jobs 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 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 or an 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. You have to map the data fields. It also 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, repetitive tasks, and you miss out on the very strategic ways that would enable you to get there faster. All of that technology exists but getting there first and getting the first mover’s 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.
Assumption five:
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 and 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.
Stories and ideas:
There exists a piece of silicon that was designed and produced and created physically back in the early 2000s that, depending on how you write about its capabilities for reuse and scale, could be marketed in different ways. It 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, especially knowing that we do have a chip shortage in the world right now. Bearing this story in mind, I created a construct that’s basically a very high level of abstraction of what I call the code spectrum. And as mentioned, I’m working with full API Lifecycle Management, 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 are components of Low and No-Code capability, where you can drag and drop and are 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. There are so many different interfaces that just physically and digitally don’t talk to each other. I created the framework of the track spectrum to help companies solve a couple of questions. Here is an example: For Low and No-Code, the value 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. 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. Canva offers content, editing and publishing capabilities, right in the form of extensions. They also have something called “Design with Canva” and partnerships if, 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.
Key Takeaways:
The tone may be 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. Not 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. It will make your customers happy and that’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. 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.
Q&A Section
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.
