The Pendulum Swings

I think there are few industries – if any – that change their minds as fast as the IT industry.

I like to use the analogy of a pendulum to discuss this topic. Because at a high level, the decisions go back and forth, swinging right to left. And the one certain fact of a pendulum that you can count on is it will only swing so far to the right, stop, and swing back again to the left.

In this analogy, you can count on the fact that what is old will soon be new again.

Take the example of the mainframe computer.

For awhile – in the early years – it was the only game in town. The only device you could hook up to the first ones were card punch readers to act as your input, and a printers to act as your output.

Then the terminal came along. It had a keyboard that users could type their instructions into, and see the output on a monitor.

At the end of this great pendulum swing – the first swing – all data was centrally stored in one location with no redundancy of data in multiple places.

Then the personal computers started emerging. And the first applications available were word processing programs, spreadsheets, and database managers.

But the data the users of the PCs wanted was stored in the mainframe. A would user call the computer room, and request a report from the mainframe. The computer guys, after a little hassle, would send the PC user a printed report. The printed report was then typed into the PC – into a spreadsheet or database by the PC user.

The result? Redundant data resided in the corporation – all over the place. Every PC that contained a list of customers, products, sales forecasts or results had a different set that was updated only on that PC.

The PC – after a slight civil war between data processing department and every other department in the company – sparked the invention of the 'terminal emulation card' – which required cabling to be run throughout a building, poking out the walls of each office that had a PC, and plugging into the card that had been inserted in the PC.

The result? The mainframe was still a separate and independent data system. The PC user would have to switch their computer from PC mode to Terminal mode. There was still no bridge to get the data from the mainframe to the PC. But as these cards were evolving new features were added to allow the output from a mainframe batch process to be used by a PC. But the work for the PC user was still tedious.

And the data redundancy problem was getting worse – not better.

By the way this same era also introduce the popularity of the computer consultant, a supposedly skilled individual who claimed they could automate the tedious aspects for the PC user – but that is fodder for a later discussion.

This is the end of the first swing back - to a collection of desparate systems each holding unique resources.

Terminal cards evolved to become network cards and the Local Area Network was born. At first the LAN was used to allow multiple persons to share a common device, like a printer. And the mainframe was still a separate sacred entity.

But then network servers started to appear. PC's that had no user – but acted mostly as a central storage site for documents, spreadsheets, and PC databases.

The redundancy issue was reduced, but not eliminated. There were still no direct ties to the mainframe. So the term "data source of record" became popular to describe the elite status of the mainframe data content.

The pendulum was now in midway swing back to the central data repository state.

The company was now littered with two levels of program applications – those that ran on the Mainframe – and those that ran on the local PC's – and eventually across the LAN.

The ground was now set for the most daring venture of all. The ability to allow PC based applications to access the data on mainframe using various client (PC) to server (Host) data transfer methods – among them ODBC. Now the logic could reside on the PC – and the data was retrieved from the mainframe, to the PC – processed by the logic on the PC – and written back to the database on the mainframe.

The result? Much better access to the data by the company – and the distribution of responsibilities to maintain that data. But the problem was that the logic on the PC was often flawed and the integrity of the data on the mainframe was compromised.

This marks the end of the pendulum swing of the data processing department – and the birth of the Information systems department.

As time and technologies progressed – and the logic of programs running on PC's consistently tweaked – now by the IS department – the data integrity issues started to wane.

But then we saw the birth of the Internet. And the internet allowed people to share data in completely different ways. In fact more than data was being shared. Communications became an integral part of the company's Information Systems as email exploded.

But the most influential aspect of this paradigm shift was that it was now better understood how to have the logic of a program reside on the host server and downloaded to the PC every time it was to be run. And one central source for code.

And the pendulum had swung all the way back to a single central repository of logic and data.

But such a function was a bit to much processing to take place on the single host – it could not be expected to respond quickly to requests for data and for logic. So the two responsibilities were split across two different hosts.

But with the adoption of TCP/IP taking over corporate LANs, security became an issue. Anybody on the outside could get in, view and steal sensitive information, and even maliciously harm the system. So a new level of host was invented. The security server would sit independently of all other resources and act as a sentry to keep out all but the authorized network requests.

So the pendulum now is in mid-swing back to disparate systems – and again facing data rundundancy problems – albeit much smaller than the first swing back.

By this time, the IS department had grown significantly to support all these various services – from server administration, software development, PC application support and development, and training. In most circumstances, the IS department now employed more staff than any other departments.

Think about this.

Let's say your company makes widgets. You sell widgets. You fix widgets. You ship and receive. You do accounting. You do research and development to make better widgets.

Each of your departments at Widgets Inc. has totally different needs – and a few common needs. So each of those departments have totally different – yet urgent needs for their set of information system components. The IS department has now grown to support all those needs. And as technology changes so fast, much more time is spent training IT staff on new technologies than any other part of your business.

Because information systems give the widget company the potential to make better widgets and reach newer markets. Quite frankly – and perhaps generally – you can judge the success of the IS department by the success of the company.

So the key to optimal business success is to make your IS resources as efficient as possible.

So what does this pendulum swing allow us to forcast?

1. You can only allow your IS staff to grow so large.
   
2. This means the amount of effort to maintain so many disparate – yet tightly integrated systems must be eased.
   
3. This means that simpler systems for security, server administration, database management, and source code logic must become more prevelant and usable.
   
4. This means that IS staff can now manage more technologies easier.
   
5. This means a shift back to the central repository of services is inevitable.
   

It will be interesting to see as we move forward how things will progress. It will be interesting to see how corporations like Microsoft – so dependent on the disparate systems model – will fare as other company's like Google move us closer to the central repository model.

By the way, is there a school left in the world that still teaches COBOL?