API driven integration
Sounds very much like MuleSoft, which I'm currently evaluating to add to our portfolio offerings.
Create an API layer over your applications, thus effectively hiding all the underlying technology (file transfers, MQ, ODBC etc etc). (e.g. Add new employee to HR system, Add new employee to Finance system etc).
Then add a business process API layer over those, that pull your applications together into meaningful business functions (add new employee to all required systems (which then calls the App APIs).
Then your 'experience' (Mules terminology) APIs over these, which you expose externally (mobile apps, partners applications, web sites etc.).
That way you can change your applications (updates, tech refresh, replacement, move to cloud, move to 3rd party etc etc), and it doesn't break your business APIs or the externally facing experience APIs (changes should be transparent to these layers). Although this does mean designing your APIs properly to start with. (i.e. don't add constricting limitations into your APIs, just because that's how the current back-end application works).
These separate API layers are not mandated, just considered best practice (by Mule).
I've come from a more traditional integration background (IBM Message Broker, ESB and Gateway systems, file transfers, MQ etc). API driven integration seems like a refreshing change to me.