Quipoz

Over time your organisation has most likely developed applications in many languages, presenting you with ongoing challenges. How easy is it to maintain an application? Does the language and the application support contemporary business and technology needs? Where are the business rules that support the application and what are they?

The Butler Group, in their Application Modernisation Report - June 2003, relate the business drivers identified by the organisation to the value dimensions that will measure their success. These are presented in the table below.

Business Driver

	Deteriorating System	Compliance	Economy	eBusiness	Get Ready For Change
Key Business Objective	Survival, operational continuity	Meet regulatory requirements	Reduce operating costs	Extend reach inside business and/or external to business	Position the business for the future
Value Dimensions	Improved maintainability (documentation, easier to fix) Access to support Lower operating costs Access to new customers (package supplier) More adaptable system	Control cost of capital Control operating risk Meet Basel II requirements	Reduced operating costs, licence costs, back-up/ disaster recovery costs Opportunity to outsource Reduced complexity More adaptable system	Increased revenues New customers and users Better service to existing, new customers and users Reduced customer acquisition costs Brand enhancement	Adaptable system Closer integration with business partners Extended services to customers Web Services option Future- proofing

To meet the demands of application functionality and maintenance most organisations would opt for a simplified systems environment but have to answer the major questions of how to make that change.

They must first establish a case whereby they can reconcile the limitations of legacy architecture with today's high priority, time critical business requirements.

For two decades business executives have been told the technology had arrived to transform legacy systems. First it was 4GLs, followed by CASE and then in the early 1990s it was believed client/server systems would replace legacy environments. Y2K was to prove that rewrites were impractical.

It would therefore seem simple to buy new application systems and replace their predecessors. ERP systems appeared to be a solution. But legacy data created a huge conversion challenge, threatening the success of many ERP projects. Today many ERP systems are themselves legacy in nature. Written in proprietary languages they do not support e-business requirements.

Nor does the "buy a replacement" philosophy take account of the degree to which legacy architectures have become inseparable from an enterprise's current business model. And, furthermore, few people, either IT professionals or members of business units, can describe exactly what legacy systems do.

Business executives asked themselves yet another question: could so-called middleware help to access the data locked away in legacy systems and make them suitable for today's straight through processing business environment? Sadly, too often, the answer is no.

It is obvious there are no quick fixes with the transformation of legacy systems. Given that the option to "do nothing" will not lead to long-term success, the four realistic options that remain are:

• Buy a new system
• Build a new system
• Manually transform the legacy system
• Automated Transformation

Contact Quipoz for more information

We would be pleased to send you a copy of any of the following documents. All we ask is that you provide some basic information in return. We may contact you after supplying you with your requested documents. Our Privacy Policy explains how we will use any information you provide.

Please enter our company name (as shown in the image above) to enable the email link.