What problem does it solve? Many state agencies who attempted to get off of mainframes have failed to transition to private sector systems, which came at a great loss of money. Our NJ mainframes are written in languages, such as COBOL, which are no longer readily taught in schools. At least in the short-term, it would be cheaper to simply keep the mainframes that we have, and get people to learn COBOL. What is your solution and who does it apply to? Though OIT is ultimately responsible for maintaining/repairing the mainframes, it would be good if we could hire a trainer to teach COBOL to current employees from all agencies (not just OIT employees). Ideally, there could be at least 1-3 people from every state agency who will sign up to learn COBOL. Then we can all mutually communicate with the employees at OIT regarding our own systems in a better fashion, and help each other. What is the anticipated impact? Over time, this idea can expand if we truly do want to get off of mainframes at a later date. We can take this “COBOL Club” and teach them more modern techniques to build something new, or we can simply use them as subject matter experts in the old programming languages. Essentially, we need to know the history of where we came from before we can jump into building new systems. If for nothing else, this idea saves money and leaves the state with ownership over what we have. It would also allow each agency to map out every mainframe screen that we currently have, and perhaps expand upon it (make a wish-list of added goals for a future system) if we do transition away from mainframes at a later date.
Great idea!
How would this end up saving the state money in the short-term and long-term?
This would help with the brain drain due to retirements, etc. Create a "Knowledge Bank" for this and probably a few other languages. A scheduled meet-up for a monthly "Coffee & Code" was discussed a while back, but never took off.
Thanks, Bonny! That’s great! I’m sure you’d be an asset to the team! And Mary, thanks for mentioning “Coffee & Code.” My idea would be more of a rigorous learning commitment that must yield a tangible result to reduce the brain drain that you described. In addition, my idea would unite all state workers to pool resources and share ideas, even if some of our mainframes are different, instead of having each agency “do their own thing” and fail.
The last section of Amanda's suggestion is absolutely a great idea. COBOL knowledge is needed to not only understand and support the current legacy systems but can also be used for modernization purposes to define what works now and how to make it better.
Thanks Kai! Avoid spending millions of dollars on failed private sector ventures. Avoid lost “manpower hours” equivalent to $ millions, as many state workers have worked alongside vendors on failed projects. Avoid the monthly fees that those vendors would’ve charged. Increase productivity by reducing the queue of items waiting to be fixed by the few COBOL workers. All we’d be losing is the cost of the trainer-- but we would have a tangible result for that investment, unlike in the past.
Addressing Andrew's and Holly's concerns - Amanda's idea and your concerns are not mutually exclusive -in fact, they are BOTH needed. During systems modernization projects, knowledgeable, expert software professionals are needed to assist in the modernization projects and to ensure that the new systems produce the same accurate results as the legacy projects. The knowledge base grows and these people can be the trainers on the new systems. Having detailed COBOL knowledge aids in these efforts.
Kai - here's a link for a 2010 vendor white paper (so, please add a grain of salt) regarding the cost differentials for applications running on mainframes vs. open systems - https://www.platformmodernization.org/hp/Lists/SuccessStories/Attachments/1/Alinean-Mainframe-Migration-TCO.pdf - the cost savings can be quite significant.
Informative link, Andrew, thanks. It could definitely be useful in modernizations of COBOL legacy systems. Maybe it's already been used in the State. However, I believe that we are getting away from the purpose and current need of Amanda's idea.
Has anyone charted the cost of the support contracts for keeping our mainframes operational from a hardware perspective? How about pricing out the cost of replacement parts from the vendor or manufacturer, if they're even available? Application functionality is portable, code may not be and hardware certainly isn't. Portability is the key to future-proofing our business-critical applications. Tying those applications to a specific hardware platform is akin to sailing the Titanic...
I just re-read Amanda's excellent idea, and I recommend everyone else do so. Her idea clearly states that it is valuable for the short-term, and it maps out the "value added" points towards the eventual replacement of the legacy systems.
The alternative would be to efficiently modernize State business operations and remove dependencies on legacy hardware and systems to provide better and more resilient services to the citizens. Continuing to spend money on technologies that are far beyond end-of-life (EOL) is a losing proposition. What happens when we exhaust every last support resource available for critical line of business applications without a strategy to move off of them?
I was a former PL/I teacher at AT&T and now I'm a State employee doing other work. I can easily re-learn COBOL and teach it! I would love to - I've been a long advocate of the need to maintain and enhance mainframe knowledge! If you win to go to Stage 2, please include me in your team!
I agree with Andrew. Software modernization is inevitable. If it is not addressed or at least thought of, then a system may inadvertently reach its end of life with the need to quickly modernize it anyway. Let's take the time to look at these legacy systems and find a way to migrate to more modern technology. Technology today offers so much...why is NJ stuck in the past when we can do so much better!
Please don't get me wrong here, I'm not anti-COBOL (I still have a warm and fuzzy every time someone talks about FORTRAN...) but the dependency on a proprietary mainframe is eventually going to be problematic. Here's something interesting that I just found that may be of interest to the rest of the group discussing this - https://en.wikipedia.org/wiki/GnuCOBOL
This content is created by the open source Your Priorities citizen engagement platform designed by the non profit Citizens Foundation