By Chris Riley, ECMp, IOAp, VP Marketing
August 10, 2010 - 1:21 PM
When it comes to enterprise technology, let’s face it, the more complicated the better. Complicated enterprise technology is job security, ensures premium software prices for vendors, and keeps the entry barrier high. One of the biggest challenges in enterprise technology, especially ECM, is integration. Integration between ECM components such as imaging to ECM, or integration between one ECM to another can often be the biggest cost and challenge of any implementation.
In this post, I would like to talk about why the integration between imaging applications and ECM systems should be the lessor consideration when choosing capture software, and why it can be as easy as creating a new folder.
Because data capture and other document imaging technologies require significant focus, adding other complexities such as integration can force a project to never start, or force an organization to choose a technology for the wrong reasons. I’ve seen companies in the past pick capture software just because they exported to one specialized file format. The result was an inadequate capture application with a stellar export. What is the value of any exported data if the quality is poor?
For this reason, I coach companies to focus on the export format as the very last aspect in their capture product decision making process. I also explain that for MOST packages it’s possible to create any conceivable export, so as eliminate the concern all together. If the data is there, 99.9% of the time it can be massaged into any shape you desire.
Not only does the export format come under fire, so does the means of delivery.
Most organizations when it comes time to consider the transfer of images and data from data capture application to Enterprise Content Management system ask for a connector specifically written to incorporate the chosen imaging applications API to pass images to the chosen ECM applications API. API to API transactions are the best way to ensure features and stability, but at what cost. Most pre-created connectors were made for the purpose of a brochure and not for production. I'm not sure what to blame, the warm and fuzzies that come from the realization that an OCR or ECM vendor has spent specific effort to develop your specific connector, or the faith that somehow these special connectors are better. What I do know is that in most all cases connectors are overkill and simply not necessary. Why? Because there are hot folders, and they are amazingly powerful and simple.
A hot folder ( sometimes called a watch folder ) is a directory virtual or real that is setup to be a staging location or queue for applications to put data into, and take data out of in real-time. The best thing about hot folders is they are free! Most all imaging, data capture, and content management applications support hot folders. If they don't, you have every right to ask why. When a scanner produces images, they can store the images automatically into a folder. The data capture application can automatically read images from this folder as soon as they appear. After data capture and OCR has done its thing, the results can be automatically exported to another directory that a content management application can automatically pick up from. That is two folders vs. two pricey connectors.
Very often custom built connectors use the hot folder approach, just without you knowing. Ideally, API to API is the best way to go, but most connectors are not utilizing all the features you require anyway. The upshot; if you need an API to API connector, build it yourself or through professional services to be exactly what you want. If you don’t need it, then use a folder! In the end how data moves from one application to another is NOT the most important feature of the product, rather focus on its core functionality and what it was built to do, data capture for data capture, ECM for content management.
Rate Post
You need to log in to rate blog posts.
Click here to login.
Type the code shown below to submit your report
This post and comment(s) reflect the personal perspectives of community members, and not necessarily those of their employers or of AIIM International
