tag:blogger.com,1999:blog-7072705265080833937.post1673096437071317592..comments2024-02-17T08:20:10.226+02:00Comments on SOA filling the Gaps: The mainframe: still alive and kickingAvi Rosenthalhttp://www.blogger.com/profile/14012894476959942872noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-7072705265080833937.post-79323689378249292882012-09-01T17:56:55.513+03:002012-09-01T17:56:55.513+03:00Group: Legacy Migration
Discussion: The mainframe:...Group: Legacy Migration<br />Discussion: The mainframe: still alive and kicing<br />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. <br />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.<br />The decision was taken to migrate the app for the regions while the home system would remain on the mainframe.<br />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.<br />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.<br /><br />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". <br /><br />With all these systems we must approach them with an open mind. No one solution is right for every case. <br />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. <br />Posted by Victor DunckerAvi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-38534807400475960002012-08-31T07:57:42.162+03:002012-08-31T07:57:42.162+03:00LinkedIn Groups
Group: Legacy Migration
Discussio...LinkedIn Groups<br /><br />Group: Legacy Migration<br />Discussion: The mainframe: still alive and kicing<br />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.<br /><br />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.<br /><br />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. <br /><br />Posted by Stephen F. HeffnerAvi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-48373037086320960292012-08-31T07:55:40.194+03:002012-08-31T07:55:40.194+03:00LinkedIn Groups
Group: Legacy Migration
Discussio...<br />LinkedIn Groups<br /><br />Group: Legacy Migration<br />Discussion: The mainframe: still alive and kicing<br />@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. <br />Posted by Florian DelongeAvi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-26322047221259325032012-08-31T07:54:23.829+03:002012-08-31T07:54:23.829+03:00LinkedIn Groups
Group: Legacy Migration
Discussio...LinkedIn Groups<br /><br />Group: Legacy Migration<br />Discussion: The mainframe: still alive and kicing<br />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 <br />Posted by John WatersAvi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-47744507102994112752012-08-31T07:52:35.120+03:002012-08-31T07:52:35.120+03:00LinkedIn Groups
Group: Legacy Migration
Discussio...<br />LinkedIn Groups<br /><br />Group: Legacy Migration<br />Discussion: The mainframe: still alive and kicing<br />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.<br /><br />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.<br /><br />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.<br /><br />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.) <br /><br />Posted by Stephen F. HeffnerAvi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-61997245663532285692012-08-30T17:09:07.765+03:002012-08-30T17:09:07.765+03:00Thank you all for your comments.
I agree with Vict...Thank you all for your comments.<br />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. <br />I do noot agree at all with Nick and John.<br />Nick, there is nothing which fits all: some should Modrernize without Migration, others should Migrate without Modernization and others should Migrate and Modernize.<br />It is a matter of the estimated number of years until Applications End Of Life, Size, Enterprise Platforms etc. <br />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.<br />There are other possibilities such as Modernization of Core Systems and migration of other systems.<br /><br />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. <br />Sometimes Maintainance efforts and costs (including Backlog of Business needs which were not included in the systems) may justify migration.<br /><br /> Avi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-18664169315495620662012-08-30T15:29:11.894+03:002012-08-30T15:29:11.894+03:00LinkedIn Groups
Group: Legacy Migration
Discussio...LinkedIn Groups<br /><br />Group: Legacy Migration<br />Discussion: The mainframe: still alive and kicing<br />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.<br />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. <br />Posted by Florian DelongeAvi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-55789774301567923552012-08-30T14:04:26.829+03:002012-08-30T14:04:26.829+03:00LinkedIn Groups
Group: Legacy Migration
Discussio...LinkedIn Groups<br /><br />Group: Legacy Migration<br />Discussion: The mainframe: still alive and kicing<br />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. <br />Posted by Nick WnekowskiAvi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-28197148396846553472012-08-30T13:51:33.635+03:002012-08-30T13:51:33.635+03:00LinkedIn Groups
Group: Legacy Migration
Discussio...LinkedIn Groups<br /><br />Group: Legacy Migration<br />Discussion: The mainframe: still alive and kicing<br />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. <br />Posted by John WatersAvi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-29937345084855840772012-08-30T09:20:58.030+03:002012-08-30T09:20:58.030+03:00LinkedIn Groups
Group: Legacy Migration
Discussio...LinkedIn Groups<br /><br />Group: Legacy Migration<br />Discussion: The mainframe: still alive and kicing<br />Stephen, and Hans<br />I totally agree, mixing migration and modernisation should be minimised as much as possible.<br />Frequently there will be a small number of batch jobs that require re-engineering to meet acceptable performance criteria. <br />Some interfaces may be unavailable on the new platform requiring re-design and implementation.<br />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. <br />Posted by Victor DunckerAvi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-47641080795285520322012-08-28T15:33:44.087+03:002012-08-28T15:33:44.087+03:00Group: Legacy Migration
Discussion: The mainframe:...Group: Legacy Migration<br />Discussion: The mainframe: still alive and kicing<br />Victor, I can support your position based on a large number of migration projects I've managed and was involved in.<br /><br />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.<br /><br />Availability of skills should definitely be much better as you said as well as supporting tools like IDE's, database tools, scripting etc. <br /><br />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. Avi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-15951482793819924222012-08-28T00:11:01.099+03:002012-08-28T00:11:01.099+03:00Group: Legacy Migration
Discussion: The mainframe:...Group: Legacy Migration<br />Discussion: The mainframe: still alive and kicing<br />Avi --"expensive" and "long time" are, of course, pieces of rope of unknown length. :)<br /><br />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.<br /><br />The objective of modernization is to improve an existing application's quality and/or repurpose it to provide new functionality. <br /><br />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).<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />So modernization should take place before or after a migration, but not during it (unless it's unavoidable, as mentioned above).<br /><br />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). <br />Posted by Stephen F. Heffner<br />Avi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-17691525935814717542012-08-27T17:18:24.636+03:002012-08-27T17:18:24.636+03:00LinkedIn Groups
Group: Legacy Migration
Discussio...LinkedIn Groups<br /><br />Group: Legacy Migration<br />Discussion: The mainframe: still alive and kicing<br />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. <br />IDE Developmenet environment is better once the learning curve is over.<br />JCL conversion to KORN or PERL can create support problems. Extra training is necessary to support operations, etc as part of the migration process.<br /><br />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.<br /><br />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. <br />Posted by Victor DunckerAvi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-3529037771003332462012-08-27T15:34:28.481+03:002012-08-27T15:34:28.481+03:00LinkedIn Groups
Group: Legacy Migration
Discussio...LinkedIn Groups<br /><br />Group: Legacy Migration<br />Discussion: The mainframe: still alive and kicing<br />I feel you need to differentiate between re-hosting and re-engineering when migrating to an open platform. <br />Re-Engineering is expensive, high risk, but provide the largest benefits. <br />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.<br />All these projects have challenges but thats why we are still interested. If it was humdrum then it would not be worth doing. <br />Posted by Victor DunckerAvi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-62438951055941895752012-08-16T03:50:26.063+03:002012-08-16T03:50:26.063+03:00Florian,
I would tend to agree more with Avi on th...Florian,<br />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!<br />Joe Perkinshttps://www.blogger.com/profile/17486780733868745896noreply@blogger.comtag:blogger.com,1999:blog-7072705265080833937.post-52402723001547110132012-08-10T14:39:46.125+03:002012-08-10T14:39:46.125+03:00Group: Legacy Migration
Discussion: The mainframe:...Group: Legacy Migration<br />Discussion: The mainframe: still alive and kicing<br />@Avi:<br />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.<br />Just my 2 cents. <br />Posted by Florian DelongeAvi Rosenthalhttps://www.blogger.com/profile/14012894476959942872noreply@blogger.com