Legacy Information Systems

Modernisation is a necessity

Most large organisations are deeply mired in their information systems sins of the beginning of the information era. Typically, their information System are large, geriatric (on average more than 30 years old), written commonly in COBOL, and use a legacy database service.

These Information Systems are essential to the organization’s business and must be operational at all times. These characteristics define what we call legacy information systems.

Today, legacy System poses one of the most serious problems for large organisations. Costs due to problems of a single legacy System like

• Failures and bugs,
• Maintenance,
• Inappropriate functionalities,
• Lack of documentation,
• Poor performance,
• Lack of security

Can often exceed hundreds of millions of dollars per year. They are not only expensive to maintain, but also difficult to adapt to changing business needs, and easily broken when modified for any purpose.

In this article I want to explore the different ways to modernize a legacy system and propose a new strategy and architecture that combine change management capabilities and business transformation.

But first lets go through some insights and information about the legacy modernisation ecosystem.

The world run’s on legacy

• 200 billion lines of legacy code are still in use
• 1+ million COBOL programmers world wide maintaining an approximate of 100 billion lines of COBOL code
• 80% of the worlds systems are legacy
• 75% of financial institutions in Europe are using out- dated systems (legacy) for core business
• COBOL powers 80% of all daily business transactions
• 30+ years of legacy modernisation research and 80% of world systems are still “legacy”?

Faults are as big as the legacy

In 2012 16 million of RBS, NatWest and Ulster customer accounts ended being frozen

In Dec 2014 40 flights was cancelled in UK affecting 1.9k other flights and 230k passengers

In Jan 2016 HSBC Customers could not access accounts for 2 Days

Change Driving Forces

• Lack of Flexibility
• High Cost
• End Of life of tech-stacks
• People
• Integration
• Security

Modernisation Strategies

First let’s suppose we have legacy System monolith candidate to modernisation.

Most of the existing legacy system still rely on mainframes hosting legacy Databases of file systems with Batch services and Transactional Process.

Cold Turkey

A Big-Bang approach consisting of a total shift to the new technology. The entire system is rebuilt using new technology, and the old system is unsettled. It is built from scratch using standard platforms or built using a third-party package as a foundation layer.

Applicable Situations

• Current age-old system cannot support additional changes needed by the market.
• The vendor no longer supports underlying technology platform
• Current technology is expensive to license. Other companies are moving to a less expensive stack (often open source).
• Post-mergers/acquisitions, the company needed to build a new application with unified functionality.
• New leadership was pursuing a new IT vision to support aggressive business goals.

Cold Turkey Techniques

• Refactor / Replace

Convert legacy code and/or replace with COTS (purchase of packaged solutions which are then adapted to satisfy the modernisation needs)

• Rebuild

Rebuild from ground up in modern language in one-go

Benefits

• Provides the highest return and best competitive edge over competitors.
• Technology stack and architecture is modern enough to remain competitive for several
• Years into the future.
• Offers the maximum edibility in architecture and design and is not constrained by old components.
• Operational measures, SLAs/KPIs, business effectiveness and efficiency all receive a huge boost.
• Offers an excellent opportunity to redefine/improve the business processes leveraging new systems.

Success Factors

• Proper due diligence/assessment must be conducted when selecting the technology.
• Assessment phase to define roadmap with key milestones (e.g., go-live dates).
• Iterative rollout to minimize the volume and impact of change (compared to big-bang go-live).
• Stakeholder management with regular communication and end-user training and acceptance.
• Strong program management and governance practices must be followed.
• Production parallel execution (“parallel adoption”) and comparison of old and new systems.
• Understanding the data structure and data quality if data migration is involved.
• Capture and validate the non-functional requirements (e.g., availability, performance, etc.).
• IT department’s ability to learn the new technology and augment it with outside talent if needed.

Risks

• This is the most risky, yet most rewarding approach.
• Entire functionality is at stake and any quality issue can impact the business operations.
• Likelihood of failure or midway stop/hold is highest due to cost overruns or missed deadlines.
• Pockets of resistance by end users due to inability to handle/accept the change.
• Business sponsor may become demotivated if no incremental business benefits are demonstrated.

Wrapping / Duct Tape

Localised, small-scale changes are performed using new technology to address specific issues in the application while the application core architecture and technology remain the same. A popular approach is to build a new application that will be bolted to the main application to bridge the gap in functionality.

• As little modification to legacy as possible (tactical approach in nature)

Usage of Wrapper Technologies like CICS, screen-scrapers or Enterprise service Bus with legacy adaptors

Applicable Situations

• Company plans to continue with the legacy app but will fix existing issues with new technology.
• Focus on current problems (e.g., improving KPIs/metrics) that must be fixed ASAP.
• Facing a new problem in the middle of the year with no budget for a more comprehensive solution.
• Stopgap solution to fix current issues to gain enough time for planning modernisation.
• Company has undertaken a large program that consumes IT manpower bandwidth and risk appetite.

Benefits

• Small-scale changes offering comparatively big returns.
• Doesn’t require huge investment and can be supported through ad hoc budgets.
• ROI is concrete and substantial, and increases the confidence of the project sponsor.
• Offers quick wins since results are often delivered in months.
• A less risky approach, probability and cost of failure are typically low.
• Doesn’t require as much management attention as larger transformations do.

Success Factors

• Technical governance to ensure this easy-to-follow approach is not overused/misused.
• Careful attention to future roadmap/strategy is required before attempting this approach.
• Rebuilding the application may be cost-effective if the app requires too many changes.
• No matter how small the change is, all project management processes must be followed.

Risks

• Too much of this approach in too many places can lead to patchwork apps and bad design.
• Cost of multiple changes in an app may be higher than required to re-platform the app.
• A change performed without due diligence can lead to throwaway work.
• A stopgap solution may not keep pace with changing business needs over time.
• Future total replacement of the application would make duct tape change a sunk cost.
• Due to its smaller budget, this approach is often overlooked and proceeds without management review.

GRADUAL REPLACEMENT

A component/functional block of an IT system is replaced with a new technology and moved to production as a separate application while the rest of the system remains on old technology. With time, remaining components/functional blocks are replaced with separate apps and gradually the entire system is rebuilt.

Situations

• Replace entire systems one component at a time, with controlled release of budget.
• Only a few components contribute to most of the issues.
• Externalise and consolidate scattered business rules using business rule management System (BRMS) platform.
• Eliminate tight coupling of the systems by implementation of enterprise service bus (ESB).
• Change the existing systems from batch to real-time/online.
• Build service wrapper on top of the existing systems to provide the data to other systems.
• Modernise out-dated database systems using leading RDBMS systems.
• Replace legacy dumb terminals with new UI, supporting Internet browser and mobile devices.
• Reduce license cost by implementing an open source platform.

Replacement Technics

Both technics are used as phased approach based on gradual legacy system decomposition into modules and coexistence with new modules.

- Chicken Little

• Gateways Usage

- Butterfly

• No Gateways
• Data Access Allocators and Crystallisers

Benefits

• This is a low-risk way to transform the entire system by moving one piece at a time.
• This requires much lower one-time budget approval compared with a total transformation.
• Since one functionality is migrated at a time, the business impact and cost of failure are lower.
• Since work volume is less than a total transformation, it consumes less management bandwidth.
• Delivers results quicker compared with a total transformation.
• Breaks one large system into SOA-based componentized systems.
• SLAs/KPIs and other measures can be tracked and improved at more granular levels.
• Allows companies to choose different technologies or newer versions for later components.

Success Factors

• All relevant program management practices are followed.
• Explore ways of building reusable components or other artefacts for future applications.
• Follow clear technology direction for all new applications for consistent architecture and design.
• Governing body to ensure all new applications are tied to common goals and roadmaps.
• Long-term continuity of key resources to support multiple new application development.
• Smooth communication among different concurrent application teams is key for consistency.
• Non-functional requirements must be captured and validated for all applications.

Risks

• Risk of amalgamation issues among different applications if not managed properly.
• In the absence of close monitoring, each app can end up using a different tech stack.
• Can lead to a set of disjointed applications that do not function well as a unit.
• If end state is not factored in design, future scope additions can be difficult to implement.
• If architecture is not planned well, it may lead to too many components and integrations.
• Concurrent development of two apps can lead to versioning issues involving common components.

Each of these types of transformation approaches has its own merits and applicability. Which approach works best for any company depends on its organizational requirements, risk appetite, state of its existing IT infrastructure and competitive landscape.