Suite 1790 T 604.738.4999
Enhancements as Modernization Drivers
Application Enhancements can be defined as:
“The constant stream of small changes that occur as the business adjusts to
changes in the marketplace, to regulation and compliance, and to growth (or
shrinkage) in parts of the business” (John Parkinson).
As legacy systems change and evolve over time, application knowledge is lost through staff turnover and system and documentation becomes out-of-date; these mission-critical systems become increasingly opaque and intolerant to change. Key systems essentially become “Black Boxes of Intellectual Property (IP)”.
New enhancements to older systems - even those perceived as relatively simple changes in functionality - can re-quire significant design, development and testing effort to implement. For example:
A large Canadian jurisdiction wanted to introduce a lower cost “Green” license plate as an incentive for owners of hybrid vehicles. However, when the IT organization assessed the time and costs to make these changes in their ex-isting 30+ year old system, their best estimate was 1 year plus costs of $1.2M.
As a result, many organizations reject or defer making changes to these systems, creating a backlog of pent-up busi-ness demand for enhancements. The inflexibility of these “frozen” legacy systems often forces busibusi-ness users to create their own “tribal” solutions to augment and extend the useful life of these core business systems, including: undocumented manual procedures; spreadsheets; local databases; and repurposing obsolete data fields to store currently business-relevant information.
Eventually, the need for business-critical enhancements which cannot be delivered with the current system or systems becomes a key business driver for modernization. Unfortunately, the inclusion of enhancements within a modernization project can significantly affect the risk profile of the project, depending on the nature/impact of the changes and their implementation strategy.
It’s not to suggest that enhancements should be avoided during modernization, as it ignores the mission-critical nature of replacing these core business systems. However, the impact of enhancements needs to be understood and managed, in order to appropriately balance business priorities with organizational risk tolerance.
The Good: Modernized System as the Foundation for Change
There are a number of alternative modernization strategies. Some strategies are best used to extend the life of legacy systems, including: SOA-wrapping; automated code conversion; and re-hosting. Meanwhile, other strategies are designed to retire and replace the legacy environment, such as Commercial Off-the-Shelf (COTS) package
re-portfolio modernization strategy.
COTS work well for implementing commodity functionality, or when the organization is prepared to change their business processes to fit the package (for example, implementing accounting systems or enterprise reporting solu-tions). Re-architecture is best suited for retiring applications or application components that remain business-rele-vant, differentiate the organization, and when the organization is unwilling or cannot change their business processes to fit a package (for example, competitive differentiation or legislative compliance).
The value of re-architecture is the ability to harvest intellectual capital from the existing legacy system, and refactor this Intellectual Property (IP) into a well structured modernized system that provides higher service levels, has lower costs of operation, and can be further enhanced to meet emerging business requirements with lower costs & risks than the existing legacy system.
A properly re-architected system can provide a solid foundation for the implementation of new business require-ments. Based on our experience modernizing a number of legacy technologies, refactoring business-relevant func-tionality while eliminating obsolete funcfunc-tionality and legacy-specific code can result in a significant reduction (60% to 80%) in the size of the modernized code base necessary to support the business (measured as lines of code). This reduction in the size of the modernized code base, plus the improved structure and documentation of the modern-ized system, makes it easier to implement new business requirements and lowers the risks and costs of mainte-nance.
The Bad: Enhancements as Game Changers
A major consideration of including enhancements within a modernization project should be whether the behavior of the modernized application with enhancements, could be effectively tested and validated against the legacy applica-tion. Be aware; inclusion of significant enhancements during the modernization process that change the behavior of the new application is a potential game changer, which may significantly increase risks and costs to the project.
A key assumption of re-architecture approaches is that the legacy system is still business-relevant and that key busi-ness requirements can be traced to and validated against logic coded into the legacy system. Consequently, detailed design specifications may not be necessarily required to support the refactoring effort, as the legacy code contains a detailed working specification. This eliminates significant effort during the re-architecture process and reduces the cost and risk of modernization, when compared to “Greenfield” (new system) development. In addition, testing of modernized code components can be streamlined through utilization of innovative techniques such as Differential System Testing (DST) when verifying the equivalence of the modernized component to the legacy component.
In contrast, enhancements require incremental analysis, design and specification, as they cannot be traced to the legacy code. In addition, testing strategies and plans need to be developed that can reconcile/validate the differ-ences in behavior between the enhanced modernized system and the legacy system.
Architectural Upgrades & Streamlining vs. Enhancements
It’s important to understand that there are a number of improvements that are routinely introduced during the mod-ernization process that are not enhancements and have minimal or manageable impact on the project’s risk profile. These improvements can be described as: Architectural Upgrades and Streamlining.
Architectural Upgrades are implemented as a benefit of moving from a legacy technology stack to a modern technol-ogy stack. Examples of Architectural Upgrades include: the creation of a multi-tiered technoltechnol-ogy stack (e.g. separat-ing Presentation, Service and Data layers); creation of reusable Services (SOA); implementseparat-ing a standard security framework; Internationalization (multi-lingual support); creation/tailoring of a rich Graphical User Interface (GUI) with intuitive navigation; and modernizing data structures from a legacy data store to a modernized relational DBMS.
Streamlining is defined as simplifying the system and reducing complexity. Examples of Streamlining include: con-solidation of screens to simplify business processes; creation of drop-down lists (to replace legacy codes); on-line data validation to replace batch processes; field-size changes; simplified access to data; and transformation of embedded data structures.
Enhancements as defined in this article, include: adding new business processes & transactions; changing (trans-forming) existing business processes & transactions; and creating system interfaces to new or modernized applica-tions.
Avoiding the Ugly: Best Practices for Managing Enhancements
1. Build Your Foundation:
• Decide where you’re going.
• Clearly communicate your System Vision.
• Design your architecture to support your System Vision, particularly your data architecture. • Include enhancements when developing your future case requirements & design, even if
de-ferred to a later release.
2. Know What’s Important:
• Prioritize your requirements balancing business priorities with risks.
• Be prepared to re-prioritize and/or defer higher-risk or lower priority requirements to a later release.
3. Continuously Manage Your Risks:
• Assess the impact of enhancements with regard to whether the modernized system can be easily tested and reconciled to the legacy system using techniques such as Differential System
º Adding new business processes & transactions that DO NOT IMPACT the ability to test sys-tem equivalency versus changing (transforming) existing business processes & transactions that DO IMPACT the ability to test system equivalency.
º Defer implementing enhancements to a later release that impact your ability to test equiva-lency between the legacy and modernized system, when possible.
Remember, it’s generally lower-risk, faster and more cost-effective to introduce changes in a well-structured and well-documented modernized system, which may have a code base that’s only 20%-30% the size of the legacy system.
• Develop appropriate Test Strategies and Test Cases.
• Use DST to test equivalency between systems whenever possible.
• Minimize re-work during the Modernization Process (touch the code once). • Avoid introducing changes late in the Modernization Process.
Conclusions
Core business systems are organizational assets that evolve over time to contain significant intellectual property (IP). However, as application knowledge is lost through staff turnover, and system documentation becomes out-of-date, these mission-critical systems become increasingly more difficult, higher risk, and more costly to change.
Eventually, many organizations reject or defer making changes to these systems, creating a backlog of pent-up busi-ness demand for enhancements. In response, busibusi-ness users often create their own “tribal” solutions to augment and extend the useful life of these core business systems.
Eventually, the need for business-critical enhancements that cannot be delivered with the current systems becomes a key business driver for modernization.
Modernizing these business-critical legacy systems can be a low-risk and cost-effective solution to conserving criti-cal organizational IP, when managed and delivered by an experienced modernization partner using a proven, fit-for-purpose approach.
Make Technologies is your key to a successful application portfolio transformation. Make Technologies® Enterprise Suite is an end to end solution for application portfolio modernization. It delivers a better quality outcome than cus-tom code development at half the cost and with the highest success rate.
Make Technologies® Enterprise Suite™ allows businesses to:
• Lower the cost of application maintenance by lowering the amount of custom code and creating an easy to maintain application.
About Make Technologies
Make Technologies is a leading global provider of legacy modernization software and services. Founded in 1999, Vancouver, B.C. Make Technolo-gies has helped customers in a broad range of industries including finance, healthcare, insurance, natural resources, distribution, communications, and government. Make Technologies is a trusted brand in enterprise legacy modernization initiatives with partners like Deloitte®, Oracle®, and IBM®. Copyright © Make Technologies, Transformational Legacy Modernization (TLM®) are registered trademarks of Make Technologies in the
supporting collaboration, analysis, code generation and data migration. • Control the output quality continuously throughout the engagement. • Verify the functional completeness of the modernized applications.
A re-architected system can provide a solid foundation for long-term organizational growth. However, decisions made by Business Sponsors and Stakeholders on the inclusion of enhancements within a modernization project can significantly affect the project’s risk profile, depending on the nature/impact of the changes and their implementation strategy.
Business Sponsors and Stakeholders need to understand the impacts, costs and benefits associated with intro-ducing new functionality and/or changes into the modernization project. Architectural Upgrades, Streamlining and most Enhancements can be incorporated into the initial modernization release with manageable risk. Changes that transform the behavior of the modernized system relative to the legacy system, may be difficult to test/validate and therefore may be implemented most cost-effectively in a later post-modernized release.
