One of the most frequent questions I get during a sales cycle is “What’s the best way to integrate my document solution with Guidewire?” Another way to frame this question is “How will your products impact my current document infrastructure?”
In my experience, any useful software architecture accounts for the realities of a particular customer’s IT landscape. Using that guideline, let me define a “strawman” customer’s document ecosystem to provide context and help me answer the question.
A typical existing document set-up includes the following:
Scanning software for incoming physical mail (which may of course include fax and email channels as well);
An intake process and team that helps index the documents, capturing the document’s business type (e.g., new claim form, address change) and relevant identifier (e.g., policy or claim number);
A document repository (also known as document management system, or DMS) to hold the basic document information and binary file; and
A notification process to inform the core insurance system that the document was received.
My “strawman” customer also operates under some constraints. For example, the budget for their core system transformation project does not include any scope for changes to the DMS, which means it needs to remain intact as it is. They may also be considering some of the DMS-as-a-service providers and solutions on the market as a way to control costs, and don’t want to invest too heavily in their current DMS (even if they could get budget for it and find someone with the right skills to change it.)
They also see some opportunities with their shiny new core insurance system and want to leverage it to the extent possible for best business value, without busting their implementation budget.
So what would my recommendation be considering all of these factors?
Leverage the out-of-the-box document metadata and linking functionality. This data model can be extended as necessary to accommodate additional business requirements. These requirements will be driven by the business experts who also own your core system user stories.
Only build an integration back to the DMS for metadata changes that will add value (in some cases, this may be nothing at all!). In other words, treat the DMS as a pure document storage repository, not an enterprise-wide collection of all-things-about-documents.
At the end of the day, this approach allows for future flexibility without adding unnecessary implementation costs today.