Natural Adabas Migration to .NET/SQL Case Study
A major service company has a business critical system developed in Natural Adabas 30 years ago. The client needed to rewrite the system in .NET/SQL the system while adding 30% new business functionality. The conversion was done in approximately nine months. The client got an enhanced system along with documentation, code and automated scripts.
Reasons for re-engineering:
The organization was running the same business process in different geographical regions. Isolated Lotus applications were used to serve each location and there was no central management available. In addition to this, the system lacks the following:
- Cost – Presently the application is running on a mainframe – the only major applications residing on a legacy mainframe. This has significant hardware and software maintenance costs.
- Resources – At this time the client no longer has any of the original application developers in house, and is using contractors for the maintenance of the applications. However, the company has SQL Server DBAs in house, but is not able to utilize them because of technology platform.
- Agility – Natural and Adabas are older technologies and do not have the new features and functions that are available in today’s contemporary platform. As a result the speed at which changes can be made to the existing systems is limited, which in turn limits the ability of the client in the changing market place.
The size of the application
2,229 Natural Programs
1,492 Natural Sub Programs
859 Maps (screens)
531 Data Access
225 JCL Job Streams
18 COBOL Interfacing Programs
The estimated lines of code is over 1,050,000 lines.
Tools Used for re-engineering
To mitigate this risk the existing application’s code was used as a source for functional specifications. However, this task is tedious and to facilitate it, a number of commercially available tools can be used to generate documentation to abstract and allow for “harvesting” of the business logic from the existing source code. One such tool is Natural Engineer from Software AG. These documents are intended to facilitate the capture of the application functionality.
- A base functionality document is required to allow for development of test cases and test planning, and also be a measure of functional completeness.
- When re-modeling or migrating an application you always come across certain constructs or usage of the base language are inevitably encountered that require a view of the whole sub-program to be able to understand and translate it correctly in the target language.
- Automated conversions also rely on “interpretations” of language constructs when mapping one language to another. Again looking at the code or the documentation will validate these “interpretations”. Visionet uses its VisiMigrate parser to parse the code and ESF.NET platform for presentation, security and database layers. The business logic was manually altered and extended to build a N-tier modern system.
Who Did What?
For the effective and timely implementation of the reengineering project, Visionet has identified the following inputs from the client:
Roles & Responsibilities
R = Prime Responsibility
S = Support Role
A = Approval Role
|Data Migration Plan||R||S||S&A|
|Automated Test Scripts||R|
|Hardware Setup & Network||S||R|
|Backup & Archiving||S||R|