practical transformation
Post on 25-Feb-2016
22 Views
Preview:
DESCRIPTION
TRANSCRIPT
Practical Transformation - 1© 2013 Computing Integrity, Inc.
Practical Transformation
Thomas Mercer-Hursh, Ph.D.VP Technology
Computing Integrity, Inc.
Practical Transformation - 2 © 2013 Computing Integrity, Inc.
Agenda
Agenda• Introduction• Ad Hoc Change• Small Incremental Projects• Stepwise Transformation• More Complete Transformations• Impact of Tools• Summary
Practical Transformation - 3 © 2013 Computing Integrity, Inc.
Agenda
Agenda• Introduction• Ad Hoc Change• Small Incremental Projects• Stepwise Transformation• More Complete Transformations• Impact of Tools• Summary
Practical Transformation - 4 © 2013 Computing Integrity, Inc.
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
Practical Transformation - 5 © 2013 Computing Integrity, Inc.
Introduction
Technology Drivers• Maintenance fatigue• Lower costs• Scalability and growth• New systems which need to be integrated• New architectural requirements
Practical Transformation - 6 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 7 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 8 © 2013 Computing Integrity, Inc.
Agenda
Agenda• Introduction• Ad Hoc Change• Small Incremental Projects• Stepwise Transformation• More Complete Transformations• Impact of Tools• Summary
Practical Transformation - 9 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 10 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 11 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 12 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 13 © 2013 Computing Integrity, Inc.
Ad Hoc Change
What one wants is a Culture of Transformation, i.e., a mindset of gradually improving any code that one touches.
Practical Transformation - 14 © 2013 Computing Integrity, Inc.
Agenda
Agenda• Introduction• Ad Hoc Change• Small Incremental Projects• Stepwise Transformation• More Complete Transformations• Impact of Tools• Summary
Practical Transformation - 15 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 16 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 17 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 18 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 19 © 2013 Computing Integrity, Inc.
Agenda
Agenda• Introduction• Ad Hoc Change• Small Incremental Projects• Stepwise Transformation• More Complete Transformations• Impact of Tools• Summary
Practical Transformation - 20 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 21 © 2013 Computing Integrity, Inc.
Stepwise Transformation
Typical Pattern of Stepwise Transformation1. Identify need and commit to plan.2. Identify one or two high ROI projects.3. Implement new technology on those projects.4. Identify more high ROI projects and
implement.5. Periodically assess when it is appropriate to
complete changes for a subsystem.
Practical Transformation - 22 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 23 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 24 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 25 © 2013 Computing Integrity, Inc.
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
Practical Transformation - 26 © 2013 Computing Integrity, Inc.
Agenda
Agenda• Introduction• Ad Hoc Change• Small Incremental Projects• Stepwise Transformation• More Complete Transformations• Impact of Tools• Summary
Practical Transformation - 27 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 28 © 2013 Computing Integrity, Inc.
Full Model-based Transformation
Practical Transformation - 29 © 2013 Computing Integrity, Inc.
Full Model-based Transformation
Practical Transformation - 30 © 2013 Computing Integrity, Inc.
Full Model-based Transformation
Practical Transformation - 31 © 2013 Computing Integrity, Inc.
Full Model-Based TransformationThe Transformation Triangle
Practical Transformation - 32 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 33 © 2013 Computing Integrity, Inc.
Agenda
Agenda• Introduction• Ad Hoc Change• Small Incremental Projects• Stepwise Transformation• More Complete Transformations• Impact of Tools• Summary
Practical Transformation - 34 © 2013 Computing Integrity, Inc.
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?
Practical Transformation - 35 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 36 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 37 © 2013 Computing Integrity, Inc.
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
Practical Transformation - 38 © 2013 Computing Integrity, Inc.
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
Practical Transformation - 39 © 2013 Computing Integrity, Inc.
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
Practical Transformation - 40 © 2013 Computing Integrity, Inc.
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!
Practical Transformation - 41 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 42 © 2013 Computing Integrity, Inc.
Agenda
Agenda• Introduction• Ad Hoc Change• Small Incremental Projects• Stepwise Transformation• More Complete Transformations• Impact of Tools• Summary
Practical Transformation - 43 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 44 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 45 © 2013 Computing Integrity, Inc.
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.
Practical Transformation - 46 © 2013 Computing Integrity, Inc.
Summary and Conclusions
Thank you?Questions?
For more information:http://www.cintegrity.com
Thomas@cintegrity.com
top related