System Integration Best Practices: How to Get Systems to Play Nice With Each Other – & With You!

Cort Buchholz

Written by Cort Buchholz

Highway interchanges signifying systems integrations

Successful system integrations are like diplomacy: you need to establish certain things from the start. Like who gets the launch codes? How do we deal with spies? What are we going to do about that militarized cult of personality?

Okay, maybe that’s a stretch, but there are some similar guidelines that apply. A successful SI project requires adhering to the following system integration best practices from day one:

  • Define user needs, roles and permissions
  • Enable non-repudiation
  • Document edge case protocols
  • Build-in security from the ground up

System integration projects that address these core issues are far more likely to succeed – and avoid mutually assured nuclear destruction – in the long-term. That means less hassle, wasted time and money for clients, developers and end-users alike.

User Needs, Roles and Permissions

From the start, there needs to be clarity about what user needs the integration is trying to solve and how they match up with different roles.

Here’s an example: you’re integrating a grading and assessment platform with a learning management system (LMS) for a higher ed institution. Instructors, teaching assistants, graduate teaching fellows, and students all need access, but it wouldn’t be appropriate to give them all the same permissions.

Understanding these differences upfront might lead you to recognize and accommodate each users distinct needs:

  • Instructors need to design curricula and tests
  • Graduate teaching fellows need to track the course schedule
  • Teaching assistants need to administer tests and enter grades
  • Students need to take tests and view course materials

Otherwise, the systems integration might give certain users too much or too little flexibility to meet its objectives. That could require potentially time-consuming and expensive fixes down the line.

Non-Repudiation

A term borrowed from the legal field, non-repudiation means “unable to deny.” Trusted third parties often provide non-repudiation, as when notaries verify the identity of an individual or a forensic analyst verifies the authenticity of a signature.

FedEx tracking likewise provides non-repudiation for packages by documenting exactly where the package went and who signed for it at the terminus.
This ties into system integrations because it’s critical to verify that messages between systems are sent and received. Otherwise, important information could be missing without anyone being the wiser.

If System A tries to send a message to System B and it fails, it either needs to retry a reasonable number of times, display an error message to the user, send an error message to the support team, or all of the above.

Edge Case Protocols

When something does go wrong, there needs to be clear documentation about how to resolve that issue.

Let’s say a student completes a test and it doesn’t show up in the grade book at the end of the term. Due to a lack of non-repudiation, neither the student nor the teacher know that the test was completed but never got passed from the assessment platform to the LMS.

For every one of those edge cases, there should be a clear “if this, then that” style document. The support team would then know to check the assessment platform, find the completed test and grade, and report back to the teacher.

Without it, you’d have one very unhappy student, a frustrated teacher and support staff, and at least one unpleasant call to the development team.

System Security

Back in 2001, a slew of Microsoft technologies like Office, Excel, Word, Outlook, and Internet Explorer all had egregious security flaws. The issues were so ubiquitous and so bad that Bill Gates sent all 33,000 developers on staff to 2 weeks of security training.

Why go to that incredible expense? Security needs to be part of the DNA of a software company’s culture. When it comes to software, every string of code is a window for hackers. You can’t afford to wait until the QA phase to secure it. It needs to be built secure from the ground up.

A decade later, Microsoft’s culture has finally turned around and their systems caught up to industry standards. While no systems integration will ever be that costly, this example does serve as a warning sign to think about security from the beginning.

Cort Buchholz

Written by Cort Buchholz

Have a project?

Contact Us