“If they do not have an appreciation of whence we came, I doubt

they will have an appreciation of where we should be going.”

- Bryce’s Law

INTRODUCTION

I always find it amusing when I tell a young person in this industry that I

worked with punch cards and plastic templates years ago. Its kind of the

same dumbfounded look I get from my kids when I tell them we used to

watch black and white television with three channels, no remote control,

and station signoffs at midnight. It has been my observation that our younger

workers do not have a sense of history; this is particularly apparent in the

systems world. If they do not have an appreciation of whence we came,

I doubt they will have an appreciation of where we should be going. Consequently,

I have assembled the following chronology of events in the hopes this will provide

some insight as to how the systems industry has evolved to its current state.

I’m sure I could turn this into a lengthy dissertation but, instead, I will try

to be brief and to the point. Further, the following will have little concern

for academic developments but rather how systems have been implemented

in practice in the corporate world.

PRE-1950′S – “SYSTEMS AND PROCEDURES”

Perhaps the biggest revelation to our younger readers regarding this period

will be that there was any form of systems prior to the advent of the

computer. In fact, “Systems and Procedures” Departments predated the

computer by several years. Such departments would be concerned with the

design of major business processes using “work measurement” and “work

simplification” techniques as derived from Industrial Engineering. Such

processes were carefully designed using grid diagrams and flowcharts. There

was great precision in the design of forms to record data, filing systems to

manage paperwork, and the use of summary reports to act as control

points in systems. For example, spreadsheets have been extensively used

for many years prior to the introduction of Lotus 1-2-3 or MS Excel. There was

also considerable attention given to human behavior during the business

process (the precursor to “ergonomics”).

Systems were initially implemented by paper and pencil using ledgers, journals

(logs), indexes, and spreadsheets. We have always had some interesting filing

systems, everything from cards and folders, to storage cabinets.

Perhaps the earliest mechanical device was the ancient abacus used for simple

math (which is still used even to this day). The late 1800′s saw the advent of cash

registers and adding machines as popularized by such companies as NCR in

Dayton, Ohio under John Patterson who also introduced sweeping changes in

terms of dress and business conduct. This was adopted by Thomas Watson, Sr.

who worked for many years at NCR and carried forward these practices to IBM

and the rest of the corporate world. Also, Burroughs was a major player in

the early adding machine industry.

The first typewriters were also introduced in the late 1800′s which had a tremendous

effect on correspondence and order processing. This was led primarily by Remington

Arms (later to become Remington Rand).

In the early 1900′s, tabulating equipment was introduced to support such things

as census counting. This was then widely adopted by corporate America. Occasionally

you will run into old-timers who can describe how they could program such machines

using plug boards. Punch card sorters were added as an adjunct to tabulating

equipment.

As a footnote, most of what IBM’s Watson learned about business was from

his early days at NCR. However, he had a falling out with Patterson who fired

him. As a small bit of trivia, after Watson died, he was buried in Dayton on a

hilltop overlooking NCR headquarters, the company he couldn’t conquer.

During World War II, both the U.S. military and industrial complex relied heavily

on manually implemented systems. We did it so well that many people, including

the Japanese, contend it gave the Allies a competitive edge during the war.

The lesson here, therefore, is that manually implemented systems have been with

us long before the computer and are still with us today. To give you a sense of

history in this regard, consider one of our more popular Bryce’s Laws:

“The first on-line, real-time, interactive, data base system was double-entry

bookkeeping which was developed by the merchants of Venice in 1200 A.D.”

One major development in this area was the work of Leslie “Les” Matthies, the

legendary Dean of Systems. Les graduated from the University of California at

Berkeley during the Depression with a degree in Journalism. Being a writer, he

tried his hand at writing Broadway plays. But work was hard to come by during

this period and when World War II broke out, Les was recruited by an aircraft

manufacturer in the midwest to systematize the production of aircraft. Relying

on his experience as a writer, he devised the “Playscript” technique for writing

procedures. Basically, Les wrote a procedure like a script to a play; there was a

section to identify the procedure along with its purpose; a “Setup” section to identify

the forms and files to be used during it; and an “Operations/Instructions” section

which described the “actors” to perform the tasks using verbs and nouns

to properly state each operation. He even went so far as to devise rules for

writing “If” statements.

For details on “Playscript,” see “PRIDE” Special Subject Bulletin

No. 38 – “The Language of Systems” – Aug. 22, 2005

http://www.phmainstreet.com/mba/ss050822.pdf

“Playscript” became a powerful procedure writing language and was used

extensively throughout the world. It is still an excellent way to write procedures

today. Ironically, Les did not know what a profound effect his technique would

have later on in the development of computer programs.

1950′S – INTRODUCTION OF THE COMPUTER

Yes, I am aware that the ENIAC was developed for the military at the end

of World War II. More importantly, the UNIVAC I (UNIVversal Automatic Computer)

was introduced in 1951 by J. Presper Eckert and John Mauchly. The UNIVAC I

was a mammoth machine that was originally developed for the U.S. Bureau of

the Census. Corporate America took notice of the computer and companies

such as DuPont in Wilmington, Delaware began to lineup to experiment with

it for commercial purposes. The Remington Rand Corporation sponsored the

project, but the company’s focus and name eventually changed to “UNIVAC”

(today it is referred to as “UNISYS,” representing a merger of UNIVAC with

Burroughs).

The UNIVAC I offered a sophistication unmatched by other manufacturers,

most notably IBM’s Mach I tabulating equipment. This caused IBM to invent

the 701 and its 700 series. Other manufacturers quickly joined the fray and

computing began to proliferate. Although UNIVAC was the pioneer in this

regard, they quickly lost market share due to the marketing muscle of

IBM. For quite some time the industry was referred to as “IBM & the

BUNCH” (Burroughs, UNIVAC, NCR, CDC, and Honeywell).

Programming the early machines was difficult as it was performed in a

seemingly cryptic Machine Language (the first generation language). This

eventually gave way to the Assembly Language (the second generation

language) which was easier to read and understand. Regardless, many of

the utilities we take for granted today (e.g., sorts and merges) simply were

not available and had to be developed. In other words, programming was a

laborious task during this period.

Recognizing both the limitations and potential of the computer, the 1950′s

represented the age of experimentation for corporate America. Here, the

emphasis was not on implementing major systems through the computer,

but rather to develop an assortment of programs to test the machine as a

viable product. As such, programmers were considered odd characters who

maintained “the black box,” and were not yet considered a part of the

mainstream of systems development. The “Systems and Procedures

Departments” still represented the lion’s share of systems work in corporate

America, with an occasional foray to investigate the use of the computer.

The computer people were segregated into “computer departments”

(later to be known as “EDP” or “Data Processing” departments).

1960′s – MANAGEMENT INFORMATION SYSTEMS

Competition between computer manufacturers heated up during this

decade, resulting in improvements in speed, capacity, and capabilities.

Of importance here was the introduction of the much touted IBM 360

(the number was selected to denote it was a comprehensive solution -

360 degrees). Other computer vendors offered products with comparable

performance, if not more so, but the IBM 360 was widely adopted by

corporate America.

The programming of computers was still a difficult task and, consequentially,

Procedural Languages were introduced (the third generation languages). In

actuality, these languages got their start in the late 1950′s, but the proliferation

of computers in the 1960′s triggered the adoption of procedural languages such

as COBOL, FORTRAN, and PL/1. Interestingly, these languages were patterned

after Les Matthies’ “Playscript” technique which made active use of verbs,

nouns, and “if” statements.

The intent of the Procedural Languages was twofold: to simplify programming

by using more English-like languages, and; to create universal languages

that would cross hardware boundaries. The first goal was achieved, the

second was not. If the languages were truly universal, it would mean that

software would be portable across all hardware configurations. Manufacturers

saw this as a threat; making software truly portable made the selection of

hardware irrelevant and, conceivably, customers could migrate away from

computer vendors. In order to avoid this, small nuances were introduced

to the compilers for the Procedural Languages thereby negating the concept

of portability. This issue would be ignored for many years until the advent

of the Java programming language.

The 1960′s also saw the introduction of the Data Base Management System

(DBMS). Such products were originally designed as file access methods for

Bill of Materials Processing (BOMP) as used in manufacturing. The “DBMS”

designation actually came afterwards. Early pioneers in this area included

Charlie Bachman of G.E. with his Integrated Data Store (IDS) which

primarily operated under Honeywell GCOS configurations; Tom Richley

of Cincom Systems developed TOTAL for Champion Paper, and; IBM’s BOMP

and DBOMP products. In 1969, IBM introduced IMS which became their

flagship DBMS product for several years.

With the exception of IMS, the early DBMS offerings were based on a

network model which performed chain-processing. IMS, on the other

hand, was a hierarchical model involving tree-processing.

Realizing that programming and data access was becoming easier and

computer performance being enhanced, companies now wanted to capitalize

on this technology. As a result, corporate America embarked on the era

of “Management Information Systems” (MIS) which were large systems

aimed at automating business processes across the enterprise. These were

major system development efforts that challenged both management and

technical expertise.

It was the MIS that married “Systems and Procedures” departments with

computing/EDP departments and transformed the combined organization into

the “MIS” department. This was a major milestone in the history of systems. The

systems people had to learn about computer technology and the programmers

had to learn about business systems.

Recognizing that common data elements were used to produce the various

reports produced from an MIS, it started to become obvious that data should

be shared and reused in order to eliminate redundancy, and to promote

system integration and consistent data results. Consequently, Data Management

(DM) organizations were started, the first being the Quaker Oats Company in

Chicago, Illinois in 1965. The original DM organizations were patterned after

Inventory Control Departments where the various components were uniquely

identified, shared and cross-referenced. To assist in this regard, such organizations

made use of the emerging DBMS technology. Unfortunately, many DM

organizations lost sight of their original charter and, instead, became obsessed

with the DBMS. Data as used and maintained outside of the computer was

erroneously considered irrelevant. Even worse, the DBMS was used as

nothing more than an elegant access method by programmers. Consequently,

data redundancy plagued systems almost immediately and the opportunity to

share and reuse data was lost. This is a serious problem that persists in

companies to this day.

1970′s – AWAKENING

Although the MIS movement was noble and ambitious in intent, it floundered

due to the size and complexity of the task at hand. Many MIS projects suffered

from false starts and botched implementations. This resulted in a period where

a series of new methods, tools and techniques were introduced to reign in these

huge development efforts.

The first was the introduction of the “methodology” which provided a road map

or handbook on how to successfully implement systems development

projects. This was pioneered by MBA with its “PRIDE” methodology in

1971. Although the forte of “PRIDE” was how to build systems, it was initially

used for nothing more than documentation and as a means to manage projects.

Following “PRIDE” was John Toellner’s Spectrum I methodology and SDM/70

from Atlantic Software. Several CPA based methodologies followed thereafter.

Also during this time, mainframe based Project Management Systems were

coming into vogue including Nichols N5500, PAC from International Systems,

and PC/70 from Atlantic Software.

The early methodologies and Project Management Systems give evidence of

the orientation of systems departments of that time: a heavy emphasis on Project

Management. Unfortunately, it was a fallacy that Project Management was

the problem; instead people simply didn’t know how to design and build

systems in a uniform manner. As companies eventually learned, Project

Management is useless without a clear road map for how to build something.

In the mid-to-late 1970′s several papers and books were published on how

to productively design software thus marking the beginning of the “Structured

Programming” movement. This was a large body of work that included such

programming luminaries as Barry Boehm, Frederick P. Brooks, Larry Constantine,

Tom DeMarco, Edsger Dijkstra, Chris Gane, Michael A. Jackson, Donald E. Knuth,

Glenford J. Myers , Trish Sarson, Jean Dominique Warnier, Generald M. Weinberg,

Ed Yourdon, as well as many others. Although their techniques were found

useful for developing software, it led to confusion in the field differentiating

between systems and software. To many, they were synonymous. In reality,

they are not. Software is subordinate to systems, but the growing emphasis

on programming was causing a change in perspective.

The only way systems communicate internally or externally to other systems

is through shared data; it is the cohesive bond that holds systems (and software)

together. This resulted in the introduction of Data Dictionary technology. Again,

this was pioneered by MBA with its “PRIDE” methodology (which included a manually

implemented Data Dictionary) and later with its “PRIDE”-LOGIK product in

1974. This was followed by Synergetics’ Data Catalogue, Data Manager from

Management Software Products (MSP), and Lexicon by Arthur Andersen & Company.

The intent of the Data Dictionaries was to uniquely identify and track where

data was used in a company’s systems. They included features for maintaining

documentation, impact analysis (to allow the studying of a proposed change),

and redundancy checks. “PRIDE”-LOGIK had the added nuance of cataloging

all of the systems components, thereby making it an invaluable aid for

design and documentation purposes.

The Data Dictionary was also a valuable tool for controlling DBMS products

and, as such, several adjunct products were introduced, such as UCC-10,

DB/DC Data Dictionary, and the Integrated Data Dictionary (IDD) from

Cullinet. Unlike the other general purpose Data Dictionaries, these products

were limited to the confines of the DBMS and didn’t effectively track data

outside of their scope.

DBMS packages proliferated during this period with many new products

being introduced including ADABAS, Image, Model 204, and IDMS from

Cullinet (which was originally produced at BF Goodrich). All were based

on the network-model for file access which was finally adopted as an

industry standard (CODASYl).

There were a few other notable innovations introduced, including IBM’s

Business Systems Planning (BSP) which attempted to devise a plan for

the types of systems a company needed to operate. Several other comparable

offerings were introduced shortly thereafter. Interestingly, many companies

invested heavily in developing such systems plans, yet very few actually

implemented them.

Program Generators were also introduced during this period. This included

report writers that could interpret data and became a natural part of the

repertoire of DBMS products. It also included products that could generate

program source code (COBOL predominantly) from specifications. This

included such products as System-80 (Phoenix Systems), GENASYS (Generation

Sciences), and JASPOL (J-Sys of Japan), to mention but a few.

MBA also introduced a generator of its own in 1979 – a Systems generator

initially named ADF (Automated Design Facility) which could automatically

design whole systems, complete with an integrated data base. Based on

information requirements submitted by a Systems Analyst, ADF interacted

with the “PRIDE”-LOGIK Data Dictionary to design new systems and, where

appropriate modify existing systems. Because of its link to LOGIK, ADF

emphasized the need to share and reuse information resources. Not only

was it useful as a design tool but it was a convenient tool for documenting

existing systems. The only drawback to ADF was that the mindset of the

industry was shifting from systems to software. Consequently, program

generators captured the imagination of the industry as opposed to ADF.

The increase in computer horsepower, coupled with new programming

tools and techniques, caused a shift in perspective in MIS organizations. Now,

such departments became dominated by programmers, not systems people. It

was here that the job titles “Systems Analyst” and “Programmer” were married

to form a new title of “Programmer/Analyst” with the emphasis being on

programming and not on front-end systems design. Many managers falsely

believed that developers were not being productive unless they were

programming. Instead of “Ready, Aim, Fire,” the trend became “Fire, Aim,

Ready.”

Data Management organizations floundered during this period with the

exception of Data Base Administrators (DBA’s) who were considered the

handmaidens of the DBMS.

The proliferation of software during this decade was so great that it

gave rise to the packaged software industry. This went far beyond

computer utilities and programming tools. It included whole systems

for banking, insurance and manufacturing. As a result, companies were

inclined to purchase and install these systems as opposed to reinventing

the wheel. Among their drawbacks though was that they normally required

tailoring to satisfy the customer’s needs which represented modification to the

program source code. Further, the customer’s data requirements had to

be considered to assure there were no conflicts in how the customer

used and assigned data. After the package had been installed, the

customer was faced with the ongoing problem of modifying and enhancing

the system to suit their ever-changing needs.

1980′s – THE TOOL-ORIENTED APPROACH

As big iron grew during the 1960′s and 1970′s, computer manufacturers

identified the need for smaller computers to be used by small to medium-sized

businesses. In the 1970′s, people were skeptical of their usefulness but

by the 1980′s their power and sophistication caused the “mini” computer

to gain in popularity as either a general purpose business machine or dedicated

to a specific system. Among the most popular of the “mini” computers were:

IBM’s System 36/38 series (which led to the AS/400) DEC PDP Series (which gave way to the DEC VAX/VMS) Hewlett-Packard’s HP-3000 series with MPE Data General Eclipse series with AOS PRIME

The competition was fierce in the “mini” market which resulted in

considerable product improvements and better value to the customer.

Instrumental to the success of the mini was the adoption of UNIX as

developed by Bell Labs, a powerful multi-user, multitasking operating system

that eventually was adopted by most, if not all, mini manufacturers.

But the major development in computer hardware was not the mainframe,

nor the mini; it was the “micro” computer which was first popularized by

Apple in the late 1970′s. IBM countered with the its Personal Computer (PC)

in the early 1980′s. At first, the micro was considered nothing more than

a curiosity but it quickly gained in popularity due to its inexpensive cost,

and a variety of “apps” for word processing, spreadsheets, graphics, and

desktop publishing. This caught on like wildfire as micros spread through

corporate desktops like the plague.

By the mid-1980′s the “micro” (most notably the PC) had gained in power

and sophistication. So much so, that a series of graphical based products

were used for software development in support of the Structured Programming

movement of the 1970′s. Such tools were dubbed “CASE” (Computer Aided

Software Engineering) which allowed developers to draw their favorite software

diagramming technique without pencil and paper. Early CASE pioneers

included Index Technology, Knowledgeware, Visible Systems, Texas

Instruments, and Nastec, as well as many others. CASE tools took the industry

by storm with just about every MIS organization purchasing a copy either for

experimental use or for full application development. As popular as the tools

were initially, there is little evidence they produced any major systems but,

instead, helped in the design of a single program.

Recognizing the potential of the various CASE tools, IBM in the late

1980′s devised an integrated development environment that included IBM’s

products as well as third parties, and entitled it “AD/Cycle.” However, IBM

quickly ran into problems with the third party vendors in terms of agreeing

on technical standards that would enable an integrated environment. Consequently,

the product ran aground not long after it was launched. In fact, the

prosperity of the CASE market was short-lived as customers failed to realize

the savings and productivity benefits as touted by the vendors. By the

early 1990′s, the CASE market was in sharp decline.

Instead, companies turned to Programmer Workbenches which included

an all-in-one set of basic tools for programming, such as editing, testing,

and debugging. Microsoft and Micro Focus did particularly well in offering

such products.

Data Base Management Systems also took a noticeable turn in the 1980′s

with the advent of “relational” products involving tables and keys. The

concept of the “relational” model was originally developed by IBM

Fellow and mathematician Edgar (Ted) Codd in a paper from 1970. The concept

of a relational DBMS was superior to the earlier network and hierarchical

models in terms of ease of use. The problem resided in the amount of

computer horsepower needed to make it work, a problem that was

overcome by the 1980′s. As a result. new DBMS products such as Oracle and

Ingres were introduced which quickly overtook their older competitors. There

was an initial effort to convert DBMS mainstays such as TOTAL, ADABAS, and

IDMS into relational products, but it was too little, too late. As for IBM,

they simply re-labeled their flagship product, IMS, as a “transaction processor”

and introduced a totally new offering, DB2, which quickly dominated the

DBMS mainframe market.

Program generators continued to do well during the 1980′s but it was during

this period that 4GL’s (fourth generation languages) were introduced to

expedite programming. The 4GL was a natural extension of the DBMS and

provided a convenient means to develop programs to interpret data in the

data base.

Another development worth noting is the evolution of the Data Dictionary

into “Repositories” (also referred to as “Encyclopedias”) used to store the

descriptions of all of an organization’s information resources. One of the

motivating factors behind this was IBM (for AD/Cycle) who realized they

needed some sort of cohesive bond for the various CASE tools to interface. This

is another area pioneered by MBA who introduced their “PRIDE”-Enterprise

Engineering Methodology (EEM) to study a business and formulate an

Enterprise Information Strategy, and their “PRIDE”-Data Base Engineering

Methodology (DBEM) to develop the corporate data base, both logically

and physically. To implement these new methodologies, their

“PRIDE”-LOGIK Dictionary was expanded to include business models, and

data models. By doing so, MBA renamed “PRIDE”-LOGIK the “PRIDE”-IRM

(Information Resource Manager) which complemented their concept of

Information Resource Management.

In terms of the MIS infrastructure, two noteworthy changes occurred;

first was the introduction of the Chief Information Officer (CIO) as first

described in the popular book, “Information Systems Management In Practice”

(McNurlin, Sprague) in January 1986. Basically, the MIS Director is elevated

to a higher management level where, theoretically, he/she is operating on the

same level as the Chief Operating Officer (COO), and Chief Financial Officer

(CFO) for a company. In reality, this has never truly happened and, in many

cases, the title “CIO” is nothing more than a change in name, not in stature.

The second change is the change in job title of “Programmer” to “Software

Engineer.” Again, we are primarily talking about semantics. True, many

of the programmers of the 1980′s studied Structured Programming, but

very few truly understood the nature of engineering as it applies to

software, most are just glorified coders. Nonetheless, the “Software

Engineer” title is still actively used today. In contrast, the last of the

true “Systems Analysts” slowly disappeared. Here too is evidence of

the change of focus from systems to software.

During the 1980′s we also saw the emergence of MBA’s graduating from

the business schools and working their way into the corporate landscape. Although

they didn’t have an immediate impact on the systems world, they had a dramatic

effect on the corporate psyche. Their work resulted in severe corporate cutbacks,

downsizing, and outsourcing. This changed the corporate mindset to think

short-term as opposed to long-term. Following this, companies shied away from

major systems projects (such as the MIS projects of the 1960′s) and were content

tackling smaller programmer assignments, thus the term “app” was coined to

describe a single program application.

Interestingly, a “quality” movement flourished in the 1980′s based on the

works of W. Edwards Deming and Joseph M. Juran who pioneered quality

control principles in the early part of the 20th century. Unfortunately, their

early work was unappreciated in America and, consequently, they applied

their talents to help rebuild the industrial complex of postwar Japan. It was

only late in their lives did they receive the recognition of their work in the

United States (after Japan became an economic powerhouse). Another

influential factor was the introduction of the ISO 9000 standard for quality

management which was originally devised by the British and later adopted as

an international standard. Little attention would probably have been paid to

ISO 9000 if it weren’t for the fact that European businesses started to demand

compliance in order to conduct business with their companies.

Nevertheless, these factors resulted in a reorientation of American

businesses to think in terms of developing quality products which,

inevitably, affected how systems and software were produced. The real impact

of the quality movement though wouldn’t be felt in the systems world until

the next decade.

To summarize the 1980′s from a systems development perspective, the focus

shifted away from major systems to smaller programming assignments which

were implemented using newly devised CASE tools. This fostered a “tool-oriented

approach” to development whereby companies spent considerably on the

latest programming tools but little on management and upfront systems

work. In other words, they bought into the vendor’s claims of improved

programmer productivity through the use of tools. Unfortunately, it resulted

in patchwork systems that required more time in maintenance as opposed to

modifying or improving systems. “Fire fighting” thereby became the normal

mode of operation in development.

1990′s – REDISCOVERY

As the PC gained in stature, networking became very important to

companies so that workers could collaborate and communicate on a

common level. Local Area Networks (LAN) and Wide Area Networks (WAN)

seemed to spring-up overnight. As the PC’s power and capacity grew, it

became obvious that companies no longer needed the burden of mainframes

and minis. Instead, dedicated machines were developed to control and

share computer files, hence the birth of “client/server computing” where

client computers on a network interacted with file servers. This did not

completely negate the need for mainframes and minis (which were also

used as file servers), but it did have a noticeable impact on sales. Companies

still needed mainframes to process voluminous transactions and extensive

number-crunching, but the trend was to move away from big iron.

Thanks to the small size of the PC, companies no longer required a big

room to maintain the computer. Instead, computers were kept

in closets and under desks. This became so pervasive that companies no

longer knew where their computer rooms were anymore. In a way, the

spread of computers and networks closely resembled the nervous system

of the human body.

One of the key elements that made this all possible was the introduction

of Intel’s 30386 (or “386″) chip which allowed 32-bit processing. To effectively

use this new technology, new operating systems had to be introduced, the

first being IBM’s OS/2 in the late 1980′s. OS/2 provided such things as

virtual memory, multitasking and multithreading, network connectivity,

crash-protection, a new High Performance File System, and a slick object

oriented desktop. Frankly, there was nothing else out there that could

match it. Unfortunately, Microsoft bullied its way past OS/2 with

Windows 95 & NT. By the end of the 1990′s, OS/2 was all but forgotten

by its vendor, IBM. Nevertheless, it was the advent of 32-bit computing

that truly made client/server computing a reality.

Another major milestone during this decade was the adoption of the

Internet by corporate America. The Internet actually began in the late

1960′s under the Department of Defense and was later opened to other

government and academic bodies. But it wasn’t until the 1990′s that

companies started to appreciate the Internet as a communications and

marketing medium.

The first web browser was developed by Tim Berners-Lee in 1990 which

led to the World Wide Web protocol on the Internet. Early web browsers

included Mosaic, Netscape Navigator, and Microsoft’s Internet Explorer,

among others. The beauty of the Internet was that all computers could

now access the Internet regardless of the operating system, making it a

truly universal approach to accessing data. To write a web page, a simple

tag language was devised, Hyper Text Markup Language (HTML), which was

compiled at time of request to display the web page. HTML was nice for

developing simple static web pages (not much interaction, just simply view the

web page). Developers then invented new techniques to make a web page

more dynamic thereby allowing people to input data and interact with files,

which ultimately allowed for the merchandising of products over the Internet.

Wanting to do something more sophisticated through the web browser,

Sun Microsystems developed the Java programming language in 1995. Java

was a universal programming language that could run under any operating

system. Their mantra was “Write once, run anywhere.” This was a radical

departure from programming in the past where it was necessary to recompile

programs to suit the peculiarities of a particular operating system. Basically,

Java made the operating system irrelevant, much to Microsoft’s chagrin. Further,

Java could be used in small pocket devices as well as in the new generation

of computers powering automobiles. This did not sit well with Microsoft who

ultimately fought the propagation of Java.

By the 1990′s the Structured Programming movement had fizzled out. Instead,

“Object Oriented Programming” (OOP) gained in popularity. The concept of OOP

was to develop bundles of code to model real-world entities such as customers,

products, and transactions. OOP had a profound effect on Java as well as the

C++ programming language.

During this time, source code generators faded from view. True, companies were

still using report writers and 4GL’s, but the emphasis turned to “Visual Programming”

which were programming workbenches with screen painting tools to layout

inputs and outputs.

The Relational DBMS movement was still in high gear, but the use of Repositories

and Data Dictionaries dropped off noticeably. Of interest though was the

introduction of “Object Oriented Data Base Management System” (OODBMS)

technology. Like OOP, data was organized in a DBMS according to real-world

entities. Regardless, Relational DBMS dominated the field.

Also during this decade “Data Mining” became popular whereby companies were

provided tools to harvest data from their DBMS. This effort was basically an admission

that companies should learn to live with data redundancy and not be concerned

with developing a managed data base environment.

Because of the radical changes in computer hardware and software, companies became

concerned with their aging “legacy” systems as developed over the last thirty years. To

migrate to this new technology, a movement was created called “Business Process

Re-engineering” (BPR). This was encouraging in the sense that companies were

starting to think again in terms of overall business systems as opposed to just

programs. I’m not sure I agree with the use of the term “Re-engineering” though;

this assumes that something was engineered in the first place (which was hardly the

case in these older systems).

Nonetheless, CASE-like tools were introduced to define business processes. Suddenly,

companies were talking about such things as “work flows,” “ergonomics,” and

“flowcharts,” topics that had not been discussed for twenty years during the frenzy of

the Structured Programming movement. Ultimately, this all led to the rediscovery of

systems analysis; that there was more to systems than just software. But by this time,

all of the older corporate Systems Analysts had either retired or been put out to pasture,

leaving a void in systems knowledge. Consequently, the industry started to relearn

the systems theory, with a lot of missteps along the way.

Companies at this time were still struggling with devising a suitable development

environment. Most were content with just maintaining their current systems

in anticipation of the pending Y2K (Year 2000) problem (where date fields were to

change from 19XX to 20XX which could potentially shutdown companies). However,

a few companies began to consider how to apply more scientific principles to the

production of systems. Since people were already talking about “Software

Engineering,” why not apply engineering/manufacturing principles to the

development of total systems?

Back in the early 1980′s, Japan’s Ministry of International Trade & Industry (MITI)

coordinated a handful of Japanese computer manufacturers in establishing a

special environment for producing system software, such as operating systems

and compilers. This effort came to be known as Japanese “Software Factories”

which captured the imagination of the industry. Although the experiment

ended with mixed results, they discovered organization and discipline

could dramatically improve productivity.

Why the experiment? Primarily because the Japanese recognized there are

fundamentally two approaches to manufacturing anything: “one at a time” or

mass production. Both are consistent approaches that can produce a high

quality product. The difference resides in the fact that mass production offers

increased volume at lower costs. In addition, workers can be easily trained

and put into production. On the other hand, the “one at a time” approach is

slower and usually has higher costs. It requires workers to be intimate with

all aspects of the product.

MBA took it a step further by introducing their concept of an “Information

Factory” in the early 1990′s. The Information Factory was a comprehensive

development environment which implemented MBA’s concept of Information

Resource Management. Basically, they drew an analogy between developing

systems to an engineering/manufacturing facility, complete with assembly lines,

materials management and production control. These concepts were proven

effective in companies throughout Japan, most notably Japan’s BEST project,

which was sponsored by the Ministry of Finance. As background, the ministry

wanted to leapfrog the west in terms of banking systems. To do so, they

assembled a team of over 200 analysts and programmers from four of the top

trust banks in Japan; Yasuda Trust & Banking, Mitsubishi Trust & Banking,

Nippon Trust & Banking, and Chuo Trust & Banking. By implementing MBA’s

concepts they were able to deliver over 70 major integrated systems in less

than three years. Further, because they had control over their information

resources using a materials management philosophy, the Y2K problem

never surfaced.

In terms of infrastructure, development organizations essentially went

unchanged with a CIO at the top of the pyramid and supported by

Software Engineers and DBA’s. But there was one slight difference,

instead of being called an MIS or IS department, the organization was

now referred to as “IT” (Information Technology). Here again, the name hints

at the direction most organizations were taking.

Finally, the 1990′s marked a change in the physical appearance of

the work force. Formal suit and ties gave way to casual Polo shirts and

Docker pants. At first, casual attire was only allowed on certain days

(such as Fridays), but it eventually became the normal mode of dress. Unfortunately,

many people abused the privilege and dressed slovenly for work. This had

a subtle but noticeable effect on work habits, including how we build systems.

2000′s – GADGETS

We are now past the halfway point in this decade and there is nothing of

substance to report in terms of computer hardware, other than our machines

have gotten faster, smaller, with even more capacity. Perhaps the biggest innovation

in this regard is the wide variety of “gadgets” that have been introduced, all of

which interface with the PC, including: Personal Digital Assistants (PDA’s), iPods,

MP3 players, digital cameras, portable CD/DVD players (and burners), cell phones,

PS2 and XBox game players. These devices are aimed at either communications or

entertainment, giving us greater mobility, yet making us a bit dysfunctional

socially. All of this means the computer has become an integral part of

our lives, not just at work but at home as well.

Shortly after taking the reigns of IBM in 2003, CEO Sam Palmisano introduced

“On-Demand Computing” as the company’s thrust for the years ahead and, inevitably,

it will mark his legacy. The concept as described by Palmisano was simple,

treat computing like a public utility whereby a company can draw upon IBM for

computing resources as required. “On-Demand Computing” made a nice

catch-phrase and was quickly picked up by the press, but many people

were at a loss as to what it was all about. Some of the early developments

resulting from IBM’s “e-Business On Demand” research included balancing the load

on file servers, which makes sense. But IBM is carrying the analogy perhaps

too far by stressing that “on demand” is the manner by which companies should

run in the future. Basically, the theory suggests we abandon capacity planning

and rely on outside vendors to save the day. Further, it implies computers

supersede the business systems they are suppose to serve. Instead of

understanding the systems which runs a business, just throw as much computer

resources as you need to solve a problem. This is like putting the cart before

the horse.

The “on-demand” movement has evolved into “Service Oriented Architectures”

(SOA) where vendors are introducing “on-demand” applications that will take

care of such tasks as payroll, marketing, etc. through the Internet. Again, it all

sounds nice, but as far as I can see, this is essentially no different than service

bureaus like ADP who for years provided such processing facilities. Now,

companies are being asked to swap out their internal programs for third party

products. I fail to see how this is different than buying any other packaged

solution, other than an outsider will be taking care of your software.

The need to build software faster has reached a feverish pitch. So much so,

full-bodied development methodologies have been abandoned in favor of

what is called “Agile” or “Extreme Programming” which are basically

quick and dirty methods for writing software using power programming

tools. To their credit, those touting such approaches recognize this is limited

to software (not total systems) and is not a substitute for a comprehensive

methodology. Agile/Extreme Programming is gaining considerable attention

in the press.

Next, we come to “Enterprise Architecture” which is derived from a paper

written by IBM’s John A. Zachman who observed that it was possible to apply

architectural principles to the development of systems. This is closely

related to consultants who extoll the virtues of capturing “business rules”

which is essentially a refinement of the Entity Relationship (ER) Diagramming

techniques popularized a decade earlier using CASE tools.

As in the 1990′s, concepts such as “Enterprise Architecture” and “business rules”

is indicative of the industry trying to reinvent systems theory.

CONCLUSIONS

Like computer hardware, the trend over the last fifty years in systems

development is to think smaller. Developers operate in a mad frenzy to

write programs within a 90 day time frame. Interestingly, they all know that

their corporate systems are large, yet they are content to attack them one

program at a time. Further, there seems to be little concern that their work

be compatible with others and that systems integration is someone else’s

problem. Often you hear the excuse, “We don’t have time to do things

right.” Translation: “We have plenty of time to do things wrong.” Any shortcut

to get through a project is rationalized and any new tool promising improved

productivity is purchased. When companies attempt to tackle large systems

(which is becoming rare) it is usually met with disaster. Consequently, companies

are less confident in their abilities and shy away from large system development

projects.

Corporate management is naive in terms of comprehending the value of

information and have not learned how to use it for competitive advantage

(unlike their foreign competitors). Further, they are oblivious to the problems in

systems development. They believe their systems are being developed with a high

degree of craftsmanship, that they are integrated, and that they are easy to maintain

and update. Executives are shocked when they discover this is not the case.

The problems with systems today are no different than fifty years ago:

End-user information requirements are not satisfied. Systems lack documentation, making maintenance and upgrades difficult. Systems lack integration. Data redundancy plaques corporate data bases. Projects are rarely delivered on time and within budget. Quality suffers. Development personnel are constantly fighting fires. The backlog of improvements never seems to diminish, but rather increases.

Although the computer provides mechanical leverage for implementing

systems, it has also fostered a tool-oriented approach to systems development. Instead

of standing back and looking at our systems from an engineering/manufacturing

perspective, it is seemingly easier and less painful to purchase a tool to solve a

problem. This is like taking a pill when surgery is really required. What is

needed is less tools and more management. If we built bridges the same way

we build systems in this country, this would be a nation run by ferryboats.

The impact of the computer was so great on the systems industry that it

elevated the stature of programmers and forced systems people to near

extinction. Fortunately, the industry has discovered that there is more

to systems than just programming and, as a result, is in the process of

rediscovering basic systems theory. Some of the ideas being put forth are truly

imaginative, others are nothing more than extensions of programming theory,

and others are just plain humbug. In other words, the systems world is still going

through growing pains much like an adolescent who questions things and learns

to experiment.

I have been very fortunate to see a lot of this history first hand. I have

observed changes not just in terms of systems and computers, but also

how the trade press has evolved and the profession in general. It

has been an interesting ride.

Throughout all of this, there have been some very intelligent people who

have impacted the industry, there have also been quite a few charlatans,

but there has only been a handful of true geniuses, one of which was

Robert W. Beamer who passed away just a couple of years ago. Bob

was the father of ASCII code, without which we wouldn’t have the computers

of today, the Internet, the billions of dollars owned by Bill Gates, or

this document.



By: Tim Bryce

About the Author:

Create a video blog…instantly.