IT Needs a Culture Change

By Lou Washington

(Back to article)

What happens when you need certain skills in the global workplace and they are not readily available? You could try outsourcing to a different region, or calling up the nearest college and telling the curriculum folks they really need to be turning out more widget operators or whatever.

But that’s not a simple solution for an IT industry facing a shortage of COBOL programmers. Demand for COBOL training has fallen to the point where colleges are not even offering it. This despite the fact, that there are 180 billion lines of COBOL code in use today and that COBOL programmers are in such demand they can command big-time money.

For most companies, the COBOL brain-trust is currently focused on things like pension payouts, retirement villages and golf communities. In nine years, where will they be?

It is estimated that nearly 80 million people will be retiring over the next 15-to-20 years in the U.S. alone. These people will take with them a boatload of knowledge.

If you’re talking IT, this has to be a bit troubling. And not just for COBOL shops. I’m talking about the many elements that go into what are euphemistically referred to as "legacy" systems.

Unplanned, Layered Progression

Mark Lillycrop of Arcati Research points out an interesting phenomenon that is somewhat peculiar to the IT industry: These so-called legacy systems have not really evolved in the sense they developed and changed over the years. It would be more accurate to say these systems have been built one on top of the other.

Each succeeding technological development, fad or trend has been laid down in layer after layer of developed code and system architecture making up the whole of the deployed system.

One is reminded of an ancient city that has been built and rebuilt many times over the ages. Archeologists can dig down through the layers to find all manner of things. On top may be the asphalt or concrete of our age, but not far beneath that, you will find cobblestones and beneath those you will find gravel and finally dirt. Each layer is supporting the other. You can’t pull out the cobblestones without destroying the asphalt on top.

In a sense, you are just as dependent on the gravel and cobblestones below as were the Romans who built the road in the first place.

Forrester analyst, Phil Murphy, expanded on this in a January 2006 interview in Optimize magazine. The issue is not that a single ubiquitous language will suddenly be without a population of programmers to maintain it, rather the issue is this phenomenon is repeated over and over with multiple generations of languages, architectures and strategies.

We would like to think of our “systems” as being unified, consolidated and efficiently interfaced with one another, perking along while a few systems engineers closely monitor their performance. We visualize the clichéd white-coated computer operators adjusting this knob, tweaking this bit of code, squeezing every MIPS of performance out of the hardware, minimizing the consumption of resources and maximizing the response time for our end-users. The reality is quite different.If you’ve ever been to the San Jose, California area you may have heard about the Winchester Mystery House. This house, a mansion by any measure, was the home of the widow of Oliver Winchester, founder the famous armaments company that bears his name.

When Mr. Winchester passed on to his reward, Mrs. Winchester commissioned the construction of an addition to their home in San Jose. Once started, the good lady could not stand the thought of firing the construction crew so they just stayed on the job ... for about 30 years.

The result is a rambling unplanned structure that sprawls over a huge parcel of land. The house features stairways that terminate in the ceiling, hallways that wind around going no where, windowed towers and spires with no access, chimneys that terminate at the roof, doors that open into brick walls, rooms within rooms and so on. The place is bizarre — an unplanned, barely functional, inefficient octopus of a house.

This is how our systems have evolved. A little brick over here, some frame siding over there, blue paint here and red paint there. No overall plan, rather an evolution of visions, strategies and technologies; each one being totally appropriate for the time and circumstances in which they were implemented.

This is the systems model that has developed over the years in our industry. Build, connect, adapt, connect, buy, connect, adapt, connect and so forth. We must learn to work with this and ultimately perhaps to replace it with something better; but first we have to work with it as is.

What We Need

What the IT industry needs is not just a new crop of people with older skills. What it needs is a genuine culture change that promotes the concept of knowledge sharing and a culture that recognizes that those systems supporting our enterprise year in and year out have immense value. Further, developing those systems must include more than bolting on new modules built in current languages. Whole systems must evolve, not just connect this part or that layer.

So, the problem is much bigger than just COBOL and a dearth of COBOL programmers. How do we approach this? What gets the knowledge widely dispersed? What gets people thinking about the whole instead of some tiny part?

We have learned two valuable lessons in the IT area over the last few years: First, we can’t allow the IT group to insulate themselves from the rest of the enterprise. They cannot be locked away in some technological equivalent of a monastery creating systems and solutions on their own, without external input, pushing these out and into the enterprise.

By the same token, total control and authority for IT strategy and implementation cannot be decentralized into individual departments or group management. Both of these approaches have failed to deliver successfully for the enterprise.

What is needed is centralized administration of the IT operation with distributed responsibility for ultimate oversight and direction. The second part should allow input from assorted elements in the user community, upper management and major functional groups within the enterprise.

Technology should be selected based on several organization-friendly elements including: adaptability, scalability, compatibility, and traceability — meaning the technology can be documented in a way that future generations can understand how it works and make periodic adjustments as needed.

Finally, I think IT management has the responsibility to facilitate communication and skills training among all IT employees. If your lunchroom has a group of old-timers sitting around one table while the “kids” hang out at their own table, you’ve got a problem.

Have some contests, create teams that are made up of kids and geezers. Have knowledge-exchange seminars. Put the most successful teams to work on your most critical projects.

This is how you change the culture that got you into a corner in the first place. You will be developing a self-sustaining system that will not obsolete itself, but rather fix itself as a natural part of its own evolution.

Lou Washington is the master of MIPS at software and services provider Cincom Systems. In his spare time, he’s also a senior business manager. He can be reached at lwashington@cincom.com. Nearly one-third of Cincom’s customers still use its products running in the mainframe environment.