Is COBOL The Root Of All (Technical) Evil?

OK, so I used a tongue-in-cheek title to attract your attention, forgive me. A recent blog about the Boomer retirement phenomenon provoked some comments by a colleague with strong opinions about COBOL's useful life. I felt that his comments raised a topic that is substantial enough to warrant its own place in the blogosphere. The comments read, in part:

" I am a boomer myself ... But as a software architect who has to look ahead and figure out what customers and users want I can't wait for the 3270 green screen boomer generation to retire.  It will allow for the acceptance of a new application paradigm. Those stepping up to the plate will not hesite to dump the COBOL garbage and use modern tools to create modern mobile apps that will finally end the drama of IT as today's business disabler. ..."

In an attempt to surface a provocative issue for broad debate, allow me to play devil's advocate for a moment. I agree about 3270 and would broaden it to include all character-based interfaces - VT, 5250, etc. The interfaces they create do not match the business expectations of today's users. But does that really extend to COBOL as well? Should we all be lobbying our business peers to spend whatever it takes to strip COBOL from our application environments? It is certainly feasible if you have a small amount of COBOL remaining, but firms with large amounts may have a much harder time justifying it. Simply put, our business peers do not care what languages we use - they want, what they want, when they want it. Funding technically-driven change is difficult, which is one of many reasons COBOL is still with us.

COBOL is a tool and like any tool it is entirely fit for some uses, and entirely unfit for others. The point being that adjectives such as better / worse, fit / unfit-for-purpose needs a context (purpose) before we can judge it. It is certainly fit for some purposes or its fate would resemble BASIC, ForTran, and other pre-historic languages. But fit/unfit misses the most important point. Even if we accept that COBOL is unfit for all uses, the problems that arise are: the ubiquity of its use, the cost to shed it, and the business benefit the change brings - as compared to other business-benefits those resources could bring if they weren't tied to a technically-oriented mass-change such as shedding COBOL. This line of reasoning falls away in small shops with little COBOL left, and looms large in large shops and big batch-processing environments.

Let's draw an analogy outside of IT. The metric system of measures and weights is undeniably better than the systems we use in the US, Canada, UK and other geographic regions of the world. Predictions of the wholsale adoption of metric measures in the US date back to the 1920s, with no clear adoption in the foreseeable future. The lack of standards causes problems every day in a global economy, (commerce, space programs,etc) so why haven't we all adopted metric? The reasons are similar to COBOL - the ubiquity of our current system, the cost to change and the perceived business benefit.

Turning back to COBOL - if we had all subscribed to the "shed COBOL" mind-set that was prevalent at the dawn of client-server, we would have exchanged all our COBOL for PowerBuilder. Had we done that, we would now be wondering how we could possibly extract ourselves from 20 years of PowerBuilder development and move to a modern programming language. This is where we come back to the link to Boomers - migrating the language is the easy part - what do you do with your people, skills, operating environment, operations procedures, etc? You can certainly replace them all, but in the spirit of devil's advocacy, we should recognize the true scope of the entire effort.

The implication that Boomers = COBOL and COBOL = Boomers over-generalizes the programming population. Some recent research completed by my colleague Jeffrey Hammond in conjunction with Dr Dobbs Journal showed that lots of 50-something folks are coding entirely in newer languages. COBOL was a miniscule part of the survey. Although we can stipulate that a survey of a mainframe-oriented publication would show markedly different results, we can't equate all Boomers as aging COBOL hippies - I don't have the hair for it anymore. *;-)  The main point about the survey data is that the world is not so black and white, but myriad shades of grey. Some Boomers are Java-heads, some programming newbies are trying their hands at COBOL via academic initiatives. 

So, I'd like to close this by thanking my colleague for his contributions to these blogs, and hope that by placing his remarks in a devil's advocate context, he'll not take offense, and together we will raise issues that elicit broad participation from a diverse set of folks in the blogosphere and Twitterdom.

What are your opinions about COBOL - is it a useful tool, a technology to tolerate and minimize as time goes on? Is it the root of all evil? Or is it some hybrid of all of these? Voice your opinions and please note your role in IT - it will be interesting to see whether (for example) the opinions of programmers varies from applications directors from those of systems architects and others. 

Is application consolidation keeping you up at night?

I've written a lot of research around the topic of application portfolio management (APM), and how the tools are slowly maturing from their application mining roots. Although the process of APM applies equally across packaged and custom-appls, the mining tools, until recently anyway, have excluded packaged applications.

Our application development team recently expanded with some new colleagues, and one of the topics a new colleague - George Lawrie - and I intend to take on as a joint effort is application consolidation across custom and packaged applications.

We'd like to know - how important is this topic to you - what are the nuances of it that keep you awake at night, or is it a non-issue? If it is a non-issue, why? Have you done such a good job of staving off redundant and obsolete technology, or is it someone else's responsibility? Please chime in, we'd love to hear about your application environments.

How Do You Define A "Legacy" Application?

 

I had an interesting inquiry with a client that began with this question - "What is the defniition of a legacy application?"  Yikes, I thought - this will be one of those long-ranging, rhetorical discussions that - at the end of the day - lacks the kind of decisive answer clients typically seek during inquiries. The client actually had a good reason for wanting an externally published, formal definition - an external entity was attempting to measure the company's risk by quantifying its exposure to "legacy."

Why repeat the question here? It's not that I don't have published opinion on the matter - I've written a number of pieces on modernization options and defined the term for those purposes, and I get tons of inquiry around "legacy skills" and the how, whether and when to "modernize" legacy applications. Those conversations follow a familiar path, and tend to end up at these points of agreement:

• The app was written some time ago, its original authors moved on taking knowledge with them (lost knowledge).
• Subsequent authors changed the application based on insufficient / lost knowledge, introducing bugs and de-stabilizing it.
• The app is now brittle, and people are reluctant to change it for fear of breaking it.

In the above context, note that the underlying technology that people usually use to define legacy (mainframe COBOL, iSeries AS400, VB 6.0) has little or nothing to do with the symptoms. In fact the the symptoms could describe 5 year old Java, C# or .Net applications just as well as a 30 year old COBOL application.

Past experiences have taught me why focusing wholly on technology as being the cause of "obsolete" can be problematic. In this case, I'd advised in a Webinar that PowerBuilder was a legacy language from which folks should move ahead. No offense to PowerBuilder - I could have cited many other languages as obsolete. In the Q&A section of the Webinar, one attendee asked - "But all of my applications are written in PowerBuilder."  Ooops, scratch that generic advice.

Clearly, my proclamation of "obsolete" required the context of this client's situation as a litmus test. Therefore, I submit that we can't rely (solely) on technology as an indicator. But we can't ignore technology either, because it can contribute to the desire to shed an application if:

• App can't be extended due to the lack of / waning 3rd party vendor support - perhaps APL, PL/I, VB 6.0 are examples.
• App won't scale based on deficiency in original technology choice - app written as a throw-together temporary app, now needs to scale to meet public-Internet traffic volumes and security protocols
• Long-standing poor coding techniques, "patching it fast" rather than "doing it right" over a long period of years for example

A succinct definition of a "legacy application" is more difficult than it seems, but perhaps that's the point - this isn't a simple matter. Deciding the fate of an application needs more than over-simplified terms like "legacy."   Perhaps we should take more of a potfolio view, and replace the entire question with a more appropriate test such as "When is an application no longer suitable for the business?"

Now that I've presented my opinion above, I'd really like to hear from you folks in the blogosphere and the Twitterati - How do you define a legacy app?

Which is it, shortage of mainframe skills ... or jobs?

  

There is a lot of noise lately from 2 camps - one swears that the availability of people with mainframe skills is drying up rapidly - they either forecast dire shortages, or note problems hiring for certain positions internally. Most of the trade press articles are firmly in this camp.

Inevitably, when a trade-press article runs on the shortage of qualified people, individuals with mainframe skills lambaste the author by noting their difficulty in finding a job that requires their skills. I recently started monitoring a Twitter site - @MainframeCOBOL - which tweets mainframe job postings at the rate of several a day. Some folks note that it is a salary issue - employers don't want to pay conventional salary rates given the job market.

But the seeming disconnect between the 2 camps makes me wonder - Where does reality lie in your shops? If you use mainframe technology - are you having trouble hiring or keeping people with mainframe skills? Is there really a glut of qualified people? Is it any different than other skill-sets? Is the supply of folks with other skills appreciably different?

How do you define an "application" for app portfolio mgt purposes?

  Once apon a time ... the definition of an application was easy - firms built accounts payable, general ledger, purchasing, order entry, and other applications to meet the automation needs of the business. The applications were written as monolithic collections of functionality that were dedicated to accomplishing key business functions and had relatively clear boundaries.

However, over the years, technology shifts have resulted in "applications" that don't fit the earlier simplistic definitions. DLLs, Services / SOA, ASPs and Software-as-a-Service (SaaS) all bent the definition of an "application" from its previous form. Looking forward, Cloud computing promises to alter the definition once again.

The definitions of an application thus far share a common catalyst - they all have some linkage to the technology components that comprise the application. But an emerging application management discipline - application portfolio management - calls for yet another twist in the story - how do we define an application for the sake of portfolio management?

With the goals of greater business transparency into the existing portfolio of applications/assets so they can be inventoried, managed, rationalized, streamlined, and governed more effectively - how do you (or would you) define an application for the purposes of APM? I have my thoughts - which I will share once the blogosphere has spoken - I don't want to color what promises to be an interesting and diverse set of opinions. Please share your thoughts freely.

Should Application Portfolio Management Start With Business Process Assessments?

 I heard an interesting comment from an executive at one of the big services firms - that application portfolio management (APM) efforts must begin by mapping business processes for the applications. I really don't agree, but thought it would make an interesting topic to discuss here. Part of the argument stems from how services firms are routinely engaged - to take action against one application or a group of applications to transform, re-engineer business processes, reengineer, refactor or otherwise modernize an application. All are useful activities and techniques, but they are not portfolio management techniques - they are modernization techniques. Modernization and APM live together on a continuum of application activity that includes in order:

• Modernization - the actions we can take against an existing application - monitor & maintain, modernize in some way, replace (rewrite/pkg) or retire.
• APM - which collect metrics about all of the applications to enable better management of the apps in the portfolio. APM collects metrics on all apps, but the goal is to isolate anomalies (duplicate apps, waste, costs not in line with business value, etc)
• Rationalization is streamlining the portfolio and driving better modernization decisions - the actions that stem from th transparency created by APM
• Strat Planning aligns the application information to business perspectives - the goal being to completely recharacterize business/IT discussions so that spending occurs in the context of business need (not necessarily business-unit need).

Interest in APM has grown over the past several years because IT orgs:

• Don't know what they own - in fact they don't even have a basic, accurate apps inventory
• Don't have any metrics about the apps (condition, cost, value to business, resource consumption, number of duplicate apps) So decisions are made based on technical criteria or seat-of-the-pants
• Spend too much on the portfolio, but cannot defend where, when or why to the business - the portfolio is a black hole for resources

APM is not equivalent to BP, does not begin with BP, and cannot take a back-seat to BP mapping activities. In fact I argue that APM should be established first as a governance mechanism:

• Why would you map business process against 10 duplicate apps? (I worked with a client who owned 17 duplicate apps in 16 geographic locations.)
• Why map BP for applications you plan to retire or replace with a package?

I see and appreciate the value of mapping BP in the right cases - to match features required in a new or replacement package, make sure we don't lose a function through application retirement and as a prelude to consolidating 2 apps, etc. but that makes them techniques for modernization, not the starting place for APM. What are your thoughts?