Abstract:
"It's Not Magic," an essay on the design of
automated modernization projects.
Abstract: When there is residual value in a legacy
application, an automated modernization project can extract and use
that value in a highly cost/effective manner. Of course, in some
cases this is futile, but in many if not most projects it has
significant technical and financial merit. There are 3 important
technical strategies:
- When the business rules expressed in a legacy system still
fit the business process, but have a problem with software
infrastructure (e.g., database, "green screen" interface,
language, hardware platform, etc.), there is usually a fast,
cheap and low risk way to deal with the problem, applying
technology to renovate the code base into supporting the target
configuration.
- When legacy systems partially fit the current business
process but need significant functional expansion or
modification, a re-engineering approach may make more sense.
This way the original system is reproduced identically in
totally new technology, then re-factored according to agile
principles to meet the new requirements. Though counterintuitive
to some, this approach is faster, cheaper and lower risk than
taking a blank sheet of paper and starting over - because at
every point in the project you have a fully functional system.
- When maintenance costs are high in a legacy application, it
is possible to logically restructure the application to reduce
the effort of maintenance programming. This is usually very
cost/effective. Depending on how bad the code is, maintenance
cost reductions of as much as 40% are possible, though this
approach has the best results for the worst systems.
In the 3 cases known to us of a replacement/rewrite project
experiencing a catastrophic failure, this approach would have
avoided that result as well as saving a ton of money. Fortunately,
catastrophic failures are rare. For more common are cost overruns
and projects that are cancelled well before reaching catastrophic
proportions. Leveraging legacy assets to break a project into small,
manageable chunks is an inexpensive way to assure on time/on budget
delivery.
Abstract:
"From Legacy to BPM", Cutter Consortium Enterprise Architecture
Service Executive Update, Volume 8, number 21-22, November, 2005.
Complementary copy available after registration from:
http://www.cutter.com/offers/legacyBPM.html
Abstract: Replacements for existing systems fail or
experience substantial cost/delivery time overruns because of a
failure to appreciate the formal complexity of the problem, and
therefore fail to derive practical risk mitigation procedures. Most
attempts to address this fundamental failure fall into the category
of doing the same thing again, only more so.
The theory behind this article takes an obvious but usually
overlooked point: the system being replaced, whatever its faults or
shortcomings, nevertheless works. We recommend that, first,
technological leverage be applied to introduce global changes to the
application that will result in demonstrably identical functionality
but resting on a modernized software and hardware infrastructure.
Then, second, we recommend applying the underlying principle of
agile programming and project management methodologies: make small,
incremental changes that can be controlled and - most importantly -
will always demonstrate a working system at the end of each short
development cycle.
Baby steps will get you where you want to go faster, safer, and
probably cheaper than giant leaps into the unknown.
|
