When Your COBOL Developer Is Feeding Pigeons
By Jay Valentine, ContingencySales.com
"Jack, we have 120 critical apps with little or no source code? What do we do if one breaks?"
"Those we patch in binary. I think there may be some old guys in the park who can still do binary!"
There are hundreds of critical business apps running today with no or little source code available. They were written in COBOL or another ancient language, usually on a mainframe, and the developer is long gone, in a park somewhere feeding the pigeons.
Or there were multiple acquisitions of that insufferable billing system and now 8 billing systems are making up the whole and 3 or 4 of them have little or no source.
The issue is how to meet the compliance issues today when that app breaks or cannot be proven to do what it is meant to do. And if it is a financial app, the risk just went way up.
The typical answer is to bring in a small army of consultants, do app reviews, look at reports, find flow charts if they are around, which they are not. Then there are months of requirements definitions and then start the process of an app rewrite.
And they will charge the poor customer a million, perhaps many millions to rewrite the app.
That process takes 18 - 36 months and when done has added ZERO value to the business. It runs pretty much the same as it did before.
Is that a good investment?
Not in the day of System Oriented Programming.
System Oriented Programming is the next step in microservices and object-oriented programming. It enables those gnarly legacy apps, with little or no source code, to be rewritten in a quarter, using only the data feeds, input and output, as the ingredients.
System Oriented Programming not only delivers these apps in record time, they arrive in containers, run 1,000 to a million times faster, use 90% less storage, and can be updated using the most common, inexpensive skills.
Virtually all corporate applications, especially those ancient COBOL ones, are made needlessly complex because of the infrastructure in which they had to perform.
Current application software is about 90% or more about dealing with the complex infrastructure of VMware, security products, reporting products, Oracle, non-SQL databases, and the thousands of related products.
Each of these is a general-purpose system. Some are worlds unto themselves. Each need highly paid technical experts to keep them running. But the dirty little secret was they were not needed in their entirety to run the app.
System Oriented Programming replaces the obsolete, overly complex current tech stack with a sliver of a tech stack customized for that specific app. There is a database, middleware, graphical user interface purpose built for that one application. All the extra junk is tossed out. You do not pay for what you do not use. You do not need tech talent for what is not there. You do not need to write complicated code for something that does not exist.
When System Oriented Programming encountered some of these really old guys they were not surprised. They immediately understood the implications of delivering not a microservice, but a fully containerized micro APP.
They said, "wow, you guys are now writing code the way we did it 50 years ago. Welcome to the best way to get an app done!"
These original coders were not gifted an O/S, a DBMS, or a virtualization layer. They had to build apps that solved a problem the quickest way possible without them. They built skinny apps, that ran fast, used minimal storage, and optimized hardware.
System Oriented Programming is a way to convert the most complex legacy apps, in a quarter, run them in parallel with the current system, and later, discard it.
Sometimes, those guys feeding the pigeons look like they were pretty smart 40 years ago.
About The Author
Jay Valentine is the CEO of ContingencySales.com, bringing disruptive tech products to market without venture capital and the VP of Sales for portfolio company Cloud-Sliver.