Upgrade to Pro — share decks privately, control downloads, hide ads and more …

INTERFACE by apidays 2023 - Battle-tested APIs,...

INTERFACE by apidays 2023 - Battle-tested APIs, Jean Burellier, Sanofi

INTERFACE by apidays 2023
APIs for a “Smart” economy. Embedding AI to deliver Smart APIs and turn into an exponential organization
June 28 & 29, 2023

Battle-tested APIs: Tech and Business working together
Jean Burellier, Tech Lead Platform Team, Sanofi

------

Check out our conferences at https://www.apidays.global/

Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8

Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io

Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/

apidays

July 11, 2023
Tweet

More Decks by apidays

Other Decks in Programming

Transcript

  1. @shepsheplu But when we think about APIs this is always

    a technical point of view. • How is the API working ? • What technology do you use ? • Which cloud architecture ? ⚠ Never as a business opening solution.
  2. @shepsheplu Jean Burellier Team Lead Platform @ Sanofi Professor @

    Supinfo Open Source Contributor @ Node.js ~ 👪 󰳓 ✈ 🥘 ➢ @shepsheplu ➢ sheplu.bsky.social ➢ github.com/sheplu
  3. @shepsheplu - Did you say API ? - Changing the

    world - but first the mindset - Bridge between Business / Engineering
  4. @shepsheplu Vision of APIs Today, both humans and machines are

    consuming data. Humans consume data through applications, often from many different devices • Smartphones • Laptops • Tablets • And desktops
  5. @shepsheplu Vision of APIs But for companies APIs are mostly

    unknown to the majority of the people. An API is not a product it is only part of a more global - and most of the time - a visual product • We need an application to create a contract • We need to sign a pdf online • We want an internal social network
  6. @shepsheplu Vision of APIs APIs is always hidden behind some

    complexity - yet this is the core of your system Remove the API part and everything collapse. • You can have an API without a frontend application • You can’t have a frontend application without APIs
  7. @shepsheplu Vision of APIs APIs is always hidden behind some

    complexity - yet this is the core of your system Remove the API part and everything collapse. • You can have an API without a frontend application • You can’t have a frontend application without APIs
  8. @shepsheplu Vision of APIs APIs is always hidden behind some

    complexity - yet this is the core of your system Remove the API part and everything collapse. • You can have an API without a frontend application • You can’t have a frontend application without APIs
  9. @shepsheplu Vision of APIs APIs is always hidden behind some

    complexity - yet this is the core of your system Remove the API part and everything collapse. • You can have an API without a frontend application • You can’t have a frontend application without APIs
  10. @shepsheplu So APIs are the core of your company, it

    IS the core product. Everything else is only a mean to display some items.
  11. @shepsheplu Changing the world - but first the mindset What

    is API First ? • APIs are treated as “first-class citizens” • An API-first approach involves developing APIs that are consistent and reusable • Establish a contract for how the API is supposed to behave ◦ Involves spending more time thinking about the design of an API ◦ Involves additional planning and collaboration with the stakeholders
  12. @shepsheplu Changing the world - but first the mindset APIs

    allow companies to break down capabilities into individual, autonomous services (aka microservices) An API-first strategy allows organizations to build APIs that serve all applications, and applications can be developed and maintained efficiently for all devices, platforms, and operating systems.
  13. @shepsheplu Changing the world - but first the mindset Benefits

    of an API-First Approach • Parallel development • Cost reduction • Standardization • Speed to market • Better developer experience • Product oriented !
  14. @shepsheplu Changing the world - but first the mindset We

    can define and design our API without writing code and so you can - and should - involve the business in the creation of the API • Using OpenAPI (v3.1 currently) standard ◦ Based on Swagger ◦ Example: https://editor.swagger.io/ • Writing Yaml or JSON
  15. @shepsheplu Changing the world - but first the mindset We

    can define and design our API without writing code and so you can - and should - involve the business in the creation of the API • Using OpenAPI (v3.1 currently) standard ◦ Based on Swagger ◦ Example: https://editor.swagger.io/ • Writing Yaml or JSON
  16. @shepsheplu Changing the world - but first the mindset With

    a governance group, you can then follow and standardize all the APIs in your ecosystem • Mixed group of people (Engineering & Business) • Guarantee compliance and use case • Validate new APIs • Monitor testing of APIs • Discover missing APIs
  17. @shepsheplu Bridge between Business and Engineering With APIs now being

    a core product it is only normal that this should be known by the business - because it can bring value to the business • Opening APIs to new customers and markets • Having a monetization strategy (or not) • Get more data • Allow other business to rely on our APIs
  18. @shepsheplu Bridge between Business and Engineering From the engineering side

    • Provide data to the business about the APIs • Be proactive about Analytics and Observability • Be a voice on all projects • Report success and failures • Do not hide complexity
  19. @shepsheplu Bridge between Business and Engineering From the business side

    • Involve the engineering side for feedback earlier • Directly work with engineering to build feature • Be present for the testing phases • Ask feedback from engineering on a live project • Learn the basics about APIs
  20. @shepsheplu Bridge between Business and Engineering On API directly, it

    can be a good idea to consider the API contract as the product • Build the openAPI spec with the business ◦ Better knowledge on the possibilities ◦ Good understanding of the use case ◦ Way to find new features that could be useful • Have the business involved in testing ◦ Final product is validated by the business ◦ Reuse tests done to have them setup in your pipelines ◦ Implement a “continuous business testing” policy