Whether an organization is adding a new piece of technology to its platform or acquiring a new product to supplement its offerings, the customer (recipient) and vendor (transferor) will need to work together to ensure the successful integration of such technology or product into the recipient’s systems. More often than not, one party cannot do its part without the other party’s assistance, thereby creating a dependency. In this Part 1, we discuss what a dependency is and how to address it in a contract. Check back for Part 2, where we will review remedies available to the parties in case of a breach of any dependency obligations.
Who Is Primarily Responsible for the Integration?
First and foremost, identify which party is primarily responsible for the integration. There are different models that may be relevant in different contexts.
Model A: Recipient Is Primarily Responsible for the Integration
This model works better for the integration of add-on solutions acquired for an existing platform or service. Think of embedding a new feature into a platform, such as an ewallet into a mobile app or a new business analytics tool into an ERP system.
An integration of this kind requires deep knowledge of the recipient’s environment to ensure a seamless integration, so the recipient is in a better position to manage the integration. Further, such integration requires direct access to the recipient’s systems and recipients are usually reluctant to give the transferor such access.
Model B: Transferor Is Primarily Responsible for the Integration
This option is good for standalone solutions where an acquired product must be disentangled from the transferor’s environment and connected to the recipient’s ecosystem. Think of the selling of a mobile app or an online platform.
As the solution is a standalone one, it is usually relatively easy to connect it to the recipient’s systems through an application programming interface (API) or enterprise service bus (ESB). Note also that it usually requires more effort on the part of the transferor to disentangle the product from the transferor’s systems. In addition, this option would often be used for “turnkey” purchases.
Model C: Both Parties Are Equally Responsible
This model often arises in a joint venture context and is the hardest to document and manage.
Understanding Assisting Party’s Responsibilities aka Dependencies
Once the party primarily responsible for the integration (responsible party) has been identified, proceed with outlining what assistance will be required from the other side (assisting party) for the responsible party to be able to successfully complete the integration. This process is usually called “dependency mapping.”
Dependency mapping will start with listing what information, documents, software, and services the assisting party should provide or develop to assist the responsible party. Other, less obvious items to consider when dependency mapping include the following:
- Personnel with knowledge: Does the assisting party need to agree to make developers or other specialists available for consultation? Does the recipient need assistance from the transferor to hire developers who used to work for the transferor but will now be employed by the recipient?
- Hardware required to run the product: Who is providing it? Does the transferor need to transfer or sell designated hardware to the recipient?
- Historic data: What data needs to be transferred to ensure successful operation, and who is responsible for complying with privacy requirements related to such transfer?
- Third-party software, services, or data: Does the solution depend on any third party in one way or another? If yes, who is responsible for transferring existing contracts to the recipient or entering into new contracts to ensure continuous operations?
Addressing Dependencies in a Contract
Once the dependency mapping exercise is complete, the parties can then evaluate whether it would be appropriate to use a general reasonable assistance clause such as the following: [Assisting party] shall use and exercise commercially reasonable efforts, taking reasonable, ordinary, and necessary measures to ensure an orderly and smooth integration of the product.
Such general reasonable assistance clause is favorable for the party primarily responsible for the integration, as the responsible party can rely on it if anything was missed during the dependency mapping process.
However, in many cases—for example, where there are a lot of dependencies, there is some consideration attached to integration services, the overall purchase price is dependent on the success of the integration, or the assisting party wants to avoid surprises—it would be more appropriate to negotiate a separate dependency schedule. Such dependency schedule would outline, in relation to each integration workstream, the information, software, hardware, and services that the assisting party must provide to ensure a successful integration.
But what if the assisting party is in breach of its dependency obligations? Watch out for Part 2, where we will review some of the remedies to address this risk.