Organizations with legacy IT portfolios frequently face many of the same challenges and often have similar questions regarding modernization. The following are among the most common questions we receive:

1. "How long does a modernization project take? What is a typical ballpark range of cost?"
2. "Can we purchase Trinity's code conversion tools?"
3. "Where does Trinity's team perform the transformation work?"
4. "How can we achieve adequate performance if we move our software off the mainframe?"
5. "Can we continue to maintain the legacy application during the modernization project?"
6. "How is the security of our software protected?"
7. "Our applications maintain highly confidential data. Do you need access to this data to transform the software?"

1."How long does a modernization project take? What is a typical ballpark range of cost?"

Each client situation and project is unique, so effort, timeframe and cost can vary tremendously. The most effective way to establish the size of a modernization initiative is to begin with a Characterization phase to understand the scope and complexity of the application(s). The phases of Trinity's Automation-Enabled Modernization™ process are designed to be executed in sequence. Each phase uncovers additional detail, reducing risk and enabling fixed-price contracting for the next phase.

Trinity can also supply a Quick Quote for clients who require information quickly. This is a way to obtain ballpark price and timeframe information for advance planning purposes.
Top

2. "Can we purchase Trinity's code conversion tools?

Trinity uses an extensive suite of internally-developed source code analysis, conversion, and generation tools as part of delivering our services. These tools are used exclusively in-house by our modernization team members and are not for sale to clients. The primary reason for this is the nature of our process, which involves a mix automated and manual tasks. Our tools are reconfigured for every project to take advantage of the unique software patterns present in each client's source code.

To understand why we do this, assume we have three COBOL applications from different clients. Consider, for example, how the security functionality might be implemented in each. One may use IF statements scattered throughout the programs to determine which users can access which screens, where another application might use a table-driven approach for user privileges. The third application might store security information in a database, or even use a third-party security solution. Since our goal is to re-architect the application, we need to identify and isolate the security functionality (along with other aspects of the legacy application) so we can populate the appropriate part of the new application architecture. Off-the-shelf tools may understand the legacy language syntax, but cannot distinguish between such application-specific variances. Trinity's tool suite is designed to be configured by our team on every project, precisely so we can handle this type of task.

Trinity never charges for the use of our tools on client projects. This is included as part of the service. There are no licensing fees of any kind.

Our tools never insert proprietary routines into generated code. We produce only native source code so clients are able to maintain their new software as they would any new Java or .NET application. There is no vendor lock.
Top

3. "Where does Trinity's team perform the transformation work?"

The bulk our project work is performed in our San Antonio head office location, with on-site work at client locations as required.
Top

4. "How can we achieve adequate performance if we move our software off the mainframe?"

Our clients frequently have specific performance constraints, such as an existing batch run that takes a certain number of hours to execute each night. We have achieved strong results in meeting and exceeding such targets when moving mainframe applications to server-based environments. For example, one daily batch job for a U.S. Federal Government department was reduced from 19 hours to 35 minutes. A number of factors can be used to achieve such results, including for example:

• Identifying inefficient algorithms in the legacy code, which often exist in programs that have been maintained and patched over many years;
• Taking advantage of more highly efficient modern database management system
• Distributing some processing to take place in real-time, thus reducing the amount of work required during batch processes;
• Identifying and removing redundant processing; and
• Performing some activities in parallel.

Each situation is unique. Trinity would be happy to help analyze the opportunities available for your applications.
Top

5. "Can we continue to maintain the legacy application during the modernization project?"

Since Trinity's Automation-Enabled Modernization™ process is partially automated, updates to the legacy source code base can be accommodated with little impact while the automated pattern matching and transformation mapping process is underway. The cost comes when manual programming has been applied to generated code and then the associated legacy source code changes. Manual work can be lost. In our experience, this can be managed effectively. We work with our clients to coordinate our schedules so we tend to avoid conflicts by focusing on different sub-systems at a particular point in time.
Top

6. "How is the security of our software protected?"

Trinity establishes confidentiality agreements to protect our client's interests. Our facilities are highly secure from both a physical and electronic perspective. Physical security at our offices includes multiple layers of secure access doors, camera systems, and exclusive areas dedicated to specific clients upon request. We use secure electronic procedures for transferring software and other client information, and we are our own Internet Service Provider so client data never resides on a third party site. Trinity has been trusted to protect the interests of a wide variety of organizations, including Federal and State government agencies, the U.S. military, banks, and large multi-national corporations.
Top

7. "Our applications maintain highly confidential data. Do you need access to this data to transform the software?"

As with any software development effort, test data is required to support unit, integration, and functional testing. There is no requirement, however, for this to be actual production data. Trinity is able to utilize test data derived in a number of ways, including client's existing test data banks, mock data, or obfuscated data. If migration of the production data is part of the project scope, then arrangements can be made to work with the data under secure conditions acceptable to the client.
Top