I’ve just returned from Review My AMS’s AMSfest where Teri Carden and company hosted a fantastic, boutique conference with 135 of their closest association exec, consultant and AMS vendor friends.

First, let me say that I love Chicago despite the insanely boring drive from St. Louis. Second, these are good people all around, so this was a worthwhile conference in my book. If you have the chance to go to the next one (tentatively later this year and in DC), I highly recommend it.

The event featured breakout sessions called Block & Tackles, and one that I attended and thought worthwhile was centered on 3^rd Party Integrations led by Ben Muscolino of benel Solutions.

Integrations fall nicely into that complex type of work that makes our developers light up (they love a good hook up).

Inspired by the session, here are 5 things to keep in mind for a successful 3^rd party integration to your AMS:

1. Who is responsible for what? Defining early on in your project (or better still in your contract) who will be the responsible party for what (the AMS, the 3^rd party, a development partner, or you) will lead to less finger pointing and diffusion of responsibility and more ownership of any issues.
2. A friend of mine in real estate used to say “a written understanding makes for a longer friendship.” In software that can mean having a thorough and solid requirements document that details (thank you Kevin Baliozian from Medical Library Association for this share at the session).  Where you can’t (and this is more often the case), I’d encourage you to be open and understanding of an Agile approach.

I use the analogy of Joanna and Chip Gaines of the home renovation show Fixer Upper. In every episode, Chip uncovers something inside the walls that he hadn’t anticipated and Joanna must call the homeowner. She then suggests a change or new solution or removes that issue from the project if it puts things over budget.

This is really similar to what happens in software development.

Some things can’t be foreseen by even the best developers. It’s up to you to then decide how to embrace any change that’s needed.

3. Identifying potential pitfalls and fail point possibilities will help with scheduling buffers and planning. It will also help you feel more on top of things if something goes wrong that you anticipated more so than if it happens unexpectedly.

See also #1 in this regard – whose job is it to fix something if it does break?

4. How is this connection going to be done? API, Open API, REST API, SSO, Authentication?

Incidentally, this connection is far more likely to work if your providers have made the connection for someone else before. Be sure to ask your vendors for input on what software they’ve connected successfully in the past.

5. How will you deal with upgrades needed in the future? Whether it’s your AMS, or the integrated piece that’s being upgraded, there’s a good chance the integration is going to break after an upgrade (on either side). How will you be prepared for that outcome? Have a plan.

Do you have an integration story? A horror story? Please share with me at jstone@engagesoftware.com and if I can incorporate how it could have been less scary or even avoided into this post, I will (in your email, please let me know if it’s ok to use your name).