| Migrating technologies AND people. |
| |
| Short Description |
| |
| With SmartEGL, comprehensive and complex Natural applications can be securely and quickly migrated to EGL (Enterprise Generation Language) through a rule-based converter. In turn, the migrated applications can be made available as Java/J2EE or Cobol apps and executed in a variety of environments without having to make any further changes. By migrating to one language (EGL), two target languages (Java and Cobol) alike are handled. |
| |
| EGL is a fourth generation programming language (4GL) and exhibits a high degree of similarity to Natural. It is geared to developers of business processes and frees the application developer from the ever-increasing technical complexity. |
| |
| The paradigm break from object-oriented development and procedural development can be totally avoided through the use of EGL. The EGL and SmartEGL concepts guarantee a high degree of productivity and serviceability of the migrated Natural code, especially for developers with procedural experience. And not only do they make it possible to migrate technologies, but people are also migrated and accompanied step-by-step into the new world. |
| |
| The Situation - Arguments: |
| |
Technology migration and comprehensive modernization is indispensable over a mid to long
term |
| |
Only with great diffi culty can application development in Natural meet short-term, quickly
changing demands |
| |
Natural is not a universal programming language but is entirely bound to Adabas |
| |
Parallel application development – some Natural here, some Java there, no uniform processes |
| |
Insuffi cient interoperatibility between Natural and other programming languages (only through
purchasing additional products from Software AG, EntireX) |
| |
High costs for maintenance and upgrades of Natural runtime or relicensing after a platform
switch (rehosting) |
| |
High degree of dependency on Software AG and its technologies |
| |
| Questions: |
| |
Can you fulfi ll all of the specialized and technical demands within your required timeframe
with
Natural, without any additional products from Software AG? |
| |
What plans have you already developed for making the technological switch away from Adabas
and Natural? |
| |
Have you already considered redevelopment or a replacement with standard software? |
| |
Have you already considered a transformation of your existing applications in this regard? |
| |
What chances do you see for migrating your existing development staff from Natural to e.g.
Java? |
| |
Can this be achieved by everyone? With the same degree of high productivity? |
| |
How high are the friction losses due to different development environments and processes at
your company? |
| |
What would you have to annually budget for upgrading and maintaining your Software AG lands
cape? |
| |
| Uses and Key Features |
| |
Natural applications are automated with a high degree of coverage and migrated to EGL with a
rule-based converter |
| |
Automatic encapsulation of access layer, business process logic and user interface |
| |
EGL code very similar to Natural code |
| |
Availability of Natural-like access statements and corresponding SQL as source code |
| |
Direct availability of new user interface (web and/or Windows) through XML-based client
technology |
| |
High maintainability of the transformed EGL code – even and especially for procedurally
experienced developers (COBOL, Natural, etc.) |
| |
Same high degree of productivity in software development from the fi rst day on |
| |
More inexpensive and faster than redevelopment or adoption of standard software |
| |
| Target Group |
| |
| Any company that has developed or is developing proprietary applications based on Natural, regardless of its line of trade. Initial considerations have already been made as to whether the apps should be replaced by a redevelopment or by standard software. |
| |
| Distinguishing Features |
| |
With the transformation from Natural to EGL, the break from procedural development to object-oriented development can be totally avoided through the use of EGL. Investments in the application and existing staff are totally protected. The maintainability of the EGL code and the productivity of Natural developers are signifi cantly higher in comparison to any other programming language. Thanks to its Natural-like constructs and access statements, the EGL language is closer to Natural than any other comparable solution.
After transformation, all database access can still be coded in a Natural-like syntax (Read, Find, Histogram, Update, Delete, etc.) for which the corresponding SQL code is then generated as a freely accessible source in access libraries. With the exception of the statement level, every developer can decide whether database access is to continue to be coded Natural-like or with SQL. The transition from Natural to SQL can therefore be individually controlled by each developer. All available EGL and SQL objects are also made available in the source code,
making runtime components (and thus dependency on a vendor) a thing of the past. |
| |
| Further Information |
| |
| Pricing: |
| |
| Prices are based on the size and complexity of the application to be migrated. A fl at rate for the migration project is calculated after an analysis of the application and database is conducted. There are no maintenance fees or runtime licenses (exception: use of the Xi client). |
| |
| Contact: |
| |
PKS Software GmbH
Georgstr. 15
88214 Ravensburg
Germany |
Mr. Karlheinz Peter
+49 751 56140-221
Contact
|