Estimating Development Time

Estimating the time required to build an integration can be difficult, as it depends heavily on your existing architecture, team experience, and the desired depth of functionality. This guide provides a framework to help you create a more accurate and realistic project plan.

What Takes the Most Time?

While the actual coding is a significant part of the work, our experience shows that the following areas often consume the most development resources.

• Product Decisions: Before writing a line of code, you need to decide how the integration will function within your product. How will users initiate a sync (if it's not automatic)? How will you handle data conflicts? What does the UI look like? Answering these questions upfront is critical and time-consuming.
• Data Model Changes: This is often the largest technical hurdle. You will need to adapt your existing database schema to accommodate data from external systems. This can involve restructuring your organization hierarchy (i.e. classes, schools) or, more commonly, adding a way to store external identifiers (like the Edlink id) for your users, classes, and other objects.
• Existing Customer Migrations: If you have existing customers that you plan to move to an Edlink integration, you will need a strategy to map their current, manually-created data to the new, synced data from their LMS or SIS.
• Scope of Functionality: At risk of stating the obvious, the more you want the integration to do, the longer it will take. A simple SSO and rostering integration is far less complex than one that also includes deep integration with assignments and grade passback.

General Timelines

While every project is different, here are some rough estimates for a developer who has some prior experience with building integrations.

• 1-2 weeks for a simple integration (SSO + Roster Sync).
• 3-6 weeks for a more complex integration (SSO + Roster Sync + Assignments + Grade Passback).

These timelines assume that the necessary product decisions and data model changes have already been planned. Obviously, large data model changes and migrations may add significant time to the project.

Factors That Influence Your Timeline

Use these questions to refine your estimate:

• Have you built an integration before? If your team has experience with OAuth 2.0, processing webhooks, and syncing external data, the project will go much faster.
• Have you built more than one integration? If so, you've likely already developed an abstraction layer for handling external data (e.g., a polymorphic external_identifiers table). This can be adapted for Edlink and significantly reduce development time.
• Do you have an existing job scheduling system? If you already have a cron-type process and a worker architecture for running background tasks, you can leverage this for your roster syncs instead of building it from scratch.
• How large are your largest districts? A sync process that works for a 1,000-student district may not scale to a 100,000-student district. Performance testing and optimization will be necessary for larger clients.
• How many districts do you plan to support? The more integrations you have, the more robust your scheduling, queuing, and monitoring systems will need to be.
• Will you provision data ahead of time or on-demand? A full, scheduled roster sync (ahead of time) is more complex initially but may be more robust and scalable, operationally. Fetching data on-demand via the User API as users log in is simpler but less suitable for admin-level features or analytics.

Assorted Best Practices

To avoid common pitfalls, we strongly recommend the following:

• Don't use email as a unique identifier. Email addresses can change and are not always guaranteed to be unique in the source system. Always use the Edlink id field to uniquely identify people, classes, schools, and other entities.
• Soft-delete your data. People or class might temporarily disappear from the data feed due to an issue at the source, or a modification of Sharing Rules. Instead of permanently deleting the record from your database, mark it as "inactive." This prevents accidental data loss and allows for easier reconciliation on the next successful sync.
• Break your implementation into phases. A phased approach allows you to deliver value to your customers faster and reduces project risk. We recommend:
  • Phase 1: SSO + Roster Sync. This is the foundation of most integrations and provides immediate value by simplifying login and user management.
  • Phase 2: Assignments & Grade Passback. Once rostering is stable, you can build on top of it with more advanced coursework functionality.