Integrations are hard. They are also one of the key elements that make your company more nimble. So when you build your integration architecture build it the right way. Unfortunately, when something is hard to do it’s tempting to cut corners. Even more unfortunate is that when something is hard it costs more to get done right. Finally, it might take longer to do it right than to duck tape two applications together.
You have to reverse that logic. Integrations get easier if done right. So future changes will cost less and go faster. Couple that with the old saying “The only constant is change itself” and you have the starting point of a good argument.
By the way, this is why we have architecture principles that we need to follow vs trying to cost justify everything we do. Think about howe complex it is to develop the business case for doing integrations right. You have to incorporate some sort of option value for saving money in the future if change happens. Strangely enough most finance folks I’ve worked with in the past simply say “we can’t quantify that in the business case”. Then why did business schools bother to teach them things like the Black Scholes Model*?
I digress. Here are some key things to get right with integrations:
Don’t do point-to-point
Map any new integration to your business object standards
Define a business object standard for what you need to interface if you do not have one yet
Make sure any change to a business object in your integration architecture triggers an API that publishes the change to your middleware
Have the middleware handle any integration errors in real-time (fix right away if possible vs cueing up a backlog of integration errors)
The hardest part here is to agree on the standard definition of your business objects. What does a sales order exactly look like? You need to define the sales order object so it works with all your applications that require sales order information. This needs to get done when you create your first sales order create, change, delete integration. You might also need to redo it if a new application is added that needs to send or receive data as part of a sales order event that was not there before. The later can happen but is less likely over time.
If you do the above well you have plug-and-play. As you introduce a new application that might change sales order information all you need to do is build the publish (outbound) and subscribe (inbound) integration to the standard sales order object. Unless you had to make changes to the standard sales order object you don’t even need to test the other ends of where you are publishing to or subscribing from. Nothing changed between those apps and the middleware. So all you need to test is the new app's publish/subscribe to the middleware.
If you did not start with this integration architecture you can still move there over time. For any new project that has decent funding start converting integrations to this model. This is going to be hard but worth it over time. if you can’t you better start avoiding integrations like the plague.
* Black-Scholes is a pricing model used to determine the fair price or theoretical value for a call or a put option based on six variables such as volatility, type of option, underlying stock price, time, strike price, and risk-free rate