A lot of the work that I do involves the integration of third party products with The Raiser’s Edge. It is not always right to develop a custom application to perform this integration. There are many factors including the volume of data transfer, the complexity of data, how quickly the data needs to be integrated and of course what budget is available. This article attempts to outline the options available to Raiser’s Edge managers who need to integrate with non-Blackbaud products.

Manual “Integration”

This may sound like it is in fact a lack of integration but in some cases it may not be worthwhile creating any kind of integration at all. Where volume is low, where the budget is limited or where the data is sufficiently complex that it requires a very large amount of human intervention (or most likely a combination of these three things) it may well be a good alternative to simply copy the data from the third party system into Raiser’s Edge. Using Batch in RE will speed this up and will make such a process easier to manage.

Pros: Low setup cost (just need to work out and document process), complete control of the process
Cons: No room for growth, may be expensive long term

Integration using imports

A solution commonly used where no custom development is available or budgeted for is to create an import file from the third party data and import it into Raiser’s Edge. Sometimes the third party application can provide a useful format for the import file through equivalent export modules (especially if it comes from a fulfilment house) and sometimes you have to manipulate the data manually or use DTS, SSIS or other data manipulation packages. The constituent id or import id will need to be added to the file. This can be done using lookup tools such as IDLookup or if the third party receives its data originally from Raiser’s Edge the constituent id or import id can be passed along with other data to the application so that it is returned to RE for reintegration.

Pros: Medium to Low setup cost, good Blackbaud support for importing, could be a stepping stone to more automated integration.
Cons: Requires skills in importing (to setup and once setup to change), may incur costs to setup import files, several passes required to import more complex data, need to add constituent information to files.

Integration using custom made plug-in

Bespoke plug-ins allow a lot of flexibility as they are designed to fit in to an organisation’s own business processes. It may be possible to emulate the work of a bespoke plug-in by exporting data, manipulating the data outside of Raiser’s Edge and then reimporting the data but this can be extremely cumbersome and time consuming. With plug-ins all this work can be done behind the scenes so that all the user need do is to select the source data and press a start button. Clearly this type of work is not cheap as it either requires in house API skills or requires the use of an outside contractor. There may be maintenance requirements too if the process should ever need updating. However any good API developer will ensure that the plug-in is at least somewhat future proof and can be changed without the need to recode. Contrary to popular misconceptions it is not required to purchase the API module from Blackbaud in order to run plug-ins. Wherever there is a batch process there is a risk that data becomes out of date and no longer synchronised between the two systems.

Pros: Can be designed exactly as required without any compromises
Cons: Requires API skills, requires at least some user interaction. Can be synchronisation issues.

Integration using scheduled batch application

These are very similar to the above method of using a plug-in. However unlike plug-ins they require no user interaction and can run in the background synchronising data between systems. Since this is a batch process it is not necessary to aim toward 100% uptime of the two systems so that  maintenance need not be carried out at unreasonable working hours. Any exceptions need to be dealt with manually. The delay between the systems should be kept to a minimal (there is no real reason not to) since this will help avoid synchronisation issues.

Pros: Fully automated integration (although exceptions dealt with manually)
Cons: Expensive setup and initial cost of API module. Requires API skills to develop and maintain. Can be synchronisation issues.

Realtime Integration

This is the ultimate user experience. Data can be presented to the user in realtime so that it is always up to date. Applications become much more interactive and responsive. There is a requirement though of a high level of uptime on both systems which may not be easily achievable. It is also harder to moderate user input. Since this is not a batch process which can be user moderated all user input has to be highly validated at the time of entry. It is much harder to moderate and change the data once it is already in the system.

Pros: Fully automated integration (although exceptions dealt with manually). Gives the user the best possible interactive experience. No synchronisation issues.
Cons: Expensive setup and initial cost of API module. Requires API skills to develop and maintain. Requires significant level of system uptime

Other Options

There are variations on these and indeed combinations of them. One such combination uses a realtime read from the database combined with a batch update. That way you keep the same level of user interaction but are allowed to moderate the input. Another alternative is a realtime read and write but then the ability to moderate data once it has already been committed to the system.

Each of these solutions have merits but a careful analysis should be done before deciding which path to go down.