Documenting Integration Requirements

Top Questions For Thoughtful Integration Documentation

Our clients increasingly want to integrate their CRM, ERP/SIS, and other business applications (their “Solutions”) into a database or another enterprise application. The question they almost always want to know is, “How much will it cost?”. To answer this question, first, be prepared to present a high-level description of your integration. This could be a paragraph or bullet points summarizing what the integration needs to do. However, to reasonably answer the cost question, we typically need documented requirements. The following article reviews basic questions you should be prepared to answer and document.

Documented requirements can be produced by you – the client, or you can hire a firm like SIG for a short “phase 1” engagement to facilitate the discovery and documentation of your requirements. If you elect the latter, you own the deliverable document under which you can (a) hire the documenting firm to implement, (b) bid them to other firms, (c) do the integration yourself, or (d) put the project on the shelf for a later day. If you prefer to document the requirements yourself or are preparing for your integration discovery meeting with us, the following are some of the initial questions that we like to document to make a recommendation on approach, technology and the associated cost and timetable.

1. What are the business applications or databases that you want to integrate? We will often refer to each end of an integration connection as an “endpoint”.
2. If it is a database that your Solution is connecting to, what is the type and version of the database? E.g., MsSQL, MySQL, Oracle, MS Access., etc. and what version.
3. If it is a business application, what edition or version is it? For example, if Salesforce CRM is involved, are you using Professional, Enterprise, or Unlimited Edition.
4. Does the database or application have an API (application programming interface) or web-services? If yes – attach any documentation you have on the API or web-services.
5. Does the database or application have Internet access (if not a web-based application)? To integrate with web-based applications like Salesforce, Slate, Ellucian SaaS solutions, Workday, and others web-based applications, you will ultimately need to provide some mechanism to get the data from your database or application to the Internet if they aren’t web-based.
6. What do you want the integration to do? This one is critically important and, in many cases, you may want the integration code to do lots of things. For example, do you want a one-way integration where invoices from your financial system are pushed to a custom object or table in your CRM and updated; or are you looking for a two-way sync where accounts, opportunity, products and invoices stay in sync. Consider drawing it out on paper with one-way or two-way arrows. Include the diagram in your documented requirements.
7. What do you want to be the trigger to move a record or cause the integration to begin? For example, is it the creation of a record, a change to the record, or a batch process that runs every night.
8. If the integration can be triggered by a person, what roles or profiles or people will be allowed to kick-off the process?
9. If the integration is a batch process (a group of records updating the other system periodically), specifically what records are included in the data set? Will it be all of the records or only records meeting certain filtered criteria (like those added or changed since a particular date)? How frequently would the batch run and is there a particular time of the day and/or week it should run?
10. Also, if the process is a batch process, how many records are likely to be included in the typical data set and how large could the data set become? For example, are you pushing the entire data set daily, or just adds, edits and deletes? Are the number of records likely to be in the hundreds, thousands, tens of thousands or millions? What about in one year or three years? We want to build in scalability so that it keeps working for years to come. This count will also help us recommend the correct technology. For example, if your record set is very large it could take days to process the entire data set with one technology and hours with another.
11. Do you need the integration in real time or near real time, or is a nighly, weekly, or monthly update adequate?
12. What happens if the integration fails or if one of the endpoints is offline? Does it need to be reprocessed, or can the data set be skipped?
13. When the integration runs, what type of error logging if any do you require? What happens if the integration encounters unanticipated results? E.g., no record match, duplicate record match or out of bounds values?
14. How many endpoint pairs will there initially be as part of your integration? (e.g., SQL<>Your Solution would be 1 pair).
15. Do you expect the number of endpoint pairs to grow over the next 24 months?
16. How frequently will the integration code need to be updated? E.g., will you be adding new fields or logic over the next year that will require changes to the integration?
17. Do you already own an integration middleware? Examples include Mulesoft, Ellucian Ethos, Dell Boomi, IBM Cast Iron, Informatica, Jitterbit, Pervasive, Scribe, Dataloader.io, plus many application specific connectors.
18. Do you have internal developers that will be maintaining the integration code or supporting the middleware? If so, are there preferred technologies?
19. What is the ROI for the integration? To figure this out, estimate the amount of time saved by individuals that would have to double enter data, correct duplicate data or would have to search for data. Estimate their hourly rate. Solve for the equation: Annual Cost Savings = (hours of effort saved each month x avg hourly rate of impacted employees x 12 months) – less the upfront cost of the integration development (one-time fee) + any middleware licensing costs (typically an annual fee). If your number is negative, consider not doing the integration unless there are subjective factors like the cost of customer satisfaction that is impacted. If the number is positive, consider how many months it will take to recover the initial investment (aka your payback period). You may also want to spread the upfront integration development over multiple years.

Application-Specific Thoughts

Ellucian Banner

• Is Banner hosted in Ellucian SaaS, Ellucian Cloud Hosted, or on-premise/private cloud? 

• If not Banner SaaS, are all APIs and messaging components installed?  What is the version of: 

• • Integration API 

• • Student API 

• • Business Process API 

• • Banner Event Publisher 

• • Ellucian Message Service (EMS/RabbitMQ) 

• • Ellucian Message Adapter 

• Is Data Access (data lake) configured and in-use? 

• Is Data Connect (part of Experience Premium) available? 

• Is Ellucian Insights in use/available? 

Salesforce CRM

• The edition of your Salesforce CRM matters. Salesforce Enterprise, Unlimited, Einstein 1 Sales, Platform, Education Cloud, and Developer Editions provide the API and additional coding tools; Salesforce Pro Suite (formerly Professional Edition) will in very limited cases be sufficient for custom integration. In nearly all cases, Starter Suite (formerly Essentials Edition) will not support custom integrations. Consider upgrading in these circumstances if integration is a requirement. 

If you have additional questions, or would like to discuss your integration needs, feel free to contact us. We would love to hear from you!