Practical Transformation

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


Agenda



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


Introduction

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


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.


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.


Agenda



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.


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.


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.


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.


Ad Hoc Change

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


Agenda



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.



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.



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.



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.


Agenda



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.



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.



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.



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.



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.



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

http://www.cintegrity.com/content/Request-Expression-Interest




Agenda



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.


Full Model-based Transformation






Full Model-Based TransformationThe Transformation Triangle



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.


Agenda



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?


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.


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.


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


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


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


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!


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.


Agenda



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.



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.



• 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.


Summary and Conclusions

Thank you?Questions?

For more information:http://www.cintegrity.com

[email protected]

http://www.cintegrity.com/

Documents

Practical Transformation