The dreaded “application integration” is something that companies do not like hearing. The “I” word is something that CFOs just look at as money being spent on something that could probably be done manually. Well, yes, that’s the point – it’s something that is probably occurring now but is slow, cumbersome, or time intensive busy work. Is there a better way?
Often, applications have APIs – application programming interfaces – that provide software developers ways to access the internals of an application, or tap into the back end database to pull out (or push in) information. While the application itself may be expensive, application integration often ends up 2-3 times the cost of the software itself.
Application integration involves several steps, and goes through a fairly complex process. If you have people on staff that can do this, that’s great, but many will look for a system integrator or other third party consultant who has familiarity with the system.
The integration process starts with identifying the problem or additional functionality that is desired. Based on the findings you define a scope of work, create a functional specification, detailed design documents, and start building out the integration. Once you’re done, you need to make sure it’s working correctly which includes testing, QA, and other verification steps. But wait, you’re not done yet – it also means continued maintenance, updates, and potentially changes down the road if the application is upgraded or the APIs change. Or, you have new functionality that you want to add. The good news is that you hopefully have a solution that saves you time, speeds up an existing process, or is simply easier and better.
Does it always have to be this way? Well, it depends. But often the answer is no. Deep integrations that delve into an application’s core system can be tricky, extensive, and prone to errors and problems. That’s the nature of the beast. But sometimes, externalizing the integration is also possible, and has a light touch. In many cases, the output of a system is a file – a report, statement, invoice, order, etc. These outputs are then sent through some kind of workflow, delivered to a distribution system, printed and mailed, faxed, or otherwise handed off to another system, person, or process.
Biscom’s philosophy on integration is that it should be simple, secure, and fast. So, while Biscom offers APIs and software development kits (SDKs) for all of its products, it also has extensions that support file system integration. Folders can be used to categorize based on a person, a department, a workflow, or other logical division of information. Folders can also be sources from which Biscom picks up a document, delivers it securely, or massages the data before sending it to another step in a workflow. Often, rules, delivery routes, and metadata can be attached to files as they are prepared for the next step of their journey. Biscom can also drop files into specific folders based on rules and policies – so incoming deliveries, whether they are inbound faxes or secure deliveries, can be routed automatically based on your criteria. These drop points are locations from which your application uses to feed into its workflow.
The beauty of file system-based integration is the lightweight aspect of the integration – typically few changes need to be made to the application. Biscom can be pointed to an output stream and take it from there. If you think you might be a good candidate for an integration with Biscom, please contact us to see how we can help you speed up your process and become more efficient.