Whether an organization adds new technology to its platform or acquires new products to should be well integrated into the platform. Recipient system. In many cases, one party cannot fulfill its role without the other party’s assistance, creating a dependency. This first part explains what dependencies are and how contracts deal with them. Please revisit Part 2, which identifies the remedies available to the parties in the event of a breach of the Dependency’s obligations.
Who is primarily responsible for the integration?
First and foremost, identify who is primarily responsible for the integration. There are different models that are relevant for different contexts.
Model A: Recipient primarily responsible for integration
This model is suitable for integrating add-on solutions acquired for existing platforms or services. Consider incorporating new capabilities into your platform, such as incorporating e-wallets into your mobile app or incorporating new business analytics tools into your ERP system.
This kind of integration requires deep knowledge of the recipient’s environment to ensure seamless integration. So the recipient can better manage the integration. Moreover, such integration requires direct access to the recipient’s system, and the recipient is typically reluctant to give such access to the transferor.
Model B: Transferor primarily responsible for consolidation
This option is suitable for stand-alone solutions that require acquired products to be released from the transferor’s environment and connected to the recipient’s ecosystem. Think of selling mobile apps or online platforms.
Because the solution is a stand-alone one, connecting to the recipient’s system via an application programming interface (API) or enterprise service bus (ESB) is usually relatively straightforward. Also note that it usually requires more effort on the part of the transferor to untie the product from the transferor’s system. Additionally, this option is often used for “turnkey” purchases.
Model C: Both Parties Are Equally Responsible
This model often occurs in the context of joint ventures and is the most difficult to document and manage.
Understanding Auxiliary Party Responsibilities, or Dependencies
Once the main owners of the integration (the people responsible) have been identified, outline what assistance they need from the other side (the backers) to help them successfully complete the integration. This process is commonly called “dependency mapping”.
Dependency mapping begins by listing the information, documents, software, and services that the contributors need to provide or develop to assist the responsible party. Other less obvious items to consider during dependency mapping include:
- Knowledgeable Personnel: Should the helper agree to allow developers or other experts to be consulted? Do you need help from the transferor to hire a developer who will be employed by the transferor?
- Hardware required to run the product: Who provided it? Must the transferor transfer or sell the specified hardware to the recipient?
- Historical data: What data must be transferred for the operation to be successful, and who is responsible for adhering to privacy requirements related to such transfers?
- Third-Party Software, Services, or Data: Does your solution rely on third parties in any way? Who is responsible for concluding
Dealing with contract dependencies
Once the dependency mapping exercise is completed, the parties can assess whether it is appropriate to use general reasonable support clauses such as: [Assisting party] You shall use and perform commercially reasonable efforts to take reasonable, ordinary and necessary steps to ensure the orderly and smooth integration of the Products.
Such general reasonable support clauses are favorable to the party primarily responsible for the integration. This is because the responsible party can be relied upon if something is overlooked during the dependency mapping process.
However, it is often the case, for example, when there are many dependencies, when there are considerations attached to the integration service, when the overall purchase price depends on the success of the integration, or when the assisting party avoids surprises. , it is better to negotiate a different dependency schedule. Such dependent schedules, associated with each integration workstream, outline the information, software, hardware, and services that the sponsor must provide for a successful integration.
But what if the assisting party is in breach of their dependency obligations? Part 2 reviews some remedies to address this risk.
