Legacy modernization: Open Source Software as an Alternative?

If you are searching about legacy migration you might have heard about legacy modernization to open source software (also known as OSS). So have you ever wondered if this would be a reasonable step to take? Maybe you need some more information about open source, first.

Open-source software is the kind of software that provides its source code open to public, so that anyone is able to copy, modify and redistribute it without paying royalties or fees. The code can evolve through community cooperation. Often someone who started an open-source project ends up as a large company. Many producers of OSS offer trainings or Service-level-agreements (SLAs), which is a part of a service contract where a service is formally defined.

Examples of open-source software products are the web-browser Mozilla Firefox and the operating system Linux. The expectation by switching to OSS is most of the times to save money – and it is true: Such products are most of the times for free or really cheap implemented, why license costs can be saved. Nevertheless, adoptions and extensions might be necessary, as well as trainings and other external services. So license costs should not be the only reason to switch to OSS without further investigations.

Other relevant topics when thinking about implementing OSS in a company would be the data privacy and IT security. A lot of questions need to be answered here: Where and how will data be saved or shared and how could the systems be controlled? Might there be a possibility for developers to control the system unnoticed and grab data out of it? All those questions regarding security topics should be verified by experts.

So as you can see: It is not always easy to decide, which software to switch to due to cost reduction or due to just modernize your systems. But don't worry: We will keep on writing about legacy modernization, legacy migration or whatever you want to call it. Please stay tuned and feel free to leave a comment!

Risks of Legacy Applications

There is no better idiom that “If it ain't broke, don't fix it” to illustrate the main barrier to IT migration. The attitude “if a system or method works there is no reason to change it” is the enemy of innovation! Why? Do business executives know what that really means for a company? In this article we will go through the main impacts of legacy applications by highlighting the connection between business and IT and seeing the potential savings and benefits companies get from moving far away from old systems.

Inefficient IT Infrastructures

Console Vs Web GUI

Legacy applications provide companies with systems that, even if they work well, are no longer able to adapt to a changing business environment. See for example the problems financial institutions are facing whose core banking system relies on COBOL programs that were built more than 30 years ago. At that time priority was given to security and reliability and although these criteria are still relevant, today systems need to be more flexible agile and innovative. IT inefficiency would consist of the following points:

• Lack of integration:
  Systems integration is the process of linking together different computing systems and software applications physically or functionally to act as a coordinated whole. It is challenging to link together several applications that use different languages and or architectures. If we go back to the banking example, their core system was developed in COBOL, if additionally they have SAP and if they acquire a new CMS in Java all three items must work together. It is possible to do so but it demands complicated workarounds.
  Advantage of Migration:  A Service Orientated Architecture based on software components that can be re-used for different purposes. 
• Lack of scalability:
  The scalability is the ability of a system to handle an increasing amount of work in a capable manner or its ability to be enlarged to accommodate that growth. The problem with legacy systems is that once it reaches its physical limits it’s impossible to it make it faster. This means that if a company has high potential for economic growth is planning to expand its activities; its legacy system is likely to be overwhelmed by new workload. 
• Lack of accessibility:
  Most of legacy applications still use complicated command line interfaces that limit the ways to use a program, as opposed to graphical interfaces that are more intuitive, and easier to use.  Moreover migration with cross platform technology facilitates the development of mobility applications.

In the long run, inefficient IT infrastructures, lower firm’s competitiveness which directly affect its revenue and market share.

Business Continuity 

Will the company have the resources to fix hardware or software problems? As newer technologies emerge, the pool of skills qualified to work on legacy applications shrinks: employees retire from work, old programming languages are no longer taught in universities, or employees would rather work on projects that keep their set of skills updated.

According to a Computerworld survey of around 350 IT professionals, for 50% of them, the average age of their COBOL programmers is 45 or older, 46% of them already noticed a shortage in COBOL programmers. Next to the skills management issue, the lack of qualified employees brings the problem of respecting Service Level Agreements. For instance, in the financial industry SLAs are made over a 10 year time frame or longer. Given the fact that’s it is already difficult to find staff today we can only be pessimistic about the situation 10 years from now.

Unexpected Costs

A common misconception about modernization is that it's often considered as “spending” rather than “saving”. Although migration costs can be significant, firms could think of it as a way to potential savings and potential business opportunities. Leaving the systems in their current state involve direct and indirect costs, often not fully understood.

Cost comparison of a migrated and an old application

• Labor costs:
• Before Migration:
  Workforces play a major role in determining how decisive it is for a company to modernize its IT infrastructure. Companies have an increasingly tough time in replacing people with critical skills – for example maintaining the old applications – retiring from work. If the company uses an old COBOL, RPG or PL/I application, today’s new generation of developers trained in C++, Java or .Net would need an additional coaching to work with COBOL, RPG or PL/I . Hence, as the pool of resources qualified to work on old systems diminishes, the staff training cost increases.
• After Migration:
  In contrast, new applications simplify system management, which means that less staff is required for ongoing support and maintenance. Even implementing new features is cheaper because it is more efficient with modern programming languages. This does not necessarily result in the reduction of operational staff but rather in the reassignment of personal to responsibilities or projects of higher strategic value. 

• Software Costs:
• Before Migration:
  Companies have to pay thousands of dollars in monthly license fees to run HOST applications while cheaper alternatives exist.
  Operation system: zOS for IBM mainframes
  Database management system: DB2 for IBM or other utility programs proprietary for HOST systems
• After Migration:
  Firms reported up to 83% savings by moving from an Oracle/IBM solution to SQL server which is a Microsoft product with license fees. With the open source MySQL it would even be entirely free.
  Operation System: Unix or WindowsDatabase management system: MySQL or often free systems for modern platforms

• Hardware costs:
  Moving from an expensive IBM mainframe to simple personal computers or rack servers is another source of savings. For instance, an IBM AS/400, which is the mainframe/HOST of small companies, costs around $20 000 for four years. Five rack servers with an equal amount of computing power would cost around $5.000.

• Indirect costs:
  Old systems decrease overall productivity and limit firms’ competitiveness. The advantages of modern graphical interfaces (GUI) compared to terminal applications are one example. This leads to indirect costs that take the form of client’s discontents and therefore business loss.

Migrating legacy applications obviously involves costs. Whether the project is handled in house or outsourced, resources must be affected to the different stages of the process: analysis of the old application, selection of the new platform / technology, definition of the migration strategy and the code and testing of the new application.

“If it ain't broke, fix it!”

It is probably better to try to avoid the problems related to aging platforms in the first place, rather than trying to fix them once they arise.

To compare the relative costs and benefits of either keeping an old application or migrating it, organizations must review their expectations considering the various advantages and disadvantages each solution brings.

A case study by Alinean analyzes the cost reduction of migration projects conducted at two companies from two different sectors: one in financial services and one in manufacturing. The analysis compares the total cost for application migration over four years to what it would have cost to keep the old version (evaluating initial costs, annual support for new equipment and software, and labor expenses).

In both cases, the cost of implementing a new system was much cheaper than the cost of keeping and still maintaining the old one. The financial services company was able to reduce hardware costs by 72.6%, software cost by 78.8%, labor costs by 21.10%, and facility costs by 39.70%. With a total initial investment of $9,363,552 (migration project, hardware and software costs) the company reduced annualized operating costs by 46.4%. For the manufacturing company, the results are even more outstanding. The company reduced hardware costs by 22.9%, software costs by 92.1%, labor costs by 47.6%, and facility costs by 45.9%. With a total initial investment of $6,136,000 the company reduced annualized operating cost by 70.9%. (See the complete case study here).

If the IT department can be isolated from business concerns, application migration emphasis the role of IT projects in the overall business effort of a company. From a financial point of view, IT migration allows great potential savings (that can also pay back the initial investment). From an organizational point of view IT migrations improves processes and hence better support organizational objectives.

Migrating From Legacy Applications?

Legacy applications are firms’ applications that are based on old and sometimes outdated programming languages. For most large companies, they are an everyday challenge. Usually found within critical applications, legacy systems continue to be used as they still deliver value performing daily tasks even though newer and more efficient methods exist.
A recent survey from Nexaweb Technologies revealed that, out of 750 IT professionals, 88% claimed to have a problematic legacy application burden, with 57% of which categorize their problem as “serious” or “very serious”.

Buy, Develop or Migrate?

To deal with legacy systems companies can take different paths:  buy or develop a new application, or migrate. They have to chose which approach should be followed according factors such as size of the project, the level of customizations, how critical the application is, and maintainability.

With buying a new system, companies have to keep in mind that each business has its own specifics and applications rarely meet the exact needs of firms. For that reason further developments at an extra cost are required for customization. Development of a new application allows more flexibility and results in a product that exactly fits the customer’s needs. Nevertheless the bigger and the more complex the application is the more difficult it will be to redevelop. By purchasing or developing, companies need to carefully test the replacement and the risk of errors, bugs, or misconceptions is high (unlike migration with Service Orientated Architecture (SOA).

Migration differs from the two previous methods in that it actually takes the old application and translates it into a modern version. It also reuses the original systems’ business logic which guarantees that the migrated application will be functionally identical to the original. The legacy applications have been operational for several years or even decades, they are tested and work 100%. With the right migration code and cross platform technology, the migrated application will be correct, plus with the Build to Order technology the modern version will exactly fit company's expectations.

Types of Migration

Companies can perform three types of migration from 0% to 100% automatic. Manual migration is about re-writing all the lines of codes by hand. Imagine here one developer sitting on a desk with two screens, in the first he reads Cobol and in the second he writes Java. That solution makes sense for very small applications, probably less than 10 000 lines of code. In contrast, with automated migration a program reads Cobol and writes Java. What is interesting with this method is that automation makes the process both faster and safer (see previous post for more details about automated migration, cross platform technology and SOA).

Legacy applications are generally huge (typically millions of lines of codes) and often complicated (given that they are critical), a program will translate faster and make less mistakes than a developer. Next to the “line-per-line”-approach, automatic migration can also use smart patterns to detect and change programmatic concepts. In doing so, architectural changes according to the program structure can be made and the converted program becomes much more flexible and maintainable. Somewhere in between, there is semi automated migration. A program will automatically migrate parts of the code and developers will manually migrate what’s left. For example if some concepts in the original system can not be translated with a feasible effort, the migration tool will leave it to the developers. The more complex and critical the application is, the more automated the migration should be.

IT migration as a strategic move

Even though IT execs acknowledge the need of moving away from legacy applications, and that relevant technology exists, it is what business executives think that matters. They are those who decide on the funding of migration projects but they are also those who don’t particularly see the challenges of IT. IT is often seen as a technical function hence the connection between IT modernization and operational concern isn’t clearly established.

Besides, in these times of economic insecurity, investments are reduced. The problem with doing so is that it is likely to offer market share to competitors who look at out of the box solutions. In 2008 Diamond Management and Technology Consultants analyzed the performances of 400 companies during the 2001 recession. According to their results companies that made the strategic decisions by being "smart about their cuts" and "successfully improving the design of their business", increased their margins by 20%. The question in then: Is migration a strategic decision?

Let’s illustrate the need of modernization with an example in the mobile phone industry: Around a decade before Apple, Nokia spend millions of dollars on research to develop touch-screen devices very similar to smartphones. Although the technology was in their hands they redirected efforts from smartphones to basic phones. In 2007 Apple came up with the iPhone and the success we all know. By sticking to old technologies Nokia progressively lost its position of world's largest maker of mobile phones. Its share price went from US$40 in 2007 to less than US$3 in 2012. In Contrast, in 2007, when Apple released the iPhone its stock was selling at about $85. By the time Job resigned in 2011, it had risen more than 350 percent. In June 2012 Nokia’s CEO even had to admit that the problems the company was facing were mainly due to the failure to anticipate the changes in the industry.

In the same way, IT modernization and the risk of aging platforms is an urge that execs should be aware of: Migration is a must; the question is not if but when!

Management of Future IT – Squaring the Circle?

Every year I meet more than 50 IT managers, CIOs, divisional managers, senior heads of department and heads of department to discuss the basis of our book Quality, that’s IT, the actual and future significance of the IT production factor, and to identify sensible options and steps for future strategic alignment.

My recommendations to move away from today’s expensive production platforms, to introduce open architecture and to consider including open-source applications for basis software, have often only been acknowledged with a friendly nod. It seems that the ties to old technologies are too strong and the ways forward to the new, are too long to be simply overcome by a simple cost effective solution. One of my last discussions culminated with the statement “Every decision I make today will be wrong tomorrow!”

The fear of making wrong decisions is justified by the conflicting areas in which CIOs have to make decisions. They are influenced by many opposing pairs: there is service delivery versus need for change, standardization versus individualization, own operation/in-house development versus out-sourcing (make or buy), security versus openness, robustness of applications versus flexibility, reaction capability (classic time-to-market) versus desired quality, modularization and re-utilization versus performance and independent components, convergence of technologies versus opportunities from new technologies, technological independence versus maintenance efficiency and last but not least further automation requirements versus cost reduction.

These are not the only opposing pairs and dimensions, the above list is intended to show the complexity of the decision making environment that CIOs have to face today and in which IT management must find its position. Many strategic questions for the future require an answer:

• What does really drive our business forward?
• What added value can IT deliver?
• Which IT technologies can improve an organization’s products and processes?
• Where do we lose competitive advantage through standardization?
• What must be or should be operated internally/externally?
• How can we increase the level of customer services through IT?
• Which IT innovations ensure more business?
• How can we increase product performance by the use of IT?
• How do we make our systems more flexible?
• Despite increasing demands on IT, how can we keep the costs under control or reduce them?
• etc.

To answer these questions and to position one’s organization in these areas of conflict requires a critical assessment and a fine balance. But the speed of competitor innovation and information technology innovation reduces the half-life of strategic IT decisions. We live in a race against time and we need to position ourselves in it. In this race against time, planning and decision replaces chance by error. If this is the case, then the decision I make today will be factually incorrect tomorrow and the statement I quoted from my conversation partner at the beginning, hits the nail on the head. We therefore need a Meta solution-model at all levels of design and use of IT technology that will anticipate the half-life of decisions.

The Speed of Innovation Should Be Anticipated Strategically

The solution-model must turn an “either/or” into an “as well as”. For example, positioning one’s company in the dilemma “robustness or  flexibility” can be avoided through a scalable configuration, so even with higher flexibility, increased robustness can be achieved. The solution-model we have been proposing for years consists of open system architecture, service management, process management, rules engines, product engines, model based development, component design and the re-utilization, encapsulation of middleware and generators.

This would mean for example, that the database technology, transaction monitors, application servers etc. in use, are replaced by newer technologies, without changing the above applications. Model-based developments would mean that target platforms are replaced without changing the applications. Additionally, process management and rules engines mean that legal requirements, organizational changes and responsibilities may be freely configured without having to make major changes in the applications.

Yet, to work, this scenario requires an upstream standardization process that standardizes all elements of system design: information structure, communication structure, functional structure, process structure and module structure. The industrialization process is primarily a standardizing process; outsourcing for example is the second step, although it’s a long way. In the long-term however, there is no alternative if one would like to achieve the same productivity increases in the area of application delivery as seen in the area of hardware i.e. approximately doubling output and halving the costs every 18 months. Once we find ourselves in this situation we really are talking industrial software development.

The Speed of Innovation Can Be Tactically Anticipated

Now the question arises: if the necessary resources are not available in the organization for industrial software development, how can a CIO avoid making wrong decisions and reduce costs? Is this even possible or is it like squaring the circle? Our answer is simple: Yes it is possible!

To do this we have developed technology that we have called Cross Platform Modelling & Transform (CPMT). This technology endeavors to answer the question how our customers can use a cost efficient production platform, middleware components, databases etc. without first having to make substantial investments.

Our solution is based on the concept of platform independent modelling. We work on the premise that every system implemented today is a complete model and that this model is capable of being incorporated into another one. By definition, when Cobol, PL/1 or RPG is implemented in an application it is a platform dependent model. This model will be transferred into a platform independent model by our Parser (PILS – Platform Independent Logic & Semantic). This model can be supplemented when required (PILS Additions). The architectural layer can be laid differently; it can define the integration of new frameworks and specify design elements (PILS Migration Design). This includes the consideration of style guidelines, nomenclatures, source-code structures and superstructures. On the PILS, PILS Additions und PILS Migration Design models, generators set up and write a new system, which will come closer in meeting future demands. So COBOL sources become JAVA statements, DDL for DB2 becomes DDL for MySQL or Posgress SQL, process models become Activiti Statements and Jobcontrol becomes Javascript or another procedural language.

The technology has already had its first tests and the results are a cause for optimism. Clients have assessed the new source code as maintainable because of its construction on templates. It can be profiled and the degree of automation in an implementation scenario is often at 100 %. It is only performance critical application components that must be manually adjusted so that the paradigms of a new platform can be adequately served. The costs incurred will be completely recovered and future IT is no longer a distant future scenario but a tangible reality.

Author: Gerhard Rienecker, President of PASS Consulting