I was recently asked a question about what is the CUSTOM schema in our tools used for and I thought it may be a good idea to write about it in case you are not familiar with it.
With our enterprise tools there are typically two main components that each site gets.
- The enterprise tool
- A site specific custom ETL solution
The enterprise tool is the same solution at every site. It may allow some level of configuration, but it is not meant to be a custom solution solely developed for each site specifically. There are many reasons for this including maintenance and supportability.
As implied the ETL solution is specific for each site and is the translation between the site’s source systems and the information that our enterprise tools require to operate.
In order for us to upgrade a site from one version of a tool to the next and in order to minimize the effort involved we expect the software and databases to be in a known state. If you have not read Avoiding deployment grief from database drift go read it now this can wait.
Seriously, go read it.
Are you back? Good.
We have definitely encountered issues with database drift where well-meaning people added new tables on site in the customer’s database prior to them being shipped in a new release, or commented out or changed logic in stored procedures without the development team being notified to account for it etc. Luckily the issues are fairly infrequent. However, when they are encountered it becomes an emergency situation for the staff on site trying to deploy the latest version and are getting errors, as well as the support team that has to jump in and try to resolve the problem for them.
So what does this have to do with the CUSTOM schema?
Good question!
While we have an expectation that at no time should the provided solution code be modified outside of release upgrades or hotfixes shipped from development we also recognize that there are valid situations where a site may want some custom feature that is not part of the enterprise tool. For example a custom audit report or a custom view written over our tables in order to feed an export. Whatever the case may be.
In order to balance these needs we have the CUSTOM schema.
If a site needs to create their own objects and process outside of the functionality of the standard tool they can create objects in the custom schema.
During deployments we will ignore objects in the custom schema: we will not remove them or alter them. If changes are made to standard shipped code they will most likely be lost during an upgrade to the next release while items in the CUSTOM schema will remain unchanged.
For example consider excel or some other application you use. Perhaps you have downloaded an add-on for it. Microsoft may not have wrote it and may not support it, but it helps you accomplish some task. When you upgrade excel it may continue to work or you may have to get the next version of the add-on to support excels new structure and functionality. Those add-ons are like the items in the custom schema.
I am curious what questions people have or situations they have encountered. Did this post make sense to you? Are you confused on drift and custom objects? Do you want to chat about enterprise tools versus custom solutions?
Let us know in the comments below.
