automation n. (ca.1948)
1: the technique of making an apparatus, a process,or a system operate automatically 2: the state of being operated automatically

Merriam Webster Collegiate Dictionary- tenth edition

Background

Following WWII a curious prospect caught the public imagination. A certain "Stored Program Machine" appeared embodying fundamental concepts identical to those which are used in digital computers to this day. Expectations for it were high! To deal with the machine's promise, in 1948, exciting words like cybernetics and automation made their way into our language.

The later enormous success of computer systems and the euphoria that accompanied it obscured many problems. In particular the Systems Development Approach, used to develop and maintain an organization's software systems, proved to be both costly and frustrating.

Over the intervening decades software development never caught up with hardware development. The hopes and expectations for software development have seldom if ever been met. Yet Systems Development continues to be the traditional and the only approach to automation. One still "develops systems" in 2016. The costly and frustrating old problems still exist and the underlying cause of those problems is still not understood.

But it always was known that, "a computer does exactly what one tells or instructs it to do". So, one might ask, is there possibly a different way to instruct the machine...at the very foundation.....resulting in a simpler approach to computer automation? The answer, it turns out, is yes. There is a way quite different from the Traditional Systems Development Approach.

1. Consider the Traditional Systems Development Approach

   Consider that, in 1948 and since then, automation was understood to be [following the definition above]:

   1. "the technique of making things automatic"-- for 60 years that has always meant the Traditional Systems Development Approach, i.e., feasibility, requirements, analysis, design, coding, testing, training, and enforcing use of the newly installed system. This approach has proved unwieldy. It now is clear that the software never did "catch up" with the hardware. And the still growing rift between IT and the Business side user is stark evidence of the failure of that Traditional Approach.

   2. "the state of being operated automatically" — for 60 years that has always meant being driven and constrained in a pre-designed fashion by a Traditional Computer System. Any encounter with a computerized telephone answering system demonstrates the "driven and constrained" nature of the human/computer systems relationship. It is the human who must adapt because the computer system certainly will not! Despite such experiences, everyone wanted to believe the marketing hype. We all believed that computerization would provide the flexibility necessary to survive in an ever more rapidly changing world. How ironic it is to find that computerization has had exactly the opposite effect. Computer systems have proven to be rigid, inflexible, and have had a stultifying effect on an organization's ability to adjust.

These problems are readily apparent and the question remains, "might we now employ the computer differently…finding a better approach to automation which eliminates these difficulties"?

• Consider the Traditional Approach vs. a New One

  Consider now the very general situation of offloading work and responsibilities to any computer [one commonly calls this "systematizing" or "applying the computer"]:

  1. Under the Traditional Systems Development Approach- one must determine requirements, must analyze, design, develop, implement, and install or change a technical software system. This is accomplished by technical support persons [IT, then outside software consultants and vendors, enterprise systems and cloud computing specialists, etc., etc.]. Today, the resultant computer systems run on machines someplace on earth [but where], likely are supported by technicians from someplace else on earth [but where]? All aspects of the offloaded responsibilities remain remote from the very person or persons whose work and responsibilities were off loaded.

  2. Under a New Supervisor/Subordinate Approach- you may instruct the machine as one instructs an aide or subordinate. This is accomplished by the user, the party directly responsible for the work, the very shop person, supervisor, manager or executive whose work and responsibilities are to be offloaded. All aspects of offloading the work and responsibilities remain in the domain of that responsible party. Precisely as if the machine were a human subordinate the responsible party may alter instructions for, or can reassume the performance of, the offloaded work and responsibilities whenever conditions change to warrant such action. ¹

So there is A New Approach [a new foundation]

The new approach relates to the traditional one as a new paradigm relates to an earlier one. According to Thos. Kuhn [see The Structure of Scientific Revolutions, 1962] in order to be attractive the new Supervisor/Subordinate paradigm should handle or include the older Systems paradigm as a special case. In fact it does handle Traditional Systems Development, and so can incorporate older, existing computer systems.The new approach relates to the traditional one as a new paradigm relates to an earlier one. According to Thos. Kuhn [see The Structure of Scientific Revolutions, 1962] in order to be attractive the new Supervisor/Subordinate paradigm should handle or include the older Systems paradigm as a special case. In fact it does handle Traditional Systems Development, and so can incorporate older, existing computer systems.

Additionally, the new approach or paradigm is not an extension of technology. It arises from a change in perspective — essentially a different way of viewing the automation problem. Because it could have been used from the very beginning of the programmable machine era in the late 1940s, it represents a classic case of "the path not taken".

This different, non-systems approach to automation will allow for asynchronous and harmonious automation efforts under the direction of the responsible parties themselves. The efforts are actually a delegation of work by the very individuals responsible for the work being automated. Those same individuals are able to make incremental, continuing adjustments or changes to the automated state...... changing it to follow their real world needs through the normal course of time.

And this is exactly what responsible managers want.

Additional Consideration - The Affect on IT

Under the Supervisor/Subordinate Approach the IT person cooperates, may help a manager write instructional scripts so the machine does what the manager wants done in the way he wants it done. No longer will IT need to completely redesign perfectly good real world functions and methods, during systems development, in order to put them on a computer. Instead IT will help to automate processes "in-place" exactly as a manager sees them. Thus IT people will be viewed as helpers/consultants; they will understand the manager's job as the manager sees it; become part of the organization and become promotable.

1. No systems design! You tell a human what to do; via short instructional scripts you tell the computer the same thing! A human needs certain orientation and background information in order to perform an action or a function; the computer needs exactly the same information. Human and machine will now follow the same script; which you know and can change when conditions warrant a change.