Recently, I was interviewed by Pcon (unfortunately the link points to an Hebrew only site) as part of debriefing on Legacy Systems.
Pcon is an Israeli company investigating IT topics by quoting professional articles and interviewing experts.
They publish the results of the investigations including practical recommendations.
This post is mainly about topics raised by me during the interview, but not included in the debriefing, which will be published.
What are Legacy Systems?
The term Legacy Systems refers to old application systems and/or veteran technologies still in use.
Usually, the term Legacy Systems is associated with:
1. Mainframe Hardware e.g. IBM System z and its Operating Systems or Proprietary Servers and Operating Systems such as HP Alpha and OpenVMS Operating System, IBM AS/400 and OS/400 Operating System.
2. Development and Production Environments, e.g. COBOL, Natural and DBMS systems such as Adabas and IDMS executing on Mainframes or Proprietary Servers infrastructure with proprietary Development and Production Environments.
3. Applications Systems developed more than ten years ago executing in the infrastructure environments cited above using the IDEs and DBMS Systems cited above.
It is true that often Infrastructure and Applications, cited above are Legacy Systems, however there are also Legacy Systems using other technologies such as Visual Basic version 6 or older, old Java technologies and old Windows Operating Systems or extincted UNIX Operating Systems.
In this post i limit the term Legacy Systems to IBM Mainframe systems.
Why investigating Legacy Systems?
The main reason is that these systems are used by many enterprises.
The systems are not only frequently used, they are used for Business critical Processes and Transactions and store and manipulate critical Data.
The second reason is that these systems are no longer Mainstream, as far as new systems buying or building is concerned.
Young people knowledge of theses systems technologies, architectures and concepts is usually limited.
The young generation is not ready to learn about these systems and prefer newer concepts and technologies.
This is the third reason to investigate: limited availability of Legacy Systems skilled professional, which raise the question: why not migrating to other environments before lack of skilled professionals availability will be a crucial problem?
So why not migrating to other environments?
For some enterprises, the question above is a good question and the answer is positive they should migrate from Mainframes to other platform.
Other enterprises have good arguments for avoiding migration.
The following list depict some reasons for not migrating:
1. If it is not broken do not fix it.
2. Replacing Legacy Systems by other systems is expensive and will take long time.
3. Probably, some of the team members should be replaced because they will not make the transition to a new system, new infrastructure and new methods.
The down side is losing their experience and their knowledge (especially non-technical knowledge of the Business, the Organizational Culture and the practices.).
Is it possible to identify those who should migrate and those who should not?
Yes it is. Size Matters. Usually Small Enterprises are better migration candidates than Large Enterprises.
Small Enterprises will not face Scalability issues and Performance issues.
They also pay more relatively to their size, because Mainframe Hardware and Software prices are skewed in favour of Large Enterprises.
They will not have to hire a large number of people to support large number of Servers as Large Enterprises will have to.
Large Enterprises usually operates more Application Systems and their Application Systems are more complex, so the migration will be prone to more errors and failures and will cost more.
Another discriminating factor is the Operating System.
Large Enterprises use IBM's Mainframe flagship Operating System z/OS. Some Small Enterprises use the declining z/VSE Operating System.
Some of the Independent Software Vendors stop support or new versions development of VSE software products. Other minimized their development efforts and current versions support.
The future seems even gloomier because the deteriorating VSE installation base.
Is IaaS a Game Changing Technology?
IaaS looks like a game changing. Users of Operating Systems such as Windows and Linux can lower their TCO by moving part of the Data Center or the whole Data Center to the Public Cloud. Mainframe users can not.
Most Large Enterprise will not move their Core Systems to a Public Cloud in the following two or three years, but SMBs are candidates for moving soon their systems to the Public Cloud.
This trend could be another catalyst for Small Mainframe sites to migrate to Windows, Linux or UNIX.
However, IaaS also change another prevailed concept of running Infrastructure and Systems within the Enterprise boundaries, i.e. its Data Center or Data Centers.
The Public Cloud age, change this concept: You no longer need to own and maintain the physical infrastructure (very similar to the concept of not placing Electricity Generators in every house).
Lower TCO based on getting rid from Data Center Servers is a challenge for Small Mainframe installations, but it is also an opportunity to save the migration efforts, by moving their Application Systems
to a larger Mainframe user premises and lowering the TCO as well. Larger Enterprises can assign Virtual Mainframe Servers to Smaller Enterprises.
Related Posts in my Blog
Mainframe and the Dinosauraus Myth Revisited
IBM z/Enterprise First Take: Data Center in a Box or Cloud Computing
Vendors Survival: Will Software AG Survive until 2019?
Subscribe to:
Post Comments (Atom)
Public Cloud Core Banking: Hype or Reality? - Revisited
More than 4 years ago I was asked if Public Cloud Core Banking is a Hype or a Short Term Reality? If you had read the post, you would prob...
16 comments:
Group: Legacy Migration
Discussion: The mainframe: still alive and kicing
@Avi:
I guess some people in this group my disagree with your statement "Replacing Legacy Systems by other systems is expensive and will take long time". I don't mean to say it is simple or it does not require an investment in technology and services - but if there is a solution and a business case (like in most cases that I have seen so far), you should go for it.
Just my 2 cents.
Posted by Florian Delonge
Florian,
I would tend to agree more with Avi on this point then disagree. And it always comes down to two words; IT DEPENDS! What if you 'go for it' and find out there was some functionality hidden in the mainframe that no one can figure out how to convert i.e. the 90-10 situation. I've seen this happen for sure , delaying the project, then cost overruns, people being replaced and sometimes backing off the conversion all together!
LinkedIn Groups
Group: Legacy Migration
Discussion: The mainframe: still alive and kicing
I feel you need to differentiate between re-hosting and re-engineering when migrating to an open platform.
Re-Engineering is expensive, high risk, but provide the largest benefits.
Re-Hosting means moving the existing buisness logic and the vast majority of the code to the new platform replacing only the platform dependicies. This should be quick, 12 to 24 months, with a breakeven in approx the same time after cutover. By utilising automated tools and a proven methodology it is relativly low risk. The impact to the buisness is minimised and the code freeze can be as short as1 to 2 months. THe user and external interfaces remain the same.
All these projects have challenges but thats why we are still interested. If it was humdrum then it would not be worth doing.
Posted by Victor Duncker
LinkedIn Groups
Group: Legacy Migration
Discussion: The mainframe: still alive and kicing
Performance can be a challenge. If the application is COBOL then that will not be an issue as it blisteringly fast on open platforms with multiple CPU's. Database can be more of a challenge, network database are very efficient in some applications, switching to a relational database as a container of the network database means that traditional tuning for a relational model may not apply. So some lateral thinking may be necessary.
IDE Developmenet environment is better once the learning curve is over.
JCL conversion to KORN or PERL can create support problems. Extra training is necessary to support operations, etc as part of the migration process.
Skills availibility now that should be better. Getting new hires to program in COBOL is easier when they have a full IDE to work and debug in. They are familliar with the open platform making the transision easier. Support for the platform components is easier.
What you still require is the core application knowledge. You are still running essentially the same application with the same batch requirements, same interfaces, etc.
Posted by Victor Duncker
Group: Legacy Migration
Discussion: The mainframe: still alive and kicing
Avi --"expensive" and "long time" are, of course, pieces of rope of unknown length. :)
It seems worthwhile, in the context of this discussion, to examine the relationship between modernization (re-engineering) and migration. I've observed some confusion about that relationship.
The objective of modernization is to improve an existing application's quality and/or repurpose it to provide new functionality.
The objective of migration, OTOH, is either to escape a fading or overly expensive platform and/or language, or to consolidate disparate languages and/or platforms to a common one (e.g. after M&A).
In our experience, a migration should perturb the functionality of the migrated code as little as possible; otherwise you don't know what you're testing on the other side. There are cases where the nature of the migration dictates changes, but they should be minimized. If such changes are extensive, the migration should be approached as an effort to salvage pieces of the old system for reuse in the new one, not as a straight migration.
Consequently, we characterize a migration as "modernization" only if it results in a move to a more modern platform, with better development tools, available developers, etc. And the modernization in that case is of the environment, not of the application.
We characterize modernization as the improvement of existing code in terms of code quality (to reduce failure risk and maintenance), architecture (to make it more agile and maximize code reuse), and/or purpose (to adapt it to new technologies such as the Web). Much of all three can be automated.
So modernization should take place before or after a migration, but not during it (unless it's unavoidable, as mentioned above).
Disclosure -- I'm the author of a computer language expert system whose rules language can be used to automate all of the above (to the extent that it's possible).
Posted by Stephen F. Heffner
Group: Legacy Migration
Discussion: The mainframe: still alive and kicing
Victor, I can support your position based on a large number of migration projects I've managed and was involved in.
Performance was never an issue for us, though I've seen a POC from a competing company failing due to very poor performance, while another approach to the same subset of application delivered the expected performance - and finally to the entire project. So done right, performance should not be an area of concern at all.
Availability of skills should definitely be much better as you said as well as supporting tools like IDE's, database tools, scripting etc.
As Steven and you pointed out, a migration should just do one thing, migrate an application to a new platform with as little changes as possible, highly automated with little or no manual intervention. This should make it - again, done right - a low risk and a fairly quick exercise with a short ROI.
LinkedIn Groups
Group: Legacy Migration
Discussion: The mainframe: still alive and kicing
Stephen, and Hans
I totally agree, mixing migration and modernisation should be minimised as much as possible.
Frequently there will be a small number of batch jobs that require re-engineering to meet acceptable performance criteria.
Some interfaces may be unavailable on the new platform requiring re-design and implementation.
Stopping project creep, the "oh can't we just improve this" or "re-engineer this to make life simpler". It needs a signed of SOW and a strong project manager to keep you off that slippery slope.
Posted by Victor Duncker
LinkedIn Groups
Group: Legacy Migration
Discussion: The mainframe: still alive and kicing
Sorry Avi...I am a little disturbed by the "If it is not broken do not fix it" attitude. I know it is a clichee that has been banded about for years. But what happens if we sit around waiting for it to break? Application overhaul is to technically future proof the asset value of mission critcal applications. re-hosting...in some cases the first step, in others a Complementary step. of application overhaul...indeed Assessment and Risk mitigation, are key parts of this, as is a POC. Additionally, re-hosting technology can work in parallel with larger Mainframe...this is a great facility for more cost effective upgrades.
Posted by John Waters
LinkedIn Groups
Group: Legacy Migration
Discussion: The mainframe: still alive and kicing
Co-incidentally I just came off a conf call with a partner saying more-or-less exactly that - (1) migrate (2) modernize. It's obvious to me having been there many times. Hopefully it will be obvious to our customer who has been trying the let's-redesign-from-scratch for the last decade without success.
Posted by Nick Wnekowski
LinkedIn Groups
Group: Legacy Migration
Discussion: The mainframe: still alive and kicing
Modernisation and Migration could have different (and often opposed) objectives. Migration/Re-hosting aims at cost reduction (short term, low risk), while Modernization/Re-Architecting will target future requirements (ageing work force, new technologies). Mixing those two can be a challenge, not only in terms of technology and methodology, but regarding the business case as well.
I do agree that an assessment is usually required, on various levels (adressing the total application portfolio to determine the best approach for each application, as well as adressing the migration design and integration requirements for a specific project), and you need to have lots of experience under your belt to do this properly.
Posted by Florian Delonge
Thank you all for your comments.
I agree with Victor that you have to separate Migration and Modernization. I know an installation which migrated from Mainframe Natural to Unix Java without seperating Migration and modernization. Maintennace is a nightmare: It is Natural structure written in Java. No Java programmer can understand the code, as well as no Natural programmer.
I do noot agree at all with Nick and John.
Nick, there is nothing which fits all: some should Modrernize without Migration, others should Migrate without Modernization and others should Migrate and Modernize.
It is a matter of the estimated number of years until Applications End Of Life, Size, Enterprise Platforms etc.
When Estimated Applications End of Life is long Modenization is better than migration. It can also ease migration in the future, for example by dividing applications to SOA Services.
There are other possibilities such as Modernization of Core Systems and migration of other systems.
John, your attitude is a technical IT expert attitude. Business Managers think differently, whether you and me like it or not. "If it is not broken do not fix it" is common Business Managers attitude. It is difficult to justify migration costs if systems are doing their jobs. Those who should spend the money do not understand or care about platforms.
Sometimes Maintainance efforts and costs (including Backlog of Business needs which were not included in the systems) may justify migration.
LinkedIn Groups
Group: Legacy Migration
Discussion: The mainframe: still alive and kicing
The problem with "if it ain't broke don't fix it" is that it perpetuates a condition of unknown risk. It's commonly agreed that 80% of software in the world is in mediocre to poor condition. This represents enormous potential risk to those who depend on the code. (We've all seen catastrophic failures of enterprises resulting from software failure.) Modernizing and improving code (or replacing it with COTS where feasible) is the best way to reduce this unknown risk. And an app portfolio assessment is the only way to quantify it.
In addition to reducing risk, there is the issue of maintenance cost. 80% of all software work involves maintenance of existing code (this supports the 80% claim above). Renovating and modernizing code can drastically reduce this. For instance, I have created and currently maintain about 1/2 million code lines, and I spend maybe 5-8% of my development time on maintenance, as opposed to creating new code.
Yet another reason to improve and modernize code is to provide agility. Code of poor quality is brittle and inflexible, make it difficult to respond with agility to changing needs.
The processes of assessing existing code and improving its quality can be heavily automated, which can dramatically shift the ratio of cost and risk to the benefits. (Disclosure -- the same facility I mentioned in my previous comment provides this kind of automation as well.)
Posted by Stephen F. Heffner
LinkedIn Groups
Group: Legacy Migration
Discussion: The mainframe: still alive and kicing
Thanks for clarification Avi. I assumed your approach was from a technical viewpoint. I fully agree with what you are saying from a business viewpoint....this is one of the big challenges in the modernization business. There are no quick wins. Rehosting is one step and not many CIOs or other business managers will see their bonus going through the roof just through the completion of one step...the big question is how to remunerate decision makers for long termism
Posted by John Waters
LinkedIn Groups
Group: Legacy Migration
Discussion: The mainframe: still alive and kicing
@Stephen - migration and modernization goals may be orthogonal in theory, but can be opposed in real life, when you have to choose the "best" approach and have to decide between moving off the current platform quickly via 1:1 re-host (at low cost) or choosing a more elaborate approach which will most likely improve the quality, but extend the project (at higher cost). I have seen more than one case where the technical team would like to modernize, but the business decision is to go for cost reduction as quickly as possible. Ideally, you would do one after the other, but in real life, it rarely happens. Some people will try do a shortcut and move "diagonally" by combining both approaches, but they will most likely end up with a "JOBOL"-type solution - and I agree that you do not want to go there.
Posted by Florian Delonge
LinkedIn Groups
Group: Legacy Migration
Discussion: The mainframe: still alive and kicing
Florian -- I understand your point, and I agree that if a limited budget is available for both, a choice must be made. However, I would argue that such a budget limitation exposes a fundamental error in management. The decision to migrate really should be independent of the decision to modernize, and each should stand on its own merits. Neither confounds the other, except for consuming resources that may be limited. But even in that case, the business decision should probably be a question of timing to fit available resources, not either/or. This underscores John's point about incentivizing long-term thinking over short-term gains at the expense of long-term viability.
One factor that can muddy the water, unless it is approached with clarity, is that migration can provide some "modernization" benefits, namely providing access to more modern and effective development tools (as well as a larger pool of available talent). But this is an issue of modernizing the environment, not the application, and should be approached as such.
IMHO, the main danger of a "diagonal" move (combining migration and modernization) is more confounding the testing of the result than that result being JOBOL. Actually, JOBOL-like results typically come more from inadequate migration tooling than from conflating migration and modernization. The tooling that we offer is equally applicable to both, so we are very careful to explain that in our view they shouldn't be mixed.
Posted by Stephen F. Heffner
Group: Legacy Migration
Discussion: The mainframe: still alive and kicing
An interesting option that I have encountered in a few cases is "Multi Platform Hosting" where the application has been modified to run on both the mainframe and an open platform.
In one recent case the risk to migrate the full suite off the mainframe was too great for management, however a core application would provide a major benefit in other countries/regions.
The decision was taken to migrate the app for the regions while the home system would remain on the mainframe.
I was not involved so I am unaware if they have kept to single source in this case, however in previous cases that was the preferred solution.
The major downside is extra testing to verify operations on both platforms. However extra testing is can be a benefit as well as a cost.
A collateral benefit was a revisiting, restructuring, and documenting of much of the old code that had been considered to be "too complicated to change".
With all these systems we must approach them with an open mind. No one solution is right for every case.
Always remember that the mainframe, open system, mobile device, are only tools to provide a service to the users and ultimately the business, not an end in themselves.
Posted by Victor Duncker
Post a Comment