Tiempo Talks Episode 3 – Importance of a Solid API Strategy

Enjoy this episode? Subscribe to our podcast on your favorite platform to be notified when a new podcast goes live:

Apple Podcast

Published Mon, 3/30 5:02PM • 17:08


api, companies, services, define, organizations, developers, strategy, decisions, based, created, episode, tiempo, applications, working, users, existing, platform, podcast, important, destination


Perla Gomez, Jorge Gaona

Perla Gomez  00:08

Hello and welcome back to TiempoTalks. I’m your host, Perla Gomez, coming to you directly from my house. That’s right, we are all working from home, so if you notice a difference in quality now you know why that is. In any case we will keep working to bring you the best episodes we can and today we will be discussing the rapidly evolving topic of application programming interfaces. During this episode we will explore why API’s have seen a surge in popularity over the last decade, why it’s important for businesses to develop a solid strategy, and how to overcome some of the challenges you may encounter when developing a plan.

To talk about all of this, we have Jorge Gaona with us. Hello Jorge, welcome to the show. Can you take a moment to introduce yourself?


Jorge Gaona  00:50

Hi Perla, sure, my name is Jorge Gaona, I’m a Solution Architect in Tiempo. I’ve been working in web applications and services, mainly with Microsoft technologies, over the last 20 years.


Perla Gomez  01:02

Wow, 20 years. That’s quite a long time. Maybe you could start our conversation and tell us how you have seen the usage of API’s changed during all that time?


Jorge Gaona  01:13

Well, It has changed a lot. In the late 90’s we started shifting from standalone independent software to applications able to communicate with each other using things like DCOM, RMI or CORBA. 

Then in the early 2000s with the rise of SOAP, we got the ability to communicate systems written using different technologies through a standard protocol, opening the door to architecture styles like SOA to become more popular. 

Fast forward around 15 years, with the cost reduction generated by virtual machines and the emergence of containers, the deployment of independent services on their own infrastructure became really easy. This, in turn, opened the door to the microservices architecture style and the type of applications we see today. For example, we see the use of serverless computing services where you can have an API up and running in minutes.


Perla Gomez  02:16

It definitely sounds like API’s have come a long way since you first started developing software. What do you think has contributed to this surge in popularity over the last 10 years?


Jorge Gaona  02:26

Well, first the revolution of mobile applications that started with the first iPhone created a need for backing services. This created an environment where existing APIs can be used for other applications within the organization. If you open a shopping app on your phone, most likely it’s backed by a similar set of services as the company e-commerce website.

The paradigm shift made companies start offering computing services through APIs, creating a whole new market in the software industry. Long gone are the days where you needed to use libraries to connect to your SMTP server for example to send an email. The development efforts can be much less than having to write all by yourself. Now you can use a third-party API and maybe 8 to 10 lines of code to get it done, including error management, asynchronous processing, error handling, and so on. Do you want to send an SMS notification instead? The same API provider can help you most likely. 

And the same goes for other kinds of services, like identity management, monitoring, and so on. This reduces the undifferentiated heavy lifting for companies to provide value. You can now create a really cool software product faster than 10 or 15 years ago.

Another important benefit we get from APIs is the ease of integration. I remember around 13 years ago I was working on a project where we needed to integrate a homemade point of sale with a big brand ERP. The process was based on text files, so every day we generated a CSV file, copied it into a folder and then a CRON job was responsible for picking it up and get the data into the ERP. We were always a day behind with the sales and inventory information. Having an angry CEO because the process failed during the weekend is not a happy way to start your Monday.

Now you can use APIs to integrate both systems immediately if you want to be able to know if something is not working in the same minute it happens. There’s a lot of value in that for companies that need to make timely decisions.


Perla Gomez  04:54

That’s very interesting, how do you feel this shift is changing the software industry in terms of the models that software companies are built on, and the types of products they are developing? The rate at which they are being created?


Jorge Gaona  05:09

Well, I think it’s like a circle, and it starts with the need to build things faster. Being able to reuse code through APIs reduces the effort and the cost of creating almost any application. 

Now, given the value of this, a new market was created where you can find companies that are solely based on APIs. For example RapidAPI, an API-specific marketplace claims to have “over a million developers and ten thousand APIs.” Anyone can start creating services and make money out of them. A company with an existing software product or service can start making their own APIs available for the public and open the door to new revenue streams.

This in turn makes it attractive for other developers or companies to integrate with off-the-shelf products, as one size doesn’t fit all well. You can find a niche of users that require a customized version and serve their needs with little effort.


Perla Gomez  06:19

Is that what makes having an API strategy so important?


Jorge Gaona  06:24

Yes. Many organizations tend to think of API’s as just individual services. But in order to really provide value, our strategy is required. You need to know where you are now, the place you want to go and what you need to get there. As decision to make in the process gets you farther or closer to desirables not having a strategy is not thinking about the decisions you’re making and not making a conscious decision. Well, it’s also this issue You can start your journey and hope for the best or plan and make measurable progress toward you destination.


Perla Gomez  07:09

So we have established that organizations definitely should have a strategy for their API’s. But how does an organization begin the planning process? What are some of the best practices they should consider?


Jorge Gaona  07:22

I think the most important one is thinking of your end users. And by that I mean the developers consuming your API’s. The same way we think on UX. having in mind that the x which is the developer experience of using your API’s is critical for their success. If developers have a bad experience when you send your brother, they’ll most likely look for an alternative. And it’s the same if they are internal or external clients. API’s are meant to make things easy. If that isn’t the case, while on developers might start avoiding them and writing their own code to get things done, and external developers switch into a competition Additionally, we need to think about the type of decisions we are to make things like language or technology of choice, accepted data types or protocols need to align with our needs. Now the decision piece is crucial because we need to balance manage we there needs to be a clear framework defining the world team members can decide freely provide or challenge choices or even follow the established standards. If a central point makes all the decisions like a CTO or an architect, the evolution can be really slow. But if it makes all the choices, fails may arise if they forget or don’t know the whole picture.


Perla Gomez  08:58

will just say is there biggest pitfall to avoid,


Jorge Gaona  09:02

we tend to think from the provider perspective, it’s really easy for us to create API’s that follow existing business logic or are based on our current data structure. The main question here is, do my API consumers care about this? We need to discover what their goals are, and then define API’s that will help fulfill them. But sometimes complicated, especially for companies that don’t have a past experience to guide them.


Perla Gomez  09:35

And I’m sure there are a lot of companies that have been a little slower to adopt or haven’t quite figured out how to navigate this new territory yet, for these companies. What do you feel is the impact of not having a mature strategy, or even no strategy at all?


Jorge Gaona  09:52

Can I make an analogy? Yes, sure, please. I have a chance to drive from Texas to Connecticut. twice at the time. I didn’t own a smartphone. So I relied on a map I bought on a gas station. The first time I use it a highway that took me through the Appalachian Mountains, it was winter. So the trip even though the beautiful scenery, it wasn’t like the best experience. Then next time we did it, I use the i 95, which is closer to the Atlantic coast. So I call about potentially icy or snowy Howard’s starting an API journey with no strategy is like making the trip with no matter how you may have a compass but the path to your destination is not straightforward. Sometimes you need to go south for some time even though your destination is northeast. Having a bad strategy can take you to dangerous places like driving through a mountain. highway during the winter, you may see the map. But if you don’t know the implications of a specific route, or having experienced it before it can be dangerous for your organization.


Perla Gomez  11:11

That’s very good concept. The road map could really help users to visualize a path to success. let’s get let’s get going with it. Let’s say you started working with a new client that really wants to get in on the API economy or mature their current strategy. What will their roadmap look like? Where will they pit stops along the way B, what terrine should they avoid? And what fraud signs should they keep an eye out for?


Jorge Gaona  11:40

Well, the first is defining the API landscape based on the business goals. Creating API’s that will be used internally only is not the same as defining services that need to comply with our service level agreement contracts. And we then need to consider their goals of the effort, you might be trying to reuse existing companies or maybe make variations within the system easily. Based on this, we start defining the scope or the effort, what parts of the system or what system will be included in this effort, and so on. Then we start designing the API. So what sun does we need based on the specific requirements? Maybe it’s rest, so, Europe, etc, etc. And what programming languages are best suited for the program we’re trying to solve? What are the type of responses we will return? Are we going to report our backs? Then, we also need to define the governance for these kind of decisions. As we talked before, centralized governance is low and fully distributed decision making process can heart more than They benefit. So we need to find the right mix for the organization and the Define goal. Next define how are we going to test the API’s correctly implementation. And this goes from choosing the tools to ensure testing is sufficient to define the source of data to replicate errors in production. Sometimes data can be shared with developers for compiling reasons. So we need to consider that on the test is ready. And then we need to think how are we going to get the API’s to production? How are we going to make the updates? What version is started, you will work best. We must not affect the applications using our API is because we make breaking change. We also need to think how our going to communicate to our users that we have API’s, how do they know that or API exists or where is it located? We need to think about the developer experience. How do we make it easy for developers to use our API’s? It should be a pleasant experience for them even when receiving errors. And finally, we need to think about retirement. All API’s have a defined lifetime. So we need to be sure we are removing API’s that are no longer serving the initial purpose, if you think of it, and you may end up with services that are stale, or no longer be use the surplus of your sources, either technical or human.


Perla Gomez  14:38

What are some particular organizations that you feel have a really solid API strategy right now? Who is leading the picture? And what characteristics Do you think these companies possess that other organizations can use as a template for


Jorge Gaona  14:52

their own success? Well, I must know for sure is one of the best examples. I think it was around 2002 when Jeff Bezos turning around the company technical direction, by asking that all communication between product teams will happen through API’s. Instead of sharing databases or other kinds of resources, service calls were the only permitted communication man. This paradigm change was one of the reasons for Amazon to become a huge platform that in turn trigger multiple business opportunities AWS, including Microsoft is another example. They have created multiple API’s to serve their own needs. On top of that, many of those are available for anyone interested in evidence in their experience on a pay per use model. Do you want sentiment analysis or anomaly detection on your app? Maybe you can write it yourself using something like Python. Or you can call Microsoft Cognitive Services API user in empower and get the results back Both companies share an important characteristic. Even though both have multiple small, independent team working on specific features or business lines, their main goal is not creating individual services. They are thinking about the platform.


Perla Gomez  16:16

That’s really good advice. Okay, great. That is very important for organizations to look at the big picture and think about the platform as a whole. Thank you so much for your insight, and thank you for being on the show today. Remember, I will also like to thank you, our audience. We hope you enjoyed today’s episode. Would you like to see updates for future episodes, subscribe on Apple podcasts, Spotify, Google podcasts, or most of the major podcast platforms. Each episode will also be posted on our website tiempodev.com and each new episode will be announced on social media @TiempoSoftware on Twitter and attempt to development on LinkedIn and Facebook. You can also email us to podcast at tiempodev.com if you have any questions, comments, or you have a topic you would like us to cover next. Until next time, and polygon And you can only send it to TiempoTalks.