Background: What is "Core"?
Clients, particularly Value Added Resellers (VARS) such as First American, often ask us to define what is Quandis' intellectual property. The answer can grow complicated, but boils down to this:
- C# code namespaced with qbo.* is Quandis IP; other namespaces are not
- SQL code sourced in qbo.* projects is Quandis IP; others are not
- XSLTs sourced in qbo.* projects is Quandis IP; others are not
- Configuration data (e.g. workflows) sourced in qbo.* projects are Quandis IP; others are not
Breaking this down by example:
| Quandis IP | Client IP |
- qbo.Core
- qbo.CoreWeb
- qbo.Debt
- qbo.Mortgage
- qbo.Credit
- qbo.Skiptrace
- qbo.Plugins
| - ncm.quandis.com
- sam.quandis.com
- ci.quandis.com
- {client}.quandis.com
|
Example 1: First American builds a customized National Case Management Site
First American's National Case Management (NCM) project includes several things, including:
- a highly customized skin (ncm.Skin project)
- customized advanced search pages (ncm.Web project)
- overrides to core stored procedures (ncm.Database project)
- a global messaging inbox (enhancements to qbo.Message)
In this example, Quandis resources (thanks Mona!) extended the qbo.Message module to handle the use cases presented by First American. First American has every right to use and customize these extensions, but since the code resides in qbo.Message, Quandis has the right to resell / deploy this functionality to other clients. Quandis has no right to resell the NCM skin or customized advanced search pages to other clients without FirstAm's permission.
When deciding who should execute code changes and in what project they should reside, my primary goal is to assess whether the functionality can be reused across clients. If it can, we implement in a qbo.* project, and generally have Quandis resources execute on the change. If not, my preference is to have our VAR implement the change, though often with our help.
Note that the moment First American decided to override core stored procedures (e.g. stored procedures source controlled in qbo.* projects), they also "code split" from our product. They will not be able to accept system updates from Quandis without a manual merge of our changes with their changes.
Example 2: First American customizes BPO workflow
This example illustrates how Quandis IP extends beyond compiled source code. The compiled code for the BPO system is the same compiled code as the Debt Collections system, the Short Sale system, and the NCM system! What makes the BPO system a BPO system includes:
- BPO workflows (rows in the Decision* tables)
- BPO custom forms (rows in the ImportForm* tables, and related XSLTs)
- BPO specific reports
First American has the right to modify custom forms (say, add new fields or change the layout). However, once they do so, they "code split" from our product. They will not be able to accept BPO updates from Quandis without a manual merge of our changes with their changes.
They also have the right to modify a BPO workflow. However, once they do so, they both code split, and more practically, risk breaking the behavior of the standard BPO system. It is in both parties' best interested to ensure that they do so with a full understanding of how the workflow is configured, so they can appropriately support the changes they make.
Realistically, there are changes that can be made with little or no impact to the "standard" BPO system. For example, adding fields to a custom form simply tracks these fields in the ImportForm.ImportFormXml field, and would not degrade the performance of the BPO workflows. However, removing fields from a custom form that are evaluated by a workflow if/then statement will most certainly change the behavior of the BPO workflows. It is crucial that all parties be capable of assessing the impact of such changes.