Introduction to Advantage TransForge

1. Introduction to Advantage TransForge Data Management and Application Development Session Code: DAO25SN

2. Agenda • Introduction • Software Modernization Options • The Business Case for Transformation • Introducing TransForge • CA Transformation Services • Transformation Success Story • Q&A

3. Legacy Application Facts • Many legacy applications do what they were designed to do! • Functionally adequate • But, they are…. • Not in modern packaging • A long-term support liability • Difficult to integrate with other systems and technologies

4. The Legacy Problem Modernize ? Redeploy Extend ? Integrate

5. Application Goals • Modernize: Move our systems from legacy to object-oriented, graphical, web enabled, “e” infrastructures • Open: Allow systems to interface with other software and repositories • Scale: Dramatically extend our system’s reach and audience • Extend: Easily add new or modify existing functionality

6. SoftwareModernizationOptions

7. Modernization Options Which is best? How long will it take? ? How risky is it? Will we succeed? What are we forgetting? How much will it cost?

8. Pros Get what you want Evolutionary Most “comfortable” Cons Scope creep Most expensive Time consuming Highest risk Option 1: Rewrite Ground up rebuild in a new architecture using new technologies.

9. Pros “Mainstream” Get you out of the software business Cons Very expensive Difficult to implement Might only meet 50%-80% of needs Option 2: Replace License one or more commercial “off the shelf” package(s).

10. Pros Can be fast to implement Easy to deploy Reasonable “interim” solution Cons Can be slow to implement Not free Doesn’t solve the legacy problem Option 3: Redirect Project the existing application through a browser or other GUI

11. Pros Solves the problem Faster and cheaper than rewrite, replace Maximum ROI on prior investments Cons Confusing conversion with transformation Other vendors offerings Option 4: Reincarnate Mine the logic, workflows and interfaces and transform them into a modern software environment

12. Sample ABF Application • Application: • Components: 800 frames, 400 procedures • Source: 300,000 statements • Database: 250 tables, 2500 columns • User Base: 2000 end-users • IT Staff: Five developers • Installations: 3

13. Ground Up Rebuild 1 "Estimating Software Costs," William H. Roetzheim, CEO, The Cost Xpert Group, June 2000 2 BusinessWeek OnLine's 2000 Salary Survey calculated the "Mean Base Salary for Companies with Revenue of $5 Million [for companies in the United States]" of a "Computer Programmer (1)" to be $49,900. Adding a benefits/overhead multiple of 1.5 and dividing by 12 yields an average monthly cost of $6,237.50 (US). 3 The COCOMO II method of software estimation is often used for new development projects. An organization considering a "ground up" replacement of a legacy application may want to discount the COCOMO cost estimate because most of the requirements and design have already been performed. This is offset by the fact that building a graphical user interface (GUI) application typically results in a dramatic increase in the number of lines of code. This is due to the increased number of user interface events that must be programmed. A reasonable comparison, therefore, would both discount the Linear Productivity Factor and simultaneously increase the KSLOC. The net result will be very close to the estimate shown above. While the above equation is very simple, the estimate is fairly accurate (within 10%) because the KSLOC, the single largest contributing factor to the equation, is known.

14. Consequences of Rebuild • Time, Labor and Money • 36 people • 2+ years • Opportunity Cost • What business was lost in the interim? • Does the staff face “magic pitcher syndrome”? Do The Math!! 882 labor months / 12 months per year = 73.5 labor years / 36 people = 2.04 calendar years

15. Other Barriers • Infrastructure Requirements • New hardware • New software • Collateral Projects • Correcting past “mistakes” • Adding a “few” enhancements • Database conversions/upgrades • Phase in/phase out costs Consequences • Scope • Cost • Time • Risk

16. Today’s Needs Solutions that reduce risk… produce results quickly… and don’t break the bank.

17. The Business Casefor Transformation

18. What is Transformation? • Transformation is a strategy for modernizing applications using: • Automated processes to perform bulk translation, conversion, and restructuring of legacy components • Manual efforts to reconstitute the components back into a functioning application

19. Transformation I/O • Inputs: • A legacy, procedural software application with a character interface • User customization options • Outputs: • A modern, object-oriented system with a graphical user interface • Functional equivalent of the original system

20. Automated Processes • Mining of the legacy application’s structure, components and source • Analysis of the system • Customization of the transformer • Restructuring of the system architecture, interfaces and language constructs • Regeneration of the components in and object-oriented, GUIcontext

21. Manual Efforts • Addressing 1%-5% of the application’s source that could not be transformed • Implementing solutions for host dependencies and unusable 3GL • Replacing menuing/adding new features • Testing, documentation, training and deployment of the new application

22. Transformation… • Is the fastest, lowest cost, most reliable way to modernize software • Is not a one-for-one translation of the original system • Does not change the application’s flow, logic or database structures

23. ApplicationServer PCs runningtransformed Client/ServerApplication Browser Enabled Clients Benefit: Parallel Rollout Unix/VMS/NT Host

24. Benefit: Use Existing Servers • Current “host” becomes “database server” • Transformed application runs against current database • DBMS upgrade NOT a requirement • Reduces initial hardware costs • Streamlines deployment timeline • Potential host performance increase!

25. Benefit: Shortened Timeline • Transformations occur in weeks or a few months, not years • Allows organization to focus on staff skill development and training • No functionality reductions often common in rewrite scenarios • No lost business opportunities

26. Benefit: Highly Scaleable • Transformed application is “multi-modal” • Client/Server (2-tier) • Application Server (3-tier) • Facilitates evolutionary migration to Application Server technology • Enhances scalability and interoperability • Eases deployment • Supports alternative client interfaces

27. Benefit: “e” Enabled • Business logic can be Web enabled • Complete infrastructure for implementation of browser enabled functions • Opportunity for external interfaces • Possible to integrate with other tools and systems

28. IntroducingTransForge

29. CA’s Transformation Solution Advantage OpenROADApplication Advantage IngresABF Application TransForge

30. What is TransForge? • Patent-pending software modernization engine • Transforms procedural systems to objects • Upgrades character interfaces to GUIs • Restructures and reformats code • Customizable to specific requirements • Powers CA’s Transformation Services • Groundbreaking transformation technology • Provides rapid, low-risk, cost effective software modernization

31. Frame Transformation Advantage Ingres ABF Frame/VIFRED Form Advantage OpenROADFrame Advantage OpenROAD User Class

32. Frame Transformation

33. Other Components

34. CA Transformation Services

35. Who Delivers Transformations? • CA TransForge Centers of Excellence • Specially trained CA Services groups • TransForge, Advantage OpenROAD Certified • Proven delivery capability • Contact CA Services for: • Specifics on ABF Transformation offerings • Application Analysis service

36. Application Analysis • First stage of a TransForge project • Initial meetings, gauge suitability • Analysis of ABF applications • Discuss customisations • Quotations for: • Automatic Transformation • Application Delivery • Timescale - should be around 2-4 weeks

37. Automatic Transformation • Automatic Phase • ABF to OR transformation • Includes client specific “customizer” • making global modifications to • frames and source code • Produces: • ABF components transformed into Advantage OpenROAD objects • Customized transformed GUI

38. Application Delivery • Manual Phase • Extend the custom Transformation • Modernise the user interface • Test, document and deploy • Other services as required • Produces: • A working, customized, modernized, Advantage OpenROAD application • Client/Server or App Server architecture • Browser deployment of some or all application functions

39. Transformation Services Success Story

40. Background • Galaxy is a library management system sold by DS Ltd to UK public authorities • Galaxy is a “best selling” product - to over 30% of UK public library authorities • Galaxy has received many accreditations for its quality and functionality

41. Galaxy Functionality • A range of applications based around a catalogue (database) of library stock records • Up to hundreds of concurrent users • Supports thousands of library patron transactions per hour • Traditionally using non-GUI interface • hundreds of ABF screens

42. OpenGalaxy Requirements • Need to move from ABF screen environment to GUI environment • Need to retain existing functionality • Migrate the system architecture to meet future needs • Enhanced speed of development

43. Project Overview • The purpose – to efficiently implement a Windows GUI for Galaxy applications • The Framework – joint partners with CA in undertaking a cooperative project • Deliverable – a Galaxy system with new GUI and all existing functionality

44. Phase 1 • Project Charter and Workshop • Preparing a sample of our application • Set up OpenROAD environment at DS and ensure staff are suitably trained • Preparing for working together • Transforge customisation workshop • Transformation itself

45. Phase 2 • Primarily managing: • the 3GL and 4GL code • the utilisation of application code within the Advantage OpenROAD OO framework • getting the applications running again • Resource intensive • Teamwork

46. Phase 3 • A DS-only phase • Allow for some support from CA • Internal agreement on house-style • Full internal testing • Product readiness

47. So … Did it Work ? • Yes • It worked because of the level of commitment • It worked because the framework was clearly defined • It worked because both sides wanted it to work

48. ...allows DS to… • Further develop Galaxy in GUI environment • Move to object oriented architecture • Have highly computer generated consistent code • Develop all parts of Galaxy rapidly, using a 4GL • Implement an Application Server architecture • Move towards a thin-client approach.

49. Galaxy demo (before)

50. OpenGalaxy demo (after!)