The Bridgestone project commenced with a fundamentally unsound motivation, existing systems were written in COBOL and therefore needed to be replaced.
Note that the existing systems were working fine, they worked so well that Bridgestone had tens of millions of dollars to pour into their massive new systems project and still remained in business.
“But COBOL is obsolete” I hear you say.
Really?
Interestingly, a report dated 23 June 2014 by Cameron Philipp-Edmonds headlined “COBOL Still used more than Google” reports that estimates indicate that there are 200 times more COBOL transactions processed daily than there are Google searches!
See http://www.techwell.com/2014/06/COBOL-still-used-more-google
Try searching on Google for “COBOL Compiler” in quotes – an exact match – Google returns 93,600 results.
Fact is that COBOL is FAR from dead!
In fact, there is NO valid technical reason why you cannot keep your existing COBOL programs running for ever.
The programming language is for the people NOT the computer
COBOL is a programming language like any other. It works by offering an English-like language that contains a wide vocabulary of instructions each one of which instructs the computer to perform an EXACT sequence of steps. For a given instruction the response of the computer is always entirely predictably the same and WILL ALWAYS be the same – UNLESS you move the software to another COBOL Compiler in which case there may be some changes in nuance. But those issues are always amenable to resolution so that you CAN continue – the lesson is to do detailed research in the event that you have to migrate your COBOL to another compiler running on a different hardware platform.
Note that once the source code (the English instructions) is compiled the computer has NO knowledge of where the binary strings that it executes came from. To the computer COBOL looks identical to the latest and greatest most modern language.
A programming language is PURELY there for the developer, to make their lives easier instead of flipping front panel switches. The ONLY thing that dies out with an old language is the human beings who know how to use it and there is NOT a programming language on earth today that is so old that any significant number of developers HAVE died off. So for ANY mainstream old language, of which COBOL is surely the leader, there are very substantial numbers of human beings who once programmed in it and who with the right financial incentive will program in it again.
A world full of old buildings, factories, machines, etc
And THAT is, in fact NOT the point.
We live in a world with numerous buildings, roads, railway systems, factories, etc that are decades and even centuries old. We do NOT demolish them because the people who originally maintained them have moved on or died, we train new people to maintain them. Your ability to maintain your COBOL applications is ENTIRELY a function of your willingness to employ staff to maintain them.
“But my CIO says COBOL is obsolete” – harsh reality, a LOT of IT people thrive on the thrill of NEW so when your CIO says that COBOL is obsolete, that is, in narrow terms correct BUT it really means “I cannot be bothered to make the effort to maintain it and to hire and train up new people in order to keep it going”. Fundamentally “COBOL is obsolete” is an IT Department empire building statement!
It will ALWAYS cost you less to maintain your existing applications than to replace them.
You can bolt on or build NEW software ALONGSIDE your COBOL applications
There is an ADDED TWIST. There is absolutely NOTHING that prevents you building NEW software alongside your COBOL or other “obsolete” software. Leave the COBOL or other old software doing what it has done reliably and dependably for the last thirty years – the time that it has taken your company to become so profitable using the software that you can afford the luxury of embarking on a big budget new system project.
If you need a web interface, well then write a web interface in whatever modern language takes your fancy. If you want an all singing all dancing data warehouse then do it, there are plenty of tools that will load your data from you old databases to new ones.
This is a lengthy subject but enough for now, I hope that I have made my point? See “Old Software IS Viable” for more information.
Bridgestone did NOT “HAVE” to replace their COBOL software
The brutal truth is that it is HIGHLY UNLIKELY that Bridgestone HAD ti replace their COBOL software, they could have spent a few million dollars, ported to a new compiler and new hardware, fixed the glitches and carried on for as long as they wanted.
But, I hear you cry, the new technology brings with it all sorts of competitive opportunities!
Bridgestone bought SAP.
Does it, really?
I doubt that Gary Garfield will agree with you.
Correctly implemented with a strong strategic focus an integrated business information system CAN deliver dramatic benefit – see my article “Attributes of a HIGH VALUE solution”.
BUT the value lies in the manner in which you configure and use the software NOT in all the fancy gimmickry that are the rage in the industry today!
The value lies in a high value business case NOT a desperate “we HAVE to change because our system is obsolete” – you do NOT have to be a victim of technology obsolescence – you CAN take charge and make informed business decisions in this area, like any other.
Note that for the same reasons there CANNOT have been an immovable deadline with regard to Bridgestone moving off its legacy systems. I am quite sure that today Gary Garfield will look back and see that no matter WHAT the motivation he could NOT actually afford to switch off his old systems when he did. But someone misrepresented the situation to him and his executive team.
Be interested to know who because whoever was responsible for the advice that Bridgestone HAD to change over THEN is the person who is ACTUALLY culpable with regard to what followed.
That said, there IS a case for new systems when the old systems are ragged and have not been maintained and NOT kept up with the business. BUT NOT at any cost.
See the Bridgestone article for more information on that particular situation.
A different spin – SAP ABAP is similar to COBOL!
Interesting to note that Bridgestone moved to SAP with a major SAP development investment that gave huge problems.
Interestingly Wikipedia reports that SAP’s ABAP (Advanced Business Application Programming) language is “somewhat similar to COBOL”!
So, because COBOL is obsolete we move to SAP which uses a language similar to COBOL?
I wonder if the Bridgestone CEO was advised of this before he signed the order for SAP?
Conclusion – it is assumed you DO have a valid case to move
My fundamental point is that you should NOT scrap your old systems for the wrong reasons move because you have evaluated the situation and concluded that there IS a strong high value business case that supports the decision to move.
Do NOT become a victim of IT hype and ONLY undertake the project because you have a clear BUSINESS understanding of the value you will create and how the BUSINESS will achieve that outcome!
This website is based on the assumption that you DO have a sound business case for moving to new technology and want to do this with minimum risk and maximum value add.