See also our Customisation Support Policy.

Caliach Vision V5: Full Site Support - Coordinated Customisation

Introduction: V5 and Site Customisation

Our experience of migrations to V5 have led us to streamline the handling of site customisation. We have already added a feature to the Upgrade Via the Internet that can both upgrade Caliach Vision system code with fixes and enhancements and site customisation (from a site secure folder on our FTP server) simultaneously.

Why Customisation can be Problematic

Experience has shown with customisation on migration to V5 that a number of issues can cause problems, delays and increased costs, best summarised as the follows:

  1. All your customisation should reside inside your ProgCode.usa (or ProgUser.db with V5). Over years, different users can create different ProgCode.usa files and the "latest" may just contain the "latest additions", so the full suite of customisation is not complete. Custom classes can lurk in the Vision.lbs you are using. This problem can lead to the loss of custom reports, etc. on migration, and then extra days of work to re-build them.
  2. The naming convention for custom reports and other classes can be inconsistent and may be unsafe as V5 has several new class name prefixes.
  3. With customisation managed locally by you on the site, any request to us to add or modify stuff requires the latest to be sent to us even when we already have the latest because we can't be sure you haven't changed something.
  4. Because V5 customisation is technically more complex than V4.1 and before, local tinkering can have unpredictable results and then the need for help is expensive when we have to provide it remotely. Inevitably moving to a client-server SQL architecture means having a reasonable knowledge of the SQL language and a deeper familiarity with Omnis Studio syntax and variable system.
  5. Site system managers leave, or are replaced, or memories fade so it is common that there is no full knowledge on-site of what part of the customisation does what.
  6. When major upgrades take place changes can effect previously stable customisation leading to downtime and "fear" of upgrade.
  7. Technically V5 is more prone to customisation obsolescence than previous versions. This is because reports have to be "passed" the data (using parameters) rather than just read it directly. The link between program core and custom reports is more intimate and therefore vulnerable to changes in the core programme. If we know what sites have as customisation, we can fix issues without the site even knowing there was a problem, rather than you suddenly and inexplicably finding out something is broken. For instance, we could speed up standard reports by restricting the columns of data returned from the server to those needed on the standard report. That would break your custom report that had a couple of added non-standard columns.

Full Site Support Service

We now have long experience of independently wholly managing and maintaining one site's extensive customisation. Despite the scale, this site still has ultimate "ownership" of the customisation, but does not have to discriminate between the core program or their customisation when seeking help from us to issues. We treat it as a full site and identify what falls into customisation and additionally charge for the work on that part alone. It is a seamless, worry-free service.

The way V5 Full-Site Support works is as follows:

  1. We manage and maintain your customisation, and hold it in your private FTP folder on our server. This allows changes to be included in Upgrade Via the Internet.
  2. When you ask us for anything we have an installation dedicated to your site to quickly establish what is needed and implement it. Charges are minimised and will be invoiced subsequently.
  3. If you want to implement changes yourself, you will need to notify us so that we can upgrade our master set-up accordingly, at a small charge.
  4. Setting up existing V5 migrations is free, and for new migrations where we have converted customisation it would start as the default at no additional cost. New sites, electing to have Full-Site Support after doing their own customisation would be charged a small set-up fee depending on the extent of it. A copy of your database would also be needed to complete the Full-Site Support set up.
  5. The most important advantage of Full Site Support would be when faults are fixed or enhancements made we would be able to identify quickly that a site customisation was effected by it and seamlessly apply to it a change at minimum cost, so you can rest assured that any system upgrade will not effect your customisation. Economies of scale and automation will enhance this.
  6. One barrier to Major Upgrades is the fear of upsetting site customisation that often limits or delays enhancements that would otherwise be useful to you. If we have access to all customisation we would be able to identify who would be affected and work around the issue. The new V5 client-server architecture makes this more likely to occur than previously. If sites were Full Site Support both enhancement-fear by us and fear-of-upgrade by you would be, if not eliminated, significantly reduced.

This Full Site Support should improve your experience of Caliach Vision and confidence in your customisation. It may not suit every site but, by default, we will assume that you will want to use this service. If you don't want it you will need to opt out.

In practise, Full Site Support will mean:

  1. Your site customisation will be held on our FTP server and available to Update Via the Internet.
  2. We will routinely maintain it in line with Caliach Vision maintenance when it needs it. You will be charged for this on the basis of Customisation Support Policy and invoiced occasionally when this happens. This may sound like a Direct Debit license but it is not. Think of it as a holistic approach to trouble-free customisation integration with Caliach Vision maintenance.
  3. What I would do to manage this, is for each Full Site Service we would raise a Sales Order which would stay on our system indefinitely and add a line item for each customisation encounter, making a dispatch and invoice you when it was worth it. It would be completely transparent.
  4. Our desire here is to improve our ability to enhance the product with maximum take-up and minimum disruption. To do that we need to have some central management of site customisation.
  5. You can opt out and go-it-alone if you wish, and bear the risk of getting out of sync with Caliach Vision's core.