Design shift of view

Rob Dixon wrote:

> <<really big snip>>
>
> Certainly, lets start a new thread.  Would you like to kick it off?
>
> Let us hope that many people will join in. If people think my pessimism is
> way over the top, let them stand up and be counted!
>
> Rob Dixon,
> Erros plc.
>

Ok Rob, here goes!

Just as you mentioned, our original concept was to get away from the "classic"
design of applications, not just the design/development methods.

IMHO the creation of 4 GL aided in reducing the time/cost of developing
applications, but these applications were still designed under the same
viewpoint.  I.E.: order entry still has a header/detail and optional footer and
application development was centered around the file structure not the business
structure.

I fully understand that is is a result of the attempt to emulate the existing
paperwork in a manual environment.  One looks at an order form and sees order
specific information at the top of the page and a variable number of item 
entries
and an order total.  Screens should still look like this, why not.  But as you
mentioned, the rules should be attached to the variables, not mainlined or
subroutines in a data entry program specific to order entry.  The same goes for
the definition of a piece of paper.

We came up with these elements:
1) Define a variable and it's general rule.
2) Define a document used by a business.  This includes documents received and
documents generated. This also means linking which variables are required and
specifying additional variable rules based upon context of usage.
3) Define the document flow.  Who is responsible for it's origination, steps
along the way, then completion.
4) Define an "agent" that handles a document at a particular step along the
process.  This also means that the variable/document rule defines which agent is
responsible for data entry.
5) Create a "manager" to enforce rules and document movement.

(This is just off the top of my head) The design shift was to get away from
designing applications around the computer and start designing the application
around how the business operates.  We happen to be lucky enough that the
technology is becoming available to implement this design shift.

For me, this possibility was strengthened with JAVA.  Not to get off on a
tangent, but..... I've wondered what the big hoopla is about having machine/OS
specific JAVA extensions.  This can be handled by an installation wizard that
places the appropriate modules into the run-time library.  Sort of like having
multiple /COPY members based upon environment.  Even if the application has to 
be
built like putting together a Linux box.  Who cares!  I guess it's just human
nature to be lazy. <g>

Now let me correlate the 5 items above to what we do now:
1) Create a data dictionary.
2) Define a physical file/display file/ICF file/xxxxx file.  Even a mapped LDA 
is
a document.  So is a logical view.
3) We don't define document flow in the application.  It's in the user
documentation. Enter and order. Print a pick slip. Print a pack slip/manafest.
Price the items. Credit check the order. Print an invoice. Post to AR/GL/SA.  
The
parts are there. Rules exist. But the rules include/exclude orders but they 
don't
-drive- an order.
4) These are the individual, non connected, commands used by the humans to
exercise flow.
5) This is a combination of the validation programs and human office manager.

Let me give a little example of the types of "agents" I'm talking about:
1) Data entry agent.  This is the application to human interface.  It determines
who the human is, knows which forms they are authorized to work with (just like
in a real office), asks them what they have in front of them or what they would
like to create.  Knows what information this particular human has available to
contribute to the document and what their "need to know" limitations are.
2) Validation agent.  The data entry agent passes a variable or complete form to
a validation agent that does as their title implies.  For validating variables,
provides feedback and recommendations to the sender.  For complete forms, either
rejects/returns or passes on to the:
3) Routing agent.  Knowing the document and particular stage of completion,
places into the next recipients "inbox" and notifies either the:
4) Initiation agent to start a process or notifies the human(s) involved that
another document has appeared on their "to-do" list.
5) Process agent.  This is the document to paper driver and the document
posting/archive process. Upon completion of a particular process, hand the
document back to the routing agent until all steps are completed.

The current creation of applications as defined by (my systems guru) Jay W.
Forrester (professor MIT, "Principles of Systems") would be an "open" system.
"An open system is one characterized by outputs that respond to inputs but where
the outputs are isolated from and have not influence on the inputs."

I personally subscribe to his stated alternative: "A feedback system, which is
sometimes called a "closed" system, is influenced by its own past behavior.  A
feedback system has a closed loop structure that brings results from past action
of the system back to control future action. One class of feedback
system--negative feedback--seeks a goal and responds as a consequence of failing
to achieve the goal.  A second class of feedback system--positive
feedback--generates growth processes wherein action builds a result that
generates still greater action."

Here's a little example of what he is taking about: (I'll explain later)

"Whether a system should be classified as an open system or a feedback systems 
is
not intrinsic to the particular assembly of parts but depends on the observer's
viewpoint in defining the purpose of the system.

The way in which the purpose of the system determines whether is is an open or a
feedback system can be illustrated by considering a gasoline engine is terms of 
a
series of viewpoints.
    1. The engine, operating without a governor, has no goal for speed.  It is 
an
open system in terms of speed regulation. <<snip>>
    2. Adding a governor produces a feedback system in terms of constant speed
goal. <<snip>>
    3. But suppose the engine is a part of a lawn mower and we change the goal
from constant speed operation to a goal of mowing the lawn.  Now, from the
broader purpose of cutting grass, the lawn mower is an open system because it 
has
no awareness of what grass has been cut or where to cut next.
    4. By adding the person operating the lawn mower, we again see a feedback
system in terms of the goal of cutting a particular lawn. <<snip>>
    5. But if the viewpoint is broadened again to that of the owner of a lawn
care enterprise with the goal of meeting his customers demands, the operator and
his lawn mower are properly considered a component of a larger management
system.  As such, the operator and his equipment represent an open system that 
is
undirected in its sequence of separate tasks.
    6. By adding the management function, instructions arising from customer
requirements are introduced as a guide.  In terms of the goal of properly
scheduled work, the operator, equipment, and owner must be taken together to 
form
a feedback system for the purpose of serving customer lawn care needs"

In my opinion, we (IT professionals) are still at level 4.  To advance to step 6
does require a radical change in design philosophy and therefore application
development tools. Yet, our employers/clients are the owners of a xxxxxx
enterprise.  Using information technology in a newer light requires that
designers understand the "broadened" viewpoint of the enterprise as a whole and
move beyond hyperthyroid calculators, glorified typewriters and filing cabinets.

Under the current design methodologies, the burden of development would be
crushing.

Next time out, I'll get into some of the nuts-n-bolts of making it happen.  And
JAVA/HTML play a role in it.

James W. Kilgore
qappdsn@ibm.net

"Grasping the structure of a subject is understanding it in a way that permits
many others things to be related to it meaningfully." - Jerome S. Bruner
(Harvard)

P.S. What do ya think Rob? Gonna get a thread started or wil David tell us to
"take it outside"? ;-)


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---