Practical Transformation

1. Practical Transformation Thomas Mercer-Hursh, Ph.D. VP Technology Computing Integrity, Inc.

2. Agenda Agenda • Introduction • Ad Hoc Change • Small Incremental Projects • Stepwise Transformation • More Complete Transformations • Impact of Tools • Summary

3. Agenda Agenda • Introduction • Ad Hoc Change • Small Incremental Projects • Stepwise Transformation • More Complete Transformations • Impact of Tools • Summary

4. Introduction Business Drivers • New user interface for new markets • Supply chain integration • SOA requirements from new applications or merger • Rapidly changing business conditions • Regulatory requirements • New business models

5. Introduction Technology Drivers • Maintenance fatigue • Lower costs • Scalability and growth • New systems which need to be integrated • New architectural requirements

6. Introduction While some transformations are time-consuming or expensive, every shop with source code can do some transformation. Even small transformations can improve code quality resulting in lower maintenance costs, greater stability, and easier modifiability.

7. Introduction Large transformations are most efficient with the use of appropriate tools. Small transformations do not need tools beyond those used in ordinary development, they simply need a plan of action and the right mindset. However, the right tools can also make small transformations more efficient and thus allow a greater amount of change for any given budget.

8. Agenda Agenda • Introduction • Ad Hoc Change • Small Incremental Projects • Stepwise Transformation • More Complete Transformations • Impact of Tools • Summary

9. Ad Hoc Change The simplest transformation is to adopt some new standards and apply these to new code or any code needing non-trivial modification. Examples include: • Eliminate Shared Variables. • Moving utilities to persistent or super procedures. • Better and consistent code formatting. • Start using object-oriented constructs.

10. Ad Hoc Change Making small changes like these are not going to transform your application over night, but it is going to make each piece of code you touch: • More readable. • More easily understood. • More easily modifiable. • More stable.

11. Ad Hoc Change Imposing new standards going forward costs little or nothing in lost productivity in the short run and will lead to increased productivity in the future when one has to revisit the improved code.

12. Ad Hoc Change Basic cleanup and modernization of code undergoing modification is simply good programming practice. New code should be written to a current standard, not modeled after 20 year old code. Doing so, will gradually improve the application, if slowly. Not doing so will gradually deteriorate the application.

13. Ad Hoc Change What one wants is a Culture of Transformation, i.e., a mindset of gradually improving any code that one touches.

14. Agenda Agenda • Introduction • Ad Hoc Change • Small Incremental Projects • Stepwise Transformation • More Complete Transformations • Impact of Tools • Summary

15. Small Incremental Projects What are Small Incremental Projects? • Limited projects. • Addresses a small body of code. • Single purpose. • Differ from simple maintenance and modification because they introduce new technology or an architecture shift.

16. Small Incremental Projects Pros of Small Incremental Projects: + Limited projects do not require special budgetary approval. + Minimally disruptive to ongoing operations. + Can introduce meaningful change, gradually, with little incremental cost.

17. Small Incremental Projects Cons of Small Incremental Projects: - Maximum benefit comes only with a strong master plan, but these are not typical unless a stronger commitment to change is made. - Easy for improvements to be patchwork and inconsistent, especially with time pressures. - Can’t deal with structural issues.

18. Small Incremental Projects Principles of Small Incremental Projects: • Identify opportunities. • Control Scope • Define highly manageable, short term bodies of work. • Create satisfaction on making improvement. • Encourage broad participation.

19. Agenda Agenda • Introduction • Ad Hoc Change • Small Incremental Projects • Stepwise Transformation • More Complete Transformations • Impact of Tools • Summary

20. Stepwise Transformation Stepwise Transformation is similar to Small Incremental Projects in that both are project by project implementations, but Stepwise Transformation elevates the master plan to an active program of systematic change. Stepwise transformation usually addresses one primary theme, e.g., move to SOA, but may have secondary design goals.

21. Stepwise Transformation Typical Pattern of Stepwise Transformation • Identify need and commit to plan. • Identify one or two high ROI projects. • Implement new technology on those projects. • Identify more high ROI projects and implement. • Periodically assess when it is appropriate to complete changes for a subsystem.

22. Stepwise Transformation Pros of Stepwise Transformation: + Requires only a modest increase in budget. + Only one function disrupted at a time. + Substantial change possible over a few years. + Clear plan makes for systematic change.

23. Stepwise Transformation Cons of Stepwise Transformation: - Requires a solid initial plan. - Single focus often leaves other aspects unaddressed. - Easy to get off track if not careful. - Doesn’t fix anything not in the plan.

24. Stepwise Transformation Stepwise Transformation Summary: + Budget commitment is modest. + Substantial change is possible with a good plan. + Ideal for orderly progression of projects - Requires continuing vision and direction. - Doesn’t fix everything.

25. Stepwise Transformation Iterative Transformation • Term coined for the use of a tool to improve a code base over time, one step at a time. • Differs from Stepwise Transformation in focusing on language elements, not technology • The tool exists, but needs adaptation to ABL. See http://www.cintegrity.com/content/Request-Expression-Interest

26. Agenda Agenda • Introduction • Ad Hoc Change • Small Incremental Projects • Stepwise Transformation • More Complete Transformations • Impact of Tools • Summary

27. Single Focus Complete Transformation “Single Focus” Complete Transformation is like Stepwise Transformation except that one does it “all at once” and there is often more consideration of secondary themes. Often a classic brute force major rewrite, it is typically motivated by a dramatic business need, such as the need for a new UI on an AP’s package for competitive reasons.

28. Full Model-based Transformation

29. Full Model-based Transformation

30. Full Model-based Transformation

31. Full Model-Based Transformation The Transformation Triangle

32. Full Model-based Transformation Model-based Transformation: + Result is a fully modern application which can continue to adapt to both new business needs and architectural changes. - Cost is high because it is not possible to build the models only from code, and tools are still in a fairly early state of development.

33. Agenda Agenda • Introduction • Ad Hoc Change • Small Incremental Projects • Stepwise Transformation • More Complete Transformations • Impact of Tools • Summary

34. Impact of Tools We have a couple of strategies with modest costs, but they also have modest results – significant over time, perhaps, but far from complete. Or, we have strategies which deliver substantial results, but with substantial costs. Isn’t there something a bit better?

35. Impact of Tools No silver bullet or magic transformer, but yes, there are existing tools that can help and tools that can be created to help. Tools automate what would otherwise have to be done by hand, saving money, and/or improving quality and thoroughness, sometimes in ways that no amount of labor could produce.

36. Impact of Tools Relevant tools come in four main categories: • Analysis – understanding current code. • Refactoring – automated point changes of current code. • Program generation – many alternatives for not having to write every line by hand. • Transformation – changing information from one form to another.

37. Impact of Analysis Tools Analysis tools help us to figure out the current code and can be helpful no matter what the scope of the project: • XREF • “SuperXREF” • Joanju Analyst • ABL2UML • Task-specific tools

38. Impact of Refactoring Tools Refactoring tools help to make gradual, but potentially widespread improvements in the existing code making it easier to work with, easier to understand, and easier to transform: • ProRefactor • UML roundtripping • Translation engines

39. Impact of Generator Tools Program generation • Automate the predictable • Automate what can be described abstractly • Any type can help, but regeneratability makes a world of difference. • Provides perhaps the single biggest productivity potential. • But, takes substantial up front investment

40. Impact of Generator Tools Specification Driven Development - An old example • 2 Interrelated modules of new code. • A lot of routine functions, but far from trivial. • 2 programmers part time over 3 month. • 300,000 total lines of ABL in the result. • Average production 1000 lines of ABL per programmer per hour!

41. Impact of Transformation Tools Transformation tools are ones which change the code sufficiently that one has made a qualitative change as well as a quantitative or specific change. Sufficient refactoring approaches transformation. The ultimate form is Model-Based Development (MBD) including Model to Model transformation.

42. Agenda Agenda • Introduction • Ad Hoc Change • Small Incremental Projects • Stepwise Transformation • More Complete Transformations • Impact of Tools • Summary

43. Summary and Conclusion We have talked about five or six main strategies. They vary in budgetary commitment and the degree of modernization accomplished. The best strategy for any one company will depend on business needs and long term goals.

44. Summary and Conclusion Common to all strategies is the need for a clear vision of the goal and a deep understanding of the technology, techniques, and tools which can be used to accomplish that goal. If you have the vision and understanding to know that you want modernization, but not how to get there, get help. It’s cheaper.

45. Summary and Conclusion • Modernization is perhaps the biggest challenge facing legacy ABL systems. • Code which used to work is turning into a liability. • Legacy systems can’t respond rapidly to changing business conditions. Some form of modernization should be on everyone’s mind.

46. Summary and Conclusions Thank you? Questions? For more information: http://www.cintegrity.com Thomas@cintegrity.com