Integration technology is getting simpler and more available – don’t think it was worth writing a blog just to establish that! Perhaps because of this, there’s now a shift from being able to integrate two applications to be able to make that integration effective.
You see we often get a request to “just integrate” two applications. And in many ways, that’s an understandable sentiment. I mean, why wouldn’t you want all of the information from your apps to be available in all the others?
Well, it’s possibly a little counterintuitive, but we’re going to humbly suggest that in integration design ‘limitations’ are your friend. Let me elaborate…
Get that time sheet approved…
Say you have a Time & Attendance app that you want to connect to your payroll app. The T&A app produces a timesheet that is transferred to Payroll. Easy.
But wait! The timesheet was sent before it was properly checked, the employee has added more hours, but the timesheet has already been processed and the pay run completed.
Now you could write lots of clever code that detected and processed updates, transferred them to payroll, detected the status of the timesheet in payroll, reversed it if needed then posted the update then reversed the pay run, recalculated everything then reprocessed the payroll again (phew!)
OR you could make the T&A app the master, implement a business rule that says that all time sheets should be approved before transfer and can’t be edited once approved.
You’ve just significantly reduced your development, what you develop will be simpler and more reliable, PLUS you’ve made it necessary for the organisation to implement good HR practices!
Ye cannot serve two masters…
Another example – the classic scenario where you want to your email marketing solution updated from your CRM. Now in actual fact, these days, these two probably communicate with each other all by themselves – but for the purposes of this example: this can be achieved in a deceptively complex scenario where all new subscribers and updates are transferred in both directions. Where you write code to manage validation, duplicates, CONFLICTS etc etc etc
OR you set one app as the master and ONLY push updates from that one to the other. Again that seems like a limitation and less technologically clever. But if you implement it that way not only do you save on development cost and end up with simpler more robust code. The ‘limitation’ ALSO channels your client to implement good list management and setup data flows to a central point. We think that’s a win for everyone!
You see with all the technology around at the moment – the temptation is to code something super complex that attempts to allow for a multitude of potential variations on the workflow.
What we think is actually clever – is to deliberately limit what is possible, and build streamlined, simple, ROBUST mechanisms that not only make the technology more efficient – but these workflow boundaries actually help organisations achieve more efficient human systems as well!!
Or put another way – It’s not how you integrate it’s what you integrate!
Hope that helped – if you’re looking for advice on your next integration project (or an entire integration platform with advice included!) – get in touch – we love to talk!