APIs - API First Strategy - Why startups build products than Platforms ? Why not API Management ?

Many startups already realize the value of APIs & follow API-first strategy to connect Mobile APP (Not APPs) to their backends using APIs integrated tightly with their server code. When it comes to API Management they fail big time due to hardly coupled APIs with server-side business logic.

What do you think about these architectural patterns ? Why do startups need to invest in API Management from day one ?

Solved Solved
1 3 944
2 ACCEPTED SOLUTIONS

Not applicable

Believe its because when they start their business they forget to separate the business /API packaging logic to the underlying infrastructure. The reason for this being simple architecture to begin with which eventually grows and innovation /replenishing demand grows exponentially in a short span of time. Success of a program cannot be a surprise. So using agile tools early on to intelligently plan the continuous investment will help them extrapolate the medium /long term target volumes accurately.

There needs to be a long term vision and organisation culture that needs to be seeded and continuously evolve. Lack of either of this ends up with a surprise bottleneck around APIs as you suggest. An good complete API management solution can promote the above.

View solution in original post

bkirschner
Participant I

Great questions and great answers.

I think one motivation for start-ups not going API-first from day one is a sense they need to rush "fast and cheap" to get that first app to market, so a really cleanly separated API layer means "an extra step."

Only I'd say that's 100% the wrong way to look at that first app: the fact is that most start-ups learn as they go what their highest and best business strategy will be. Odds are pretty good that first app or third feature or second app may tell you something you didn't expect.

For start-ups, I think its super important to think about APIs as options. An option (in the classic sense) gives you the right but not the obligation to buy or sell something in the future for a price fixed in the present.

For a small marginal cost in time/effort at the get-go, a start-up buys an option to adapt at essentially "no cost" in the future. This is relevant to two pretty likely scenarios:

One, any start up worth their salt today is making the most of clouds (plural chosen deliberately), Who can predict the options for XaaS back ends in the next 2 years, never mind the next five? Being able to swap backends without refactoring apps is a valuable options.

On the flip side, what if your best business model strategy turns out being a headless API called by a bot? Or Alexa? Maybe the "app" isn't where the value will lie as the market evolves. You want the ability to swap your front end out as well.

(If I were a start up all in on APIs I'd make sure to emphasize the optionality to funders...:) )

View solution in original post

3 REPLIES 3

Not applicable

Believe its because when they start their business they forget to separate the business /API packaging logic to the underlying infrastructure. The reason for this being simple architecture to begin with which eventually grows and innovation /replenishing demand grows exponentially in a short span of time. Success of a program cannot be a surprise. So using agile tools early on to intelligently plan the continuous investment will help them extrapolate the medium /long term target volumes accurately.

There needs to be a long term vision and organisation culture that needs to be seeded and continuously evolve. Lack of either of this ends up with a surprise bottleneck around APIs as you suggest. An good complete API management solution can promote the above.

Not applicable

To add to Sesh's answer, I totally agree that a long term vision needs to be identified.

It is very easy to fall into the trap of keeping the same business logic since "if it ain't broke, why fix it?". APIs are a new venture for a lot of companies so they naturally want to start with something familiar rather than take the big leap from the get go.

It is also common to see plans of having the API follow the backend logic at first with the eventual goal to improve them over time. However, this could be risky as tying the API too closely with the back end may limit the flexibility of iterating it in the future. It's important to remember that making big design / functionality changes to an API is a lot more difficult if that API is already in Production and being consumed so some forward thinking thought needs to take place.

bkirschner
Participant I

Great questions and great answers.

I think one motivation for start-ups not going API-first from day one is a sense they need to rush "fast and cheap" to get that first app to market, so a really cleanly separated API layer means "an extra step."

Only I'd say that's 100% the wrong way to look at that first app: the fact is that most start-ups learn as they go what their highest and best business strategy will be. Odds are pretty good that first app or third feature or second app may tell you something you didn't expect.

For start-ups, I think its super important to think about APIs as options. An option (in the classic sense) gives you the right but not the obligation to buy or sell something in the future for a price fixed in the present.

For a small marginal cost in time/effort at the get-go, a start-up buys an option to adapt at essentially "no cost" in the future. This is relevant to two pretty likely scenarios:

One, any start up worth their salt today is making the most of clouds (plural chosen deliberately), Who can predict the options for XaaS back ends in the next 2 years, never mind the next five? Being able to swap backends without refactoring apps is a valuable options.

On the flip side, what if your best business model strategy turns out being a headless API called by a bot? Or Alexa? Maybe the "app" isn't where the value will lie as the market evolves. You want the ability to swap your front end out as well.

(If I were a start up all in on APIs I'd make sure to emphasize the optionality to funders...:) )