UCT's Data Migration Solutions

We use DCA to automate the steps of a carefully defined lifecycle

Data Conversion Architect (DCA) is UCT's data conversion tool. It is a web-based collaboration tool with a number of critical features and components that automate parts of the conversion system development lifecycle. It is important to note that DCA does not perform a conversion; no customer data is loaded into DCA. Instead, DCA's role is to aid the team as they develop a separate "conversion system" - a program(s) that converts data from one system (the source system) to another system (the target system).

4GL to 3GL conversion turns Business Analysts into Programmers

DCA's primary role in the development of the conversion system is as a 4GL to 3GL converter. It accepts and stores conversion logic from the Business Analysts (BA) that is expressed in a natural form, like "move field-1 to field-2," and generates code modules that can be compiled and executed on the platform that will host the conversion (usually either the source or target platform). As the BA creates the conversion logic using the 4GL "mapping language" they periodically validate it to produce the more complicated 3GL code modules. This has a significant advantage over other conversion solutions because it gives the BA the ability to improve the conversion logic and resulting conversion module without involving a programmer – a key differentiator between DCA and other ETL products. The programmer only develops the driver, which calls the modules produced by the BA through DCA, and the I/O modules needed to move data into and out of the source and target systems. The BAs develop the conversion modules using DCA. The mapping language not only has commands that support conversions but it also includes commands that perform auditing, report errors, do balancing, and many other tasks.

DCA utilities are reused by the programmers

Within DCA are a suite of "utilities" that exist to support the programmer who is developing the driver that calls the conversion modules. These utilities can do a variety of things. One of the utilities that is commonly referred to as UCT Messaging, is used to standardize the messages that are generated by a map module or other part of the conversion system. Another utility is used to create formatted Excel reports from the standardized messages. Other utilities can be invoked from map logic to do bit-level processing or load run-time conversion tables that are defined inside DCA.

Testing intentionally starts early

When the conversion logic in the data maps has reached an acceptable level of maturity, the testing cycles can begin. Within the UCT conversion system development lifecycle, the intent is for conversion system testing and source system auditing to start as soon as possible. UCT's solution makes this happen by disassociating conversion module development from driver and I/O module development. With DCA being used by the BAs to develop the conversion modules, these activities can occur concurrently. It is important to start testing early because it is not possible to fully understand the development requirements in advance as it is with some types of software development projects. UCT has learned that there are always data anomalies and that the sooner the data anomalies are detected, the easier they are to deal with and the more time all parties have to resolve complicated data issues.

DCA features evaluate conversion success

Once testing begins, DCA provides features that collect the error messages and perform success evaluation. The generated code modules and drivers are set up by the BAs and programmers to trap and report conversion errors from I/O failures to data format problems. Whenever an error is detected, a message is generated and collected by UCT Messaging. These messages each specify an "owner" or the person responsible for handling the issue. Features in DCA process the collected messages and the results from previous tests can be compared to the new results to see how the logic is improving. The DCA Reporting feature allows team members to drill down into the message data to understand the root cause of a problem. The UCT BA Spreadsheet feature formats Excel reports from the messages that include summaries and reports by user, by policy, or by map.

Some maps are automatically generated by DCA

Finally, DCA features provide the ability to create complete maps of a particular type. In many conversions, it is common to evaluate incoming source data either before or during a conversion. The UCT lifecycle calls this "auditing" and DCA can automatically create complete audit maps and auditing code modules. Another common task that happens after the conversion is “balancing”. One form of balancing is to extract converted data before it is loaded into the target system and then compare it to the same data after it is loaded. DCA features can automatically create maps and balancing code modules to perform this kind of balancing.

DCA is essential to data migration success

Many if not all of these DCA features are expected to be used as required during the Source system to target system conversion. DCA will turn conversion logic expressed by the BAs into source code without the help of the programmer. As a result, the BAs will be more effective in their efforts.

Programmers will focus on I/O and the overall driver and work concurrently with the BAs. Testing and data anomaly detection with begin earlier and there will be more time to address the unexpected.

Balancing and auditing will be conducted to ensure that data meets expectations and is converted correctly. The conversion, auditing, and balancing data maps that are used in DCA to collect the logic can be exported from DCA as text files and reviewed or archived for posterity. When this time saving application is combined with experts and a proven lifecycle it ensures a successful conversion.

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