Google Translate and the Mainframe…


Strange question I know for a blog title, but just got off the phone and inspired to put virtual pen to paper.  In a multi-cultural world where many languages are spoken we never hear the debate about which national or even wider language is ‘better’ than any other language.  The UN to my knowledge are not championing an international agenda to move countries to adopt a ‘newer more sexy’ global language…

However in the IT realm certain languages are perceived as better and are therefore justify expending large sums of money to get the promised land of a new language.  Take for example a client executive who just called me about a cloud opportunity for mainframe.  The client scenario is that the client wanted to migrate from COBOL on their mainframe to .NET.  3-years in the project has failed, the promised land of .NET has delivered little if any working functionality, the mainframe environment has continued to grow in the interim, the business challenge remains… The net net is that 3-years has been lost, money has been wasted, the management team has moved on, but the business still faces the same challenges.

COBOL, Fortran and PL/I are all languages, they are solid well understood languages, think of them as something like Mandarin in the spoken sense.  Java, Ruby, Python and GO are also solid, well understood languages, think of them as Swedish in the spoken world.  The challenge is not the language, no CEO ever asks a team to embark on a project to change an IT language.  CEO’s ask their IT teams to drive innovation, deliver the new app, drive delivery optimisation, but in all cases delight clients!

As Enterprise Architects look to deploy new Line of Business driven applications the discussion should be how do we leverage the existing architecture, using my analogy the body of spoken and written word that existing in a country, to build on…  In the same way no country premier would ask his country to change its language from say British to Spanish to achieve economic growth for instance, in no way should an IT leader embark on a a change of language to deliver on a business driven objective…

So as you face the challenge of how do you deploy your new application, don’t ask how do I throw all of this away mainframe stuff away and go to GO, Erlang, Ruby or Python, what you should be asking is how do I leverage the business logic and proven data structures that sit on the mainframe and allow new modern interfaces and API’s access that data and logic.  The API Economy is alive and well on the mainframe, be it RESTful API’s connecting to CICS, IMS or DB2 or be it Linux open source apps running co-resident to z/OS applications…

In short no language is better than any other language…  Don’t embark on a risky re-platforming exercise just to get to a new application programming language, its both a risky endeavour, but it also realises little or no business value. No end client will ever care about how the app they engage with is written or where it runs, what they will care about is that its quick, always on and most of all delights them… put your focus there…


5 thoughts on “Google Translate and the Mainframe…

  1. VERY true. The only time replatforming is a valid solution is when the op-ex is demonstrably lower than your current op-ex and you anticipate being on said platform for long enough to amortize the cap-ex involved with the migration. I say this as someone who is often quick to suggest rewriting modules of software from scratch when maintenance costs exceed rewrite costs.


  2. Moving to another platform and also another language is quite risky and you stand to lose a lot, not just the usual problems of performance but the intangibles, like the IP value of your code. Most code, not matter what the language, have quirks that don’t necessary translate from one language to another let alone to another platform. There is a undetermined value of the Intellectual Property that can’t really be measured.

    Instead, the right thing to do is to be more concerned of how to get more value out of your current code with small but targeted enhancements. For mainframe COBOL code, right now, that’s using the new Optimizing features out of the Enterprise COBOL that now uses the new features of the new IBM z13 mainframes.

    Making decisions to move by just looking at part of the picture (saving $$ in the short term) is being shortsighted. One needs to see the entire picture. How will you maintain that new code? Training personnel on the new platform and tools to help you manage your source — your source code management system to name a few. Can your new code and platform meet your capacity and response time requirements? Most major business rely on 10’s of millions transactions per hour every minute of every day and every year.

    With customers that have 10’s of thousands of programs, conversion will be massive and problems will increase dramatically. Don’t bet your business on a whim.

    We have a great number of discussions about COBOL that you don’t want to miss. See



  3. Hi Steve,

    Not sure I’d say, “…no language is better than any other language…”, every language has advantages and disadvantages, even beyond the technical aspects – from incumbency, “we have ten million lines of PL/I” to ubiquity, “C/C++ skills are easy to come by” to financial architecture, “converting that COBOL to Java could save us millions per year on MLC cost.” To me, the important point is to ensure that you are asking the RIGHT questions:
    – What is the desired end state for this application?
    – What are the risks of changing the language, the platform? What are the risks of not changing?
    Technology like APIs allow you to decouple parts of a complex application so that changing the implementation of one part does not cause a ripple effect across the rest and allows you to attack the problem in pieces, rather than a risky big bang.

    Scott Fagen

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.