"Invisible" Introduction
Billy and I have been talking about this concept for some time and I come across it more and more talking with customers and internal colleagues. What we mean by this is the concept of content (or records) management sitting behind an application and essentially invisible to the end users.
There's a lot to cover in this topic - architecture, performance, security, routing, etc., but I wanted to explore some broad concepts first.
Let me give you an example of where we are doing this successfully (Wayne was involved with this project too). The client is a large "insurance" company in the APAC region (it's not really insurance as we understand it, Jim, but that's not important right now). They were implementing a new claims management system but needed more flexibility in the way that actual content was managed and transformed behind the scenes.
Here's how we do this using invisible ECM and SOA:
Scenario 1: claims manager receives printed letter from client referring to insurance claim.
User logs into claim management system and selects option to "add document". Fills out claimant infromation, date received, etc. and sticks the barcode sticker onto the original document. This barcode number is assigned as the uniqe identifier for that document. User then sends original document with barcode to regional scanning center.
In the meantime an XML message is put on a message queue to create a content entry without associated content (a "metadata only" item in our language). This message is picked off the queue by our middleware java application created using CIS (Content Integration Suite), recognizes that this is a "create new" request and that it will create a record (rather than a draft) because of the system it has come from. It also picks up the original contributor, date, and all the other associated metadata entered at creation.
CIS then sends an instruction to create a new metadata-only record for the currently active records instance. When the record is successfully created, it responds with a unique content ID and this is written back to the message queue, where it updates the claims management app with this identifier.
A couple of days later the original document is received at the regional scanning center. It is one of 50,000 or so items to be scanned per working day. The item is prepared (i.e. staples and post-its removed, placed in a clear folder if wrinkled or smaller than standard size (A4)) and then it is placed in a feed queue for a large Kodak scanner. This scans both sides at the same time and reads the barcode stuck on it. The scanning software could also do OCR if needed, but in this situation it's not required. The scan software releases the image to a validation step where the barcode value is checked against a database table. This is updated twice daily from the content management system in order to check that nothing has been scanned to this barcode already and that the value derived from the barcode is internally consistent (with a check digit calculation).
After validation the scanned image is converted to PDF and sent to the UCM system where it is matched to the original metadata only record. From now on, whenever a claims manager searches for documents associated with a claim, they will get back a list of items and can click on any of them to get a PDF of the original (or get a message saying that the original is still being processed). All they see and interact with is their claims management interface, but behind the scenes is a robust content management system applying retention management, format conversion, additional security, and tracking access.
In my next posting I'll cover the process flow when searches are conducted from within the claims management system, and how managers can submit electronic content as drafts or records.
