Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How to Prepare to Integrate With a Third Party

DZone's Guide to

How to Prepare to Integrate With a Third Party

Integrating with a third party means faster time to market and that you aren't responsible for scalability and support. But how can you know you're ready to integrate?

· Integration Zone
Free Resource

Share, secure, distribute, control, and monetize your APIs with the platform built with performance, time-to-value, and growth in mind. Free 90-day trial of 3Scale by Red Hat

In our fast-moving world, businesses want to shorten the period between an idea and its implementation. You might need a payment system, a notifications provider, or a content management tool for your app or website. You can develop some of them in-house, but in most cases, you can find a tool to help your business get to market faster and to start getting benefits (i.e., money) earlier.

Third-Party vs. In-House Development

Let’s analyze what advantages and disadvantages third parties bring to your business.

I personally love pros/cons matrices. They help with analysis and are a great visualization of your thought process for a presentation.

Pros Cons
In-house

You can build exactly what you need.

You have full control over your data and application.

Requires an initial investment in both development and infrastructure.

Capex vs. Opex for a third party.

Third-party

Faster time to market.

Scalability and support are a weight off your shoulders.

You might need to share your data or your customer's data with a third party.

Third parties are hardly tailor-suited to meet unique business requirements.

Using SaaS solutions is like renting instead of buying. You are not sure whether you want to live in this neighborhood and whether you want to take care of house maintenance.

Third Party Technical Evaluation

Once you decide to go with a third party, it is important to do a technical evaluation of the vendor. Your business becomes dependable on the vendor that you can’t control. If there are any risks associated with the vendor, it’s better to know it sooner than later. This gives you an opportunity to mitigate those risks and to negotiate SLAs.

APIs and SDKs

  • What kind of APIs are provided by the third party? Do they have documentation for the APIs?
  • Do they provide SDKs for your mobile apps?

Availability

  • What is their system's (i.e., APIs, apps) availability?
    •  If it’s a critical system for your business (i.e., payment provider) with 99.5% availability and your app or site has 99.9% availability, your overall system availability becomes 99.4%. Is that acceptable for your business?
  • Do they have any available history of downtimes?

Performance and Scalability 

  • What is the response time for their APIs, SDKs, and web applications?
  • Is it an auto-scalable solution?

Disaster Recovery

  • Do they have a disaster recovery plan?
  • What type of disaster recovery do they have (i.e., cold, warm, hot)?
  • How much time would they need to recover?

Security

  • Do they have SSL for APIs?
  • Do they encrypt sensitive data?
  • Where are the data centers located? (Note: Some countries have regulations about where data can be stored.)
  • Is there any monitoring in place to detect malicious activities?
  • What PII information will be sent and stored by a vendor?
  • If you are providing the third-party with PII, can that be hashed? What hashing mechanisms do they support?

Support

  • What are their support SLAs? If this is a critical system for your business, you might want them to respond quickly.
  • Can you be notified if there are any issues with the vendor so you will be able to mitigate the impact on your business?

Reference Calls

  • Ask the third party to provide contacts for a reference call. They might have some case studies available, but it’s always better to talk to a person who has experience with a solution that you plan to use. Ask questions about ease of development, support process, availability, and unexpected downtimes.

Research 

  • Check Gartner’s and Forrester’s recommendations.
  • Check StackOverflow about any issues that were reported by other developers.

Integration Architecture

Once you've collected and evaluated a vendor from a technical perspective, you are ready to design an integration.

The first question to ask is: What is the system’s level of criticality? 

If the system is critical, my advice is to be prepared for the worst.

  • How will your system behave if the third party is unavailable? Would this impact user experience?
  • Can you turn off the integration with the third party?
  • If you send data to the third party, make sure that you have retry mechanism built in case of system unavailability.

The next step is to do a POC. During the POC, you might want to achieve the following goals:

  • Validate that your developers are comfortable with SDKs and APIs.
  • Implement a few key use cases.
  • Check how the vendor behaves and whether they provide professional support during the POC.

If everything looks good to you after a technical evaluation, reference calls, and POC, and you can mitigate all found risks, you are ready for an integration!

Good luck!

Explore the core elements of owning an API strategy and best practices for effective API programs. Download the API Owner's Manual, brought to you by 3Scale by Red Hat

Topics:
integration ,saas ,archiecture ,third party

Published at DZone with permission of Kate Semizhon. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}