UCT's Release Upgrades Solution

We have a better approach to conducting release upgrades

Typical Policy Administration Release Upgrade puzzle

If you are facing the daunting task of how to apply a release upgrade to your legacy system, then you understand the often trivialized complexity of the task. Let's look at the background for typical policy administration system "upgrades" for the typical UCT customer (policy administration system owner):

1. Policy administration system vendors usually provide some tools, including data migration programs, to help customers upgrade from one release to the next.
2. Vendor tools normally do not accommodate customer modifications and changes. Since the "business rules" reside in hard-coded programs, this retrofit typically becomes a programming effort.
3. Most customers do not use all modifications supplied in a vendor release. Most customers spend considerable effort analyzing the enhancements against the business function and product they need.
4. Data migration isn't the most complex task in release upgrades. The most complex task is usually the code retrofit, which refers to the integration of new release enhancements with the existing version of the customer's system. Since the customer's system is frequently customized, this retrofit usually takes the most time and effort.
5. Data migrations get much more complicated when multiple releases are involved (most vendors do several releases per year). It gets very complicated when several years of releases are included between the existing release and the targeted release. When this is true, the result is that:
   1. Use of the vendors release migration programs gets very complicated because testing is required for each release to make sure it went in correctly before proceeding to the next release
   2. Each step requires the "customization" of the vendor's release upgrade tools to account for the customer's modifications
   3. Both a. and b. (above) are highly redundant and prone to errors, causing unneeded expense and delay
   4. Customers are often better off to abandon the release-to-release approach and focus on the starting and ending releases.
6. In any case, the strategy is essentially a file-to-file methodology, which is based on similarities and differences between the data models for the starting and ending versions of the upgrade project. Without automated tools and with data models that include many thousands of data elements spread across many records and segments, this becomes a tedious and time-consuming process.

Universal Conversion Technologies' methods for conducting release upgrades

1. The Customer still needs to analyze the collective enhancements to determine which should be integrated into the existing system. UCT business analysts, averaging 27 years in the industry, are qualified to help or lead this effort.
2. Retrofit of the selected enhancements to the customer's version of the system is needed. This is also an area where UCT can assist.
3. With respect to the data migration, UCT would use its Data Conversion Architect (DCA) tool to complete these tasks:
   1. Import the customer's existing version of the Vendor data model into DCA using DCA features
   2. Take the vendor's "base" version of the target release and optionally, add any "deltas" to the target data model based on the results of 5a. and 5b. (above). If some elements are unknown, make a note for future analysis and testing, and continue
   3. Import the target version of the Vendor data model into DCA using DCA features
   4. DCA has built-in functions to support release upgrades and automates the following tasks and more:
      • Produce a data map for each target segment, documenting each detail such as field name, format, length, and valid values.
      • Compare the "starting" and "ending" versions of each segment and element. If there's a complete match on name, data format, and field length, DCA automatically generates the appropriate "move" command in the data map along with mapper documentation noting that there is no mapping required.
      • If no "ending" element is found for an "starting" element, DCA alerts the mapper to the condition. This requires analysis to resolve. Most likely, it's a customer modification to the vendor's release that needs to be added to the target release data model.
      • If field definition changes are found between starting and ending elements, DCA alerts the mapper and tells them what changed and provides suggestions.
      • If no "starting" element is found for a "ending" element, DCA alerts the mapper to the condition. The target field is initialized based on its data definition.
      • A Business Analyst uses DCA to edit the generated maps, preparing them for generation of required programs and testing.
      • On command, DCA generates a complete program to convert the old segment/record to the new formats. These compile without error.
      • Other DCA functions may be used to analyze the source system databases to document and report on values used in the system or to produce other types of data audits, as needed.

   

   5. In addition, DCA can easily be used to provide production-level test data as needed for the code retrofit tasks. Usually, the compilation of test data is a manual effort so due to the substantial time and effort required, complex conditions don't get tested.
4. In addition, DCA can easily be used to provide production-level test data as needed for the code retrofit tasks. Usually, the compilation of test data is a manual effort so due to the substantial time and effort required, complex conditions don't get tested.

In a typical release upgrade, we believe that as much as 70% of the "analysis" and programming related specifically to data migration is automated by the Data Conversion Architect (DCA)

Home | About Us | Data Migration Solutions | FAQ | Products | Contact Us | References | Request Quote