Analog Computing Machine in Fuel Systems Building Lewis Flight Propulsion Lab-NASA

Retraining Mainframe COBOL Programmers to Object-Oriented Java Programming, via Requisite Organization

E. Forrest Christian Computers/IT, Managing, Organizations 1 Comment

A few weeks ago, I talked about the basics of Requisite software developmen and organizational design affects the quality of software projects. Today, I will continue that, answering Paul’s questions about retoolling a mainframe shop to object-oriented programming (OOP).

Computer solution groups within companies have different names, often from when they started. Management Information Systems (MIS) and Data Processing Center (DPC) come from the era when mainframes ruled, when if you had access to a computer it was through a green WANG terminal on your desk. Information Systems (IS) comes from when UNIX-based systems began to take over the desktop and midrange servers. Information Technology (IT) came about when the Windows-based client-server workers took over everything. I’ll be talking about MIS shops, based around large mainframe operations, who are moving towards an IT shop that creates object-oriented (OO) software inhouse.

Mainframe-focused MIS Organisation

Let’s start off with looking at how Management Information Systems (MIS) organizations were organised. One of the things that most people find surprising who did not grow up in the mainframe MIS environment, including those of you in management, is how low-level the work inside the firm really was. Most of the mainframe programming was actually done by externals, often from the mainframe vendor from whom the company leased the mainframe. Back in the 1960s, a company never bought a mainframe: they leased it from the vendor, such as IBM, DEC or Compuware. These vendors often created the software that ran the corporate computing needs since it involved having an intimate knowledge of the mainframe operating system and database. These things were very complex entities, much harder to understand than the simplified systems that we now enjoy.

Back then, “programmers” often only created flowcharts. “Data processors” or “data entry” then put these programs onto punchcards which would be fed into batches into the computer. The programmers did the high-level work, thinking out the way that the data moved from place to place. The data processors would turn this into binary code, a tedious but necessary step to use the punch cards.

This situation resulted in fairly low-level, operations-oriented computer groups within the company. The high-level work — what I had called development, design and architecture — was handled by the vendor, such as IBM. The inhouse group created the punch cards from their flowcharts or more developed programs, and did the various maintenance programming, altering programs to solve problems or needs discovered after the initial installation. Much of this work involved creating report jobs or queries of the database from a template. The worker would get a request, look up the revelant template in the template repository created by the vendor, and then create the report job using the template.

As a result, the MIS organization really wasn’t all that high-level. Using the worklevels that Elliott Jaques discovered back in the 1950s, the organization would look Figure 1.

Mainframe MIS organization chart

[Figure 1: Mainframe MIS Org ChartClick here to see full size]

This represents an MIS organization at a Fortune 500 company with large computing needs. The organizationd did not need a “Chief Information Officer”, only an operation manager. Decisions about what needed to be computed, what information could be gathered, and even what vendors to use was mostly decided at upper levels at an abstract level. Because of the need for accounting drove most number crunching, Accounting ran most MIS departments. The vendor would then create the software that they would implement. An handover process then happened where the vendor would provide appropriate maintenance training to the company’s MIS staff.

MIS was about operations, not strategy, and was therefore run at a low level.

Moving to Client-Server and Objects

Many organizations went through a slow evolution of information systems. MIS maintained control of the mainframe but the PC pioneers of the early 1980s bought their own PCs. They started off in the wild, unsupported and unwanted by the MIS silo, which saw a threat to their command-and-control over computing. Remember that MIS is mostly Stratum (or worklevel) 3 and lower; they are simply responding consistent with their worklevel. But that meant that a separate organizational silo evolved to support the desktop. These groups later pushed the installation of LANs which led to Intel-based servers running Novell network operating system (NOS). Some companies even had separate groups for minicomputers such as DEC’s VAX VMS, making for three internal computing groups in all.

Companies that went through this process created a central governing body over all computing resources, the Information Technology department, which would handled strategic decisions between the various warring platforms and create an information strategy for the company, showing what computing could do to help the company make money rather than simply act as a cost-sink.

But suppose that your company didn’t go through that. Suppose that your company got desktop PC not in 1986 but in 1996, mostly driven by your partners and customers wanting websites. Your computer group is mainframe-based, and a worklevel 3 organization. The work for architecting enterprise-wide OO systems is worklevel 4 or 5. OO itself probably doesn’t start until worklevel 3, because it requires a particular way of thinking about creating programs. You can get programmers at worklevel 2 to support your efforts if their work is heavily prescribed by a 3 developer but they can’t do OOP on their own.

So what do you? If you’re smart, you create a new organization that contains the old operations group. But most people aren’t smart. What most companies seemed to do is give the work to the existing operations group manager and retitle him “Chief Information Officer”, a role that must be above the strategic thinking barrier, worklevel 5 or above. But he’s a level 3 manager. You end up with an organization that looks like Figure 2.

MIS doing OOP
Click to enlarge

The new employees are given to an existing manager to manage. Since the top MIS manager was at worklevel 3, these had to be at worklevel 2 in order to add any value. Unfortunately, these people are incapable of adding any value to the work of level 3 and 4 developers, designers and architects.

Often, in this case, the organization writes spaghetti procedural code in Java. Difficult, but they manage to pull it off. (That procedural programmers can develop that way in Java has been well documented; see “Teaching Old Dogs New Tricks” in a recentCommunications of the ACM or my posts on it over at “Open Source Echos“.)

It seems impossible for the upper management to recognize that the old organization cannot do the new OOP work. They can’t even handle client-server work, which is why these companies have so many problems with systems architecture. In order to create a system that the managers (level 2 or 3 now) can understand, they simplify what should be a complex environment, reducing the number of platforms and connections. This results in servers falling over under load and massive outages or slowdowns. The managers blame it on the technical staff when it is really an organizational structural problem.

Next up: How to organize an IT group requisitely.

GPN-2000-000354 Analog Computing Machine in Fuel Systems Building Lewis Flight Propulsion Lab (NASA)

About the Author

Forrest Christian

Twitter Google+

E. Forrest Christian is a consultant, coach, author, trainer and speaker at The Manasclerk Company who helps managers and experts find insight and solutions to what seem like insolvable problems. Cited for his "unique ability and insight" by his clients, Forrest has worked with people from almost every background, from artists to programmers to executives to global consultants. Forrest lives and works plain view of North Carolina's Mount Baker.  [contact]

Comments 1

  1. This strikes me as similar to the anecdote that I often speak of when consulting regarding talent evaluation and matching people to roles. When a company that goes through explosive growth, frequently, the person who purchased the office supplies for the last 10 years ends up with the organization “exploding below him” and he suddenly becomes the “Director of Purchasing” of a billion dollar company due to SENORITY rather than capability. It’s hilarious to consider that the reason he is now in this position is that his brother’s cousin’s wife, owned an office supply company in town in 1987 when they needed some office supplies. This same scenario plays out when the person who used to cut the payroll checks or organize the company picnic becomes “Director of Human Resources”. Right place, right time on the employees’ part, but a huge oversight on the part of management. (In reality, it does not serve the employee either.)

Tell Forrest how wrong he is: