API Development
We realized that a lot of development were redundant, and we decided to go "service oriented", to work one time on a specific need, and stop reinventing the wheel.
Developers realize that much of the functionality they need to build into an app is redundant to what many other companies are toiling over. They’ve learned not to expend precious resources on reinventing the wheel but instead to rely on APIs from the larger platforms, such as Salesforce, Amazon and, more recently, specialized developers. We’re still in the early innings of this shift to third-party APIs, but a number of promising examples illustrate how developers can turn to companies such as Stripe and Plaid for payment connectivity, Twilio for telephony, Factual for location-based data and Algolia for site search.
Techcunch - "The Rise of APIs" (source)
Table of Contents
API Work In Progress
Reinventing the wheel every time you have to work on something is not efficient. Not at all. At Foyer we listened to the developers and product owners. We worked together to rework the existing ecosystem: a lot of technical debt, and it's totally normal regarding the almost one century of existance of Foyer.
APIs are the best solution to build micro-services and move business complexity to a single location to centralize complex insurance rules. API are building by each Domain Team and orchestrated under the Scrum Framework to allow quickly delivery and short loop of improvement.
While we are working on the construction of APIs and their testing, we are also working on the construction of independent organisms using these APIs. We name those organisms "Features".
Task focused: The Features
Adding a new client in our database is not something simple because there is a lot of way to become a client at Foyer. Read here: there is a lot of application/website that are doing the same job, but not the same way.
Our Features' work in progess is here to create efficient way to exploit APIs a certain way, and once for all propose a homogeneous, adapted and unique user experience for all applications.
Our Design Processes helped a lot here to build consistent flows all over the different existing and incoming application. We played with several methods like Event Storming to get the big picture of our tentacular organization through all of our domains.
We can't expose those Features today, because of the lack of maturity and feedback. But it's just a matter of time.😉
What about the Design System?
The Design System is used by the actors of the APIs and Features initiatives like an example of what can be done to mutualize work, and also "physically" as a way to share the work done on features. It became the place where collaborators can find the reference of all the centralized work done at Foyer.
It's a good cursor that shows you the Design System has its early adopters and ambassador for furthers new usages. Moreover, it's a demonstration of the need to centralized information at one and unique location to falicitate its use.