This is a summary of a recent discussion about making some system A leverage some other system B. The new system B would replace some functionality which system A already had.
The case in favor of A leveraging B was that it would decrease the maintenance cost of system A, since more functionality would be “outsourced” to system B (owned by another team). This maintenance gain could be especially significant if system B offers a correct solution to a difficult problem. That being said, some nuances are missing.
Deeply integrating multiple systems with a single shared dependency has pros and cons. It generates more leverage of course, but what kind of leverage?
If the surface area of the leveraged functionality is large (i.e., lots of APIs), then the more likely it is that any change on either side causes a regression. System A could break the system B, or vice versa, potentially leading to outages. This risk can be mitigated with robust integration testing and other techniques, but in the end it still translates into a productivity cost. These various drags on operations and development can be called coupling cost.
If the maintenance gain - coupling cost > 0, then the leverage is positive on execution, otherwise the leverage is negative on execution.
Reassess this periodically. Yesterday’s great dependency could be today’s liability.