Many business information system projects are motivated on the basis that the existing systems are obsolete. This article challenges that argument with regard to a significant number of systems and presents information that will enable executives and managers to take a pragmatic view of this debate
<<< PREVIOUS SUB-SECTION: The Critical Human Foundation
NEXT SUB-SECTION: From South Africa >>>
One of the drivers of new systems in business today is replacement of “ageing” systems. Problem is that software does NOT grow old, only the programmers do and new programmers can be trained.
Legitimate software obsolescence is driven by genuinely obsolete hardware coupled to software that is associated with the operating environment for that hardware for which there is NO effective port to new systems, or badly maintained software – which frequently comes about because of a CIO who decides to kill the system by NOT investing in people and maintenance. The latter case can be remediated
There ARE situations in which legacy software can have its life extended considerably. This article discusses this. Following are some key points:
1. Instructions for the bricklayer
Source code is “instructions for the bricklayer” – the English like language is translated by the compiler into binary code and processor and device addresses – in this respect the compiler is like a bricklayer simply following instructions to generate the executable code.
2. Programming language ONLY for the programmer
Programming languages are simply there for the convenience of the programmers so that they can write more complex and elaborate software applications.
To say that a language is obsolete is to say that the people who knew how to program in that language are either all dead or have moved on to other languages. Insofar that in even the oldest languages there are still programmers alive the question then becomes one of providing the right financial incentive to bring old programmers back from other languages.
Alternatively, NOTHING prevents you for training young programmers on old languages. The world is full of factories with old machines that are maintained by technicians and mechanics who have been trained up on equipment that was manufactured before they were born. There is NO reason NOT to do this with software.
3. Development languages are a fashion industry
Application development languages have historically progressed to a point and then been superseded by new languages that have been written to perform different functions, but to a point it is a fashion business. It is my view that this trend is coming to an end. The current mainstream languages will probably be around for a very long time.
In some cases of really leading edge technology applications there MAY be real benefit moving to a new language, BUT in the case of core mundane operational business information systems there is generally little or NO benefit. Remember always that you can develop new components with a new language and leave the existing components in the old language. Once they are compiled the computer does NOT know the difference.
4. Software NEVER wears out
Software NEVER wears out, it has NO moving parts. The older languages died out because the computer processors died -- that does NOT happen anymore.
5. Once software works it always works
Once software works it ALWAYS works unless some human being does something that stops it working – either as an act of incompetence, negligence or sabotage.
6. Mainstream legacy languages remain valid
Mainstream older languages, such as Cobol in particular, remain valid because compilers have been ported to run on modern processors so barring minor conversion idiosyncrasies old code will work perfectly well on modern computers. See “COBOL Still Used More Than Google”.
7. Once compiled the processor is ignorant of the language
It is vital to be aware that once compiled the processor does NOT know whether it is running 30 year old Cobol or the latest “dot net” or whatever language. The language is PURELY for the human beings who write the program.
8. “Obsolete” is therefore most frequently a fashion statement
“Obsolete” is therefore most frequently entirely a fashion statement, the developers are still around and many will happily work on old code for a fair wage. Many of the old guard prefer the older languages because they are leaner and more efficient.
9. It is NOT necessary to replace the entire application
Note that there is NO need for all parts of a software application to be written in the same language. If you have an elderly Cobol suite of software and you want a pretty web front end interface in the latest language, NOTHING stops you writing the new front end in that language and writing an interface to the database of the old application or writing an interface to feed data files from the old application to the new database.
There are tools specifically for that purpose such as “Advantage Data Transformer”.
10. The 80:20 Phenomenon
Note also that as with most things in life, of the order of 80% of the software that is used in a business does NOT change for years. This can remain in your legacy language. Just replace the 20% of the software where there REALLY ARE benefits f
rom upgrading. The minute you move away from a mind-set that says that you MUST replace the ENTIRE solution interesting possibilities open up.
11. Mainstream databases are still in existence
Some of the older databases HAVE died out and this MAY legitimately drive replacement but in MANY cases there is a solution and some mainstream databases that have faded from the limelight but are still out there and supported, such as DB2 and Informix -- you just have to look.
Again, in many cases the problem is fashion NOT technology obsolescence.
12. The ONLY limitation is the ingenuity of the developers (and their willingness)
In many (most?) cases the limitations with regard to legacy software relate to the ingenuity of the developers and managers and their willingness to find solutions.
It is TOO easy to tell management that the old systems are obsolete because you have a career need to learn a new language so that you are more marketable and can earn a higher salary, or just because it is an adrenalin rush to learn something new. Those are NOT valid reasons.
Bottom line is that probably 90% of the legacy application out there CAN be maintained and used indefinitely and can be extended by bringing in selected modern components.
It is also so that if you look at the REAL costs of implementing and operating the major ERP and related products and apply a percentage of that cost to maintaining your existing systems you will be very well off. There may WELL be a case for a project to remediate and strengthen your existing systems and extend them to better support your current and future strategic position.
Note also that, given the massive failures that are occurring, the business risks associated with progressively and incrementally remediating and enhancing your existing systems are MASSIVELY lower.
Dr James A Robertson PrEng
11 September 2014
Download Old Software IS Viable -- White Paper in Adobe pdf format
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.
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!
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.
Business Systems NOT delivering?
Call the Business Systems Specialist
Dr James A Robertson -- has been involved in the effective application of Business Information Systems, including but NOT limited to ERP, since 1987 and in the profitable and effective use of computers in Business since 1981.
Drawing on a diversity of experience, including formal military training in Quick Attack techniques at the Regimental Commander level, Dr Robertson has developed highly effective methods of investigating any sub-optimal Business Information Systems situation -- be it an established system or a stalled project or any other source of Executive frustration -- quickly and concisely diagnosing the root cause of the problem and prescribing concise practical actions that Business Executives can effectively act on see the Pulse Measurement page and also the Sample Reports page for redacted real reports.
He has also developed highly effective methods of strategically enriching systems to unlock the full potential of existing investments, see the Precision Configuration page and couples this to architecting small pieces of clever software that harness the full potential of your investment, see the Software page.
If you are having problems with your systems, your project or your IT Department, call The Business Systems Specialist
Business System Failure is RIFE -- we offer insight into why this happens AND WHAT is required to prevent it.
Failure is at epidemic levels with massive damage done to client companies -- if you are NOT aware of the extent of the problem please visit the About Failure page for a catalog of major failures running to billions of Pounds and Dollars.
All evidence indicates that the established players do NOT know how to deliver stable, reliable high value solutions that WORK.
There HAS to be a better way!
This website provides information relating to that way with a large collection of white papers, presentations, standards documents, etc that you can use to start bringing the situation under control
We also offer high level advisory services with regard to the application of the principles advocated on this website
We offer an ENGINEERING APPROACH to addressing these issues
By Engineering I mean the formal, structured, highly disciplined, highly systematic, highly practical approach that consistently delivers results in ALL areas of human endeavor where formally trained and certified engineers are the ONLY practitioners permitted to operate -- think large buildings, factories, motor vehicles, aircraft -- highly complex systems that work at a level that we take it for granted that they WILL work and where failure is all but unthinkable and, when it happens, attracts immediate public attention and rigorous investigation directed at ensuring that such failures are prevented in the future -- in fact, everything that the management consulting industry that implements complex software systems is NOT
This approach is discussed further on the Engineering Approach page.
A simple confidentiality and non-disclosure agreement which you can tailor and elaborate on as you see fit and which may vary depending on your legal jurisdiction and your attorney. I recommend that this initial document is kept simple as you want ALL persons attending the initial tender briefings to sign this
You would possibly have a much more comprehensive agreement for your short list bidders and possibly more comprehensive still for your final choice although I personally hold that very detailed documents of this sort tend to be excessive
In 2003 I undertook an in-depth analysis of all the information and experience that I had gathered with regard to the factors giving rise to Business Information System failure including ERP and general IT and classified this information into a number of categories including "The Factors Causing Failure" and "The Critical Factors for Success" based on this I developed a two day Course "The Critical Factors for Information Technology Investment Success" which is still offered today.
Based on this I wrote the book of the same name, which is available in electronic form here for download:
Click here to send us an email subscribing to our free newsletter -- all articles posted by James Robertson will be emailed to you
James has a very detailed profile on LinkedIn should you require further information about him.
You can also connect with him on LinkedIn at http://www.linkedin.com/in/DrJamesARobertsonERPDoctor
James has an open networking profile -- click on "Connect" and use email address James@LinkedIn-at-JARA.com.
You can contact us on
LinkedIn at http://www.linkedin.com/in/drjamesarobertsonerpdoctor
Facebook at https://www.facebook.com/james.a.robertson.393
Mobile: +44 (0) 776-862-2875
Landline: +44 (0) 207-059-0007
Fax: +44 (0) 844 774 4580
There is a large body of white papers, articles and other content produced by Dr James Robertson available on this website
Please click here to visit the detailed listing of articles
About Dr James A Robertson PrEng -- The Business Systems Doctor -- and Other Topics
Catalogue of Major Business Information System Failures
About the Engineering Approach
James Robertson's Value Add
Attributes of a HIGH VALUE solution
Recognizing Business System Failure
The Critical Human Foundation
Old Software IS Viable
From South Africa
Competencies of Dr James A Robertson PrEng
About Professor Malcolm McDonald
Table of Contents
About my relationship with the Almighty Creator, Yah the Eternally Self-Existing
Comments relating to the Business Systems Industry and other topics
Testimonials and other positive material regarding James Robertson
List of Articles
Achieving High Value Business Information System outcomes
Executive Custody -- What is it and HOW do you get it?
The REAL Issues in Integrated Business Information System Success
Part 1: Introduction
Part 2 -- Mythology and Lack of Executive Custody
Part 3 – Strategic Alignment and Precision Configuration
Why your ERP is NOT delivering and HOW to FIX it
IT Project Management
CEO Anthony Lee Comments on his experience of the Pulse Measurement
No Charge Guarantee on the Pulse Measurement Service
Examples of Pulse Measurement Outcomes
Critical questions regarding the Pulse Measurement™
The Pulse Measurement Workflow
The Critical Factors for Business System (ERP+) Investment Success in the Pulse Measurement
Indicative Pulse Measurement Durations
What is a JAR&A Pulse Measurement?
Survival of the fittest – why it makes sense to measure the pulse of your business
Examples of Pulse Measurement Outcomes over 24 years
Sample Pulse Measurement Reports
Strategic Essence: The Missing Link in Business Information Systems
Strategic Essence: Overview
Strategic Essence: Part 1 -- Strategy Defined
Strategic Essence: Part 2 -- Differentiation
Strategic Essence: Part 3 -- The Essence IS Different
Strategic Essence: Part 4 -- The Essence should be the Point of Departure
Strategic Essence: Part 5 -- Discovering Strategic Essence
Strategy -- the Essence of the Business: What is it and how do you develop actionable strategic plans?
Simple Steps to Increase the Strategic Value of your ERP Investment
Free Strategic Snapshot Toolset and Manual
A strategy focused planning system beyond traditional budgeting
Tough IT and ERP Procurement and Contracting that Works
Robust Business Systems Procurement
Part 1 -- Introduction
Part 2 -- Bill of Services, Laboratory, Go-live Certificate, etc
Part 3 -- Executive Engagement, Bid Compliance, Adjudication and other matters
Guidance and Advisory Services
The Art of Project Leadership
Why Regular Communication with the CEO is Vital
The Business Simulation Laboratory
Precision Configuration and Strategic Business Information Architecture
Precision Configuration based on Strategic Engineered Precision Taxonomies
The JAR&A Cubic Business Model
Highly Structured Strategic Chart of Accounts -- a Vital Element of your Corporate Information Arsenal
The Product Catalogue -- an Essential Element of any Precision Configuration
Attributes -- answers to the questions you have NOT yet thought to ask
Case Studies of Notably Successful Projects with high value Precision Configuration
092 Doing things differently and better -- ASCO Case Study 2-- BPM Summit 2013
088 Strategic ERP Invesment -- ASCO Case Study -- Service Management Conference and Exhibition Africa
026 Information Architecture and Design of FIS for Rennies Group -- Financial Information Systems Conf
018 CRM Risk Control: Designing and Implementing an Integrated Risk Mgmt Sys -- Integrated Risk Mgmt Conf
011 V3 Consulting Eng: Benefits of MIS to Professional Practice -- SAICE 15th Ann Conf on Computers in Civil Eng
Strategically Enriching your Business Information Systems
Part 2 -- Principles of Data Engineering
Part 3 -- Steps in applying these recommendations
Simple Steps to increase the strategic information value yield from your Business Systems Investment
The Full JAR&A Taxonomy Manual
Part 1: Introduction, Problem Statement, Definitions and Examples
Part 2: Why Use JAR&A, Required Knowledge and Experience, Cubic Business Model and Chart of Accounts and Taxonomy Software
Part 3: How to do it, Case Studies and White Papers and other References
Example General Ledger Manual
Business Process -- Irrelevant, Distracting and Dangerous
The RIGHT Approach
Custom Strategic Software Design and Oversight of Construction
Standards for Custom Software Specification
What IS Software?
Critical Factors for I.T. Success
A Moral and Ethical Dilemma -- Systems that Fail
Case Studies examining Business Information System failures
The BBC Digital Media Initiative Debacle
The Bridgestone -- IBM Conflict
Speaking and Training
Showcase of Conference Presentations
Most Viewed Presentations
Briefings and Seminars
Why your ERP/BIS is NOT delivering and HOW to FIX it
ERP and IT Procurement that Delivers Results
The Critical Factors for IT and ERP Investment Success
Conferences and Public Presentations
Conferences 80 to 99 -- 2009 to Present
Conferences 60 to 79 -- 2005 to 2009
Conferences 40 to 59 -- 1996 to 2005
Conferences 20 to 39 -- 1994 to 1996
Conferences 01 to 19 -- 1989 to 1994
On-Line Seminars (Webinars)
Webinar on Preparing and Presenting Webinars
Contacting James A Robertson and Associates Limited