Third-Party API Economy.

The Third-Party API Economy
Image: Grace Isford

How to Give Your Users Superpowers

Application Programming Interfaces, or APIs, thrive and give companies an edge for focusing on very specific issues. While the pattern has been around sind the early 2000s, the ecosystem only started to develop this rapidly recently.

Only to make an example, Twilio started their service as an API only offering. The problem the company solves is basically notification. On all channels, mainly texting and calling. Which by itself is pretty complex, compared to what the involving party actually wants to achieve. Twilio is wrapping this functionality to allow their customers take advantage of telecommunication.

Grace Isford made an effort to classify vendors in the market, that follow similar patterns. The criteria for the selection in his chart are:

  • The product reduces complexity
  • The company provides Business Critical Functionality
  • It takes advantage of a technological shift
  • And finally a community factor

The entire sector is currently exploding and it’s difficult to keep track. Specialised services, consumable through Web-APIs become a commodity for at least developers. Grace Isfords chart gives a good overview of the current situation, along with some criteria to consider the offering.

Source: The Third-Party API Economy. How to Give Your Users Superpowers | by Grace Isford | Sep, 2020 | Medium

Going all-in on AWS is a recipe for success

Gousto believes going all-in on AWS is a recipe for success, diginomica writes, and it’s undeniable there is no way around public cloud for digital services & offerings. It’s a pretty steep thesis to build a strategy relying on one particular hyper-scaler to make a business a success. In the end, customers purchase experience and not technology.

Yesterday, a software engineer, also new to the organization, roughly told me the following. The way the organisation plans projects is so different to what he is used to as a software engineer. Planning projects with a horizon of 12 or even 24 months is something he says he just cannot wrap his head around.

While this is very common and necessary in the hardware industry, it is indeed something terribly alienating software people. Software is typically treated as a living product, that takes tiny changes at a time, it is more governed towards a direction to take than having the one exact goal it has to hit by a specific date.

These very fundamental goals both mindsets follow make it difficult for change to happen. While the software engineer above obviously has a point to make, he cannot reach the people he needs to reach, because both sides are just too far apart.

At the same time, I don’t yet have an answer to the problem, but the problem itself became so obvious when this colleague told me he just doesn’t know what to say. The digital world does not yet have a common language, not to mention a common way to think about approaching problems, and unless this hurdle is taken, change will only happen slowly.