IT organizations continue to operate and support older applications to support critical business processes. The industry has been predicting the demise of languages like COBOL for 30 years and yet many critical business processes ares still supported by these old technologies. This post discusses some of the issues and interim solutions.
1. Stability/Reliability – New applications have stability problems because there are always unknown issues that are discovered over time. When the older applications were implemented, they also had stability problems. If an application has been in production for 10 years, the support team has had 10 years to discover and fix most of the severe problems. Generally, the older applications have fewer stability and reliability problems (although there are always exceptions).
2. Procedural vs. Object Oriented – It is difficult to compare older procedural lanugages and today’s object oriented languages. They each have their pros and cons. COBOL was tedious and had limited capabilities but it was easy to learn which is the primary reason it became an industry standard. The new languages provide significant capabilities but they are much harder to learn and it is difficult to find people with sufficient proficiency in these languages to support the development effort required to replace existing systems.
3. Complexity – The power and nuances of the new languages support the development of very complex and highly flexible applications. Unfortunately, these applications are difficult to test, difficult to learn, and difficult to support. All of this translates to increased cost and risk that must be managed.
4. Security – Older systems included functions to control their own security. The distributed nature of new systems (N-Tier) distributes security across different layers. This significantly increases the possibility for security issues (especially for Web delivered applications). New applications are designed under the assumption that security is provided by each Tier but the prevalance of security issues has proven this to be a false assumption.
I am not a proponent of staying with COBOL. I am simply explaining why COBOL is still prevalent in spite of 30 years of predictions that it will go away. The newer languages need to evolve to make them less complex and more secure so that new applications can be developed at a reasonable cost and with minimal risk.
There are very few people with sufficient proficiency in the newer technologies to staff development projects. The shortage of qualified people is made worse because there are so many different languages making it difficult to find a qualified team with experience in a single language.
As a result, we continue to operate and support old technology. What can be done in the interim?
1. Limit the number of development languages in an organization. Just because a junior developer likes C# doesn’t mean the organization should start using it.
2. Set standards for using the selected technologies. Years ago, this was a common practice in the industry but many organizations allow their developers uncontrolled freedom in the development process which results in cost-overruns and quality issues.
3. Manage the Creative process – A junior developer with 2 years experience has no business designing a new applications. Senior level architects should design and the junior people should build. This is the way the construction industry handles the problem. Would you want to work in a building designed by an unsupervised architect with 2 years experience?
4. Define Roles, Responsibilities, and Skill levels that ensure a career path – A person with 2 years experience is not a Senior Developer and they are certainly not an Architect. Yet, we take these inexperienced people and assign them to lead roles with no career path to ensure they develop the required skills. The same can be said for project managers.