Mainframe Blog

Overcoming TDM Challenges

2 minute read
Bill Clayton
image_pdfimage_print

Parts 1 and 2 of this 4-part series defined TDM, explained why it’s crucial to the success of your organization, and identified key stakeholders. Part 3 covers some of the challenges associated with implementation of a TDM strategy.

 

The challenges of implementing a TDM strategy come in many different forms. Following are some of the more common that I’ve seen.

Corporate Acquisitions. Many of the businesses that I have worked with have been banks, and banks especially have a lot of acquisition activity over the course of their evolvement. Some acquisitions may have happened many years or even decades prior to a TDM initiative and would have brought their own data conversion challenges at that time. Still existing, badly mapped data from conversions may be inevitable. Extensive data sampling needs to be completed as a part of an initiative to enable a strategy to handle this.

Naysayers. Among other roles, users especially, or application testers will express doubts about their ability to do their job if their data is obfuscated. In my years of working on TDM projects I have not come across anyone who was unable to do their job after a planned TDM initiative.

Names and Addresses. There may be many recommendations about what to do with names and addresses. Experience tells me that older enterprises inevitably have some anomalies in this area. Users may believe that all of their addresses on file are “valid,” but that is not usually true. Over time, application dBases will have added columns and tables, and names and addresses will have been keyed in by many different operatives across the business, in different formats. In the past little guidance or validation was employed at entry time and names and address fields often contain “difficult” data.

It is possible that there will be names on address lines, and it is probable that there will be multiple names on some name fields.

Analysis of the data contained in these columns/tables needs to be conducted at the start of a TDM initiative.

Proprietary Compressed Data. Many organizations chose to buy software packages to help run their business processes. Some of these software packages store data in a compressed state and that data needs to be uncompressed where necessary. Working with the vendors of such data may be a part of a TDM initiative.

Related Data and Referential Integrity. Data provisioning needs to be able to obtain subsets of related data on-demand. A subset may be driven by any defined element such as account number, customer number, or a range of numbers. Defining the tables or files needed in the extract should be part of a process and working with SME’s, DBA’s etc. is required. Knowing your data is key!

There are challenges to implementing a robust TDM strategy, but with proper planning and preparation, they can easily be overcome. In the conclusion of the series, I’ll discuss TDM solutions, how they can help you, and the results of implementation.

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.

BMC Bring the A-Game

From core to cloud to edge, BMC delivers the software and services that enable nearly 10,000 global customers, including 84% of the Forbes Global 100, to thrive in their ongoing evolution to an Autonomous Digital Enterprise.
Learn more about BMC ›

About the author

Bill Clayton

Bill Clayton is a Principal Consultant for BMC Compuware. He specializes in Test Data Management and has been with the company for over 20 years. He has worked with many of BMC’s customers in finance, health insurance, and government. Prior to joining BMC, Bill worked in tech for financial and manufacturing organizations in Europe and the USA.