When to consider enterprise application integration as the best software decision
The IT world has become much more interconnected between applications and solutions coming from different software vendors. Software is becoming more intelligent and, of course, companies want to use this benefit to become more productive. How to get and use this new software feature with the best balance between cost and effort is a key question for IT responsibility.
Selecting a new product may be a good choice when a complete cut is needed to start with something much more modern and with better benefits compared to the good ole legacy application. Of course everybody knows that taking this direction is an important and crucial decision.
It’s not only the cost and risk to buy, configure and test the new software that’s important to examine. You must also consider that the business user front end will be completely different, so the secondary costs to train users and get their acceptance is a remarkable point. Nevertheless, it often makes sense to do this step – but not always.
If a legacy application needs to be extended with new features, or the other way around, if a new enterprise software still uses the legacy application for good working features, it makes no sense to take the high risk of building a completely new solution. Instead, you might consider the integration of existing applications, and there are many ways to accomplish this approach.
Having relatively new software installed most probably Enterprise Service Bus and Service Oriented Architecture is available and can be used to interconnect. We speak here about the possibilities to use macro and micro services to trigger a complete complex workflow in the other application just with one message or to combine certain small and simple functionalities to build the workflow in the own app. SOAP standards like CMIS interfaces are available to have a well-defined way to exchange documents.
Of course there are also older applications without the possibility to communicate via HTTP(S) (using SOAP and REST). How to do it here?
All software gets input data, processes it with optional locally stored data and produces output data. The integration can happen by file interfaces to pass CSV files, XML files and other binary information to get output files like AFP and PDF.
Another functional example is to extract data from PDF files and store in an external database. Here we need connections to independent databases, such as DB2, Oracle or MS SQL server.
What about APIs via loaded libraries? In former times this was often used to extend an application with a foreign module. Keeping such programming interfaces constant over many years without breaking the compatibility is often not accomplished, so upgrading to a newer, better software is not possible unless the version is adapted.
The recommendation is to go away from such API’s to have a looser coupling between systems. If this approach is not possible, it might require the help of software developers to transform an existing API into network messages. This very thin API layer can then be kept much easier compatible.
In case you want to get more information please watch the following video I presented at our Virtual Open House this year:
Development Manager at Papyrus Software