#26 - APIs Inspired Dependencies Management
How to reduce dependencies between Product teams by taking inspiration from APIs
Intro
Dependencies can be a significant setback for teams, often consuming a portion of the ongoing capacity. While no one wants or appreciates dependencies, most accept it as a way of life. Let’s see two ways to imagine a project involving multiple teams trying to work around the dependencies elegantly.
Imagine we want to launch a new marketplace within an existing app. Let’s say this e-learning platform intends to offer a learning marketplace for everyday learners (instead of professional and certified paid instructors). For that, we have two teams, one responsible for the buyer experience (BUYEX) and the other for the seller’s one (SELEX).
One side should come before the other, like the egg and the chicken. I’ve previously written about deadlocks, so let’s assume the teams depend on one another but are not blocked.
The SELEX team works on creating the gig until it needs to interact with the buyer. Now, the BUYEX team wants to get the data about the courses and prices to build the catalog for the buyer persona. The problem is that they can’t do it without the SELEX team providing it.
The Easy Way
Firstly, the SELEX team will work on their databases and integrate their flow almost end-to-end. Then, they will create some mock data and eventually provide the BUYEX team with the data they need to continue their work.
The BUYEX team might find work at this time (after all, they still have problems to figure out), but they do have to sync with the SELEX team constantly. Excessive communication and synchronization could potentially impact project deadlines.
This reminds me of another post about asynchronous communication, where in this case, using the sync way between the team has its burdens and pitfalls.
The contract way
Con·tract
Enter into a formal and legally binding agreement.
The primary lesson from APIs is their interface. Even before you use one, you know what its input is and what is the expected output. This is also called a “contract.”
Let’s return to the previous example and suggest a contract between the team -
The BUYEX team will provide an API to get all available courses.
It will contain a list of courses, sorted by date, with data on ….
The SELEX team will publish an event for every new course registration, including its ID…
Now let’s see how the teams structure their work -
BUYEX - develop an API that returns a mock response with an example course.
SELEX - integrate with the message broker and simulate a registration event.
The above two tasks are no more than hours long and establish the contract. Of course, they may skip this part, but it does give credibility and assist later on in reducing the dependencies.
From this point on, each team works on its lane until the end, where the API and Event come from accurate data (integration tests). While the teams still have dependencies, we were able to remove the need for synchronous communication and other roadblocks.
Summary
APIs are predictable and can be written before the database is connected, or the system is live. Similarly, the extra mile in the planning phase can dramatically reduce dependency in the execution and build stages.
Here are some practical examples where you can use this method -
Preparing a presentation - ensure you have the base theme and agreed-upon structure, organize your slides, and merge them once the final request is sent.
A/B Test - before starting the test, export the mock data, ensure it fits your needs, and prepare the analysis sheet to help you decide on the result. Once the test is done, one more export, and you’re good to go.
Meetings - if the agenda is known, as well as the participants, do your due diligence and come prepared for the possible meeting outcomes (e.g., the alternative solution analysis, the cost of the implementation, etc.)
Image by vectorjuice on Freepik