API Lifecycle Management

7 Mistakes When Putting In Place An API Program By Francois Lasne


Francois Lasne is a Senior API Manager at Murex. He is also part of the API Thinking Collective. In this article, he discusses common mistakes when implementing an API program.

  1. Underestimating the coordination effect

Launching an API is like launching an API product. An API program is about connecting people as you are launching a product. So, it can be about connecting the top management to the product management, marketing, sales, business architecture, product owner, technical architect, development, documentation and security, teams, etc. In addition, it also requires connecting with billing, finance, and legal compliance. This can lead to problems. A common mistake is thinking that everyone is aligned and understands the strategy. But people might live in silos. So, you need to put APIs between these groups.

Sometimes, people are not aligned because they have not understood the strategy. You also need people to understand that they are part of a process. Disordered execution can lead to delays, and delays can lead to frustration. Examples are a salesperson selling an API that is not fully complete or an architect publishing an API not yet licensed or priced. Any delay could lead to a bad perception; internally, it would lead to a lack of motivation, and externally, it would lead to a lack of customer trust.

To resolve these issues –

  • Have a clear and documented process.
  • Have templates that define the input and output. Have a canvas for use cases, architecture, design, etc. This will make it easier for all teams to understand what the input and output are.
  • Have a dedicated board with all tasks and responsibilities assigned to teams. This helps everyone get the broad picture and detailed tasks.
  • Create a guild or community of experts.
  1. Forget the Customer

Usually, customer needs are very simple, and some companies have understood this very well. Stakeholders’ ideas are usually more complex and do not always fit the customer, and somewhere down the line, we forget the customer. So, the key idea is to keep it simple and keep the focus. We need to understand that the success of an API is not about its complexity but its adoption. So, focusing on the product instead of the customer is a mistake. Another common mistake is disconnecting the business from the API world, thinking it is about tech.

Solutions would be –

  • Modernize the APIs when you build them.
  • Keep it simple
  • Try and partner with a sponsor. You can even co-create them.
  • Publish your APIs as soon as possible. Even if you don’t have the real product, push the mock product out that simulates API behavior.
  • Help build your client application to showcase the API’s full potential.
  1. Thinking that money will come fast

It takes time to build an ecosystem, to monetize the API, and to get financial returns. It will also take time to align everyone and for everyone to understand what you are building. You must factor in the time required to publish the API, market the solution, generate leads, etc.

Try to have a clear business model. Find an early adopter. Validate the business model. Get feedback and incorporate it to improve the product.

Be humble and pragmatic. Start simple and then expand.

  1. Underestimating the documentation effort.

I used to say that API is “What you see is what you get.” The moto was no doc, no app. A mistake here is believing that the client will know and understand your product. You may publish a PDF file for the client to get to know the product, but this does not help the client know the product as he should.

So, create documents that are not technical: document workflows, use cases, endpoints, and details related to those. Put in place API guidelines and ensure that those are enforced. If possible, build a schema library and use it to create reusable components. Get the APIs reviewed by external people, such as your sales team or HR department. Provide a sample application to try and get feedback. Getting feedback is always good.

  1. Underestimating the DevOps effort.

To start, you may have a great idea to develop an API. You may decide to hire a good developer. But it is not `so simple. But the lifecycle is complex. It requires design, development, deployment, networking, and integration with API. API Management is a new and complex tool. But it is helpful, so it is good to master it.

You also need to ensure that you do not have spaghetti code, that versioning is maintained, and that you do not lose traceability.

To resolve these potential issues and mitigate risks, build a deployment policy. Ensure the policy is followed. Automate as much as possible. This will ensure that rules are forced onto development. Let the team that builds it own it so that they feel responsible for the code.

  1. Believing that the API works.

As we develop our APIs, we believe that our APIs work. We test happy flows. Tests are done only during the deployment of the APIs. This makes us believe that the APIs are working fine. It may happen that the API, when pushed onto the server, may not work, and that may be too late. So, have a sandbox in place. Validate and inspect your APIs at regular intervals. Test each deployment. Have smoke testing and deep testing to ensure larger coverage. Inject trojan horses and test. Perform monkey testing with dummy payloads.

  1. Underestimating the security

As per statistics, hackers and attackers have grown by 400%. According to Gartner, 94% of financial institutions have faced attacks in the past few years. Some believe that security needs to be implemented at the API gateway level. If you have an ISO or similar certification, you have rock-solid security. Security attacks pose a risk at multiple levels, operational and financial, and put your reputation at risk. To counter this, establish threat modeling. Be clear about who is handling what security aspect. Perform data flow analysis and put checks where you site security threats. Carry out static tests, penetration tests, etc. Use tools that analyze data, check for potential threats, and flag alerts.

To resolve these seven mistakes, the common thing is to be together. Work as a team, share feedback, and improve on it. Together, we grow stronger and go faster.

Francois Lasne

Francois Lasne

Senior Product Owner Open API, Open Banking at Finastra
During my previous professional experiences, I worked on critical large project (Air military defence, financial risk management, open Banking) so that I have developed competencies in Large system analysis , Legacy modernization , Cloud and digitization transformation. I love working on open API (currently open Banking) , as it is mixing business (Fintech ecosystem , business model) and technical skill (Cloud, security ...). It is a key roles in the organization , that allow me to bring my expertise and to share it with many people from many profile and culture. Every new project is a new challenge ! Strength : #openAPI

APIdays | Events | News | Intelligence

Attend APIdays conferences

The Worlds leading API Conferences:

Singapore, Zurich, Helsinki, Amsterdam, San Francisco, Sydney, Barcelona, London, Paris.

Get the API Landscape

The essential 1,000+ companies

Get the API Landscape
Industry Reports

Download our free reports

The State Of Api Documentation: 2017 Edition
  • State of API Documentation
  • The State of Banking APIs
  • GraphQL: all your queries answered
  • APIE Serverless Architecture