Dan Palanza
dan@capecod.net


Date: Tue, 03 Aug 1999 07:35:55 -0400


Mr. Rod Welch
The Welch Company
440 Davis Court #1602
San Francisco, CA 94111 2496
rowelch@ibm.net

Subject: NSF - Common Admin

Hi Rod,

[Responding to your letter on August 2, 1999...]

Rod Welch wrote...

Dan needs information about SDS structure in order to correlate and discuss details of how his bookkeeping methods can be extended to Communication Metrics. ref DRT 1 2800

At this time, I do not want to present specific SDS design details, which have taken many years to develop through trial and error.

I understand your not wanting expose trade secrets just yet. But I don't believe you need to. What I am interested in is architectural. My accounting system is built around a universal pattern system. I know that patterns are present in your system. If I can convey this pattern to you we can talk freely without exposing the inner details.


Rod Welch wrote...

Information on 940901 explains major features and provides a schematic. ref SDS 4 2929

I will look at this again.


Rod Welch wrote...

We can talk on the phone to develop further information Dan needs.

What would help, if you have the time, is to begin reading some patterns literature. The problem being attacked here is not going to be solved without the help of patterns. Every ancient culture worked out a pattern system. So pattern study is nothing new. But when a culture shifts a major paradigm, as the computer is forcing on our culture, for leadership to understand patterns is essential.


Rod Welch wrote...

If the NSF grant is awarded, I can go visit with Dan and map out the architecture, explaining how the various elements interact to accomplish design objectives.

I'm sure we can work out a meeting even if the grant is not awarded. My own accounting work will be enhanced by Phase II but I will continue to work on my business goal with or without the grant help.


Rod Welch wrote...

A related question, Morris asked, is how do we avoid getting a lot of extraneous information in a subject search, i.e., the classic problem of looking for a "needle in a haystack?" See reports on how well SDS finds information. ref SDS 0 1732

This challenge is generally addressed in SDS by the POIMS concept of Controlled Visibility, ... reviewed recently on 950704. ref SDS 14

Patterns and accounting again.

Patterns and accounting put a maze of data into types, that are more easily managed. Accounting identifies the data into accounts so that context can be isolated to whatever fractal level a project wants to invest in information management. The pattern of context is recursive. So the accounting data can be composed of multiple contexts.


Rod Welch wrote...

From POIMS:

Personal and Organizational Integrated Management

The dual meaning of POIMS reflects the complexity of management.

I call this The Binary Unit Pattern. I avoid the use of the word "dual" because it does not create a true picture of what is really happening in a binary unit. I found it impossible to computerize this type of philosophy until one understands the meaning of types. "Personal Organization" and "Integrated Management" my bet are typical of types as they occur in an accounting system. For example, debits and credit, or assets and liability. Accounting creates these dreaded catagories for good reason. Pattern study enables us to understand why these catagories of type need to be treated with mutual respect within a formal data management system.


Rod Welch wrote...

A good explanation of the goal to manage context was prepared in developing the Action Item system...

We don't want summary to hide context and we don't want context to overwhelm perspective, i.e., the ability to see the "Big ure" Picture" and to grasp the "bottom line." We want to be able to dig out context (also, "dig out of the system"), referring to finding catagories of work activity summarized by description of organizational goals and objectives, e.g., a cost account, a scheduled task, a commitment in a letter, a policy, so that general understanding enables people to work efficiently, yet be able to instantly step back into the details to verify context when needed, per work on 950626 ref SDS 13 2882 for understanding complexity, ref SDS 13 2772 on using summary, explaining organic structure is on 940824. ref SDS 10 1411.

This talk is precisely high level patterns talk. But with patterns, the oldest of computer Bon Mots seem to apply: "garbage in garbage out." If the structure of one's program is not prepared to differentiate types according to patterns the data becomes a ball of hair.


Rod Welch wrote...

There has been less attention given to accounting in SDS, because the opportunities for application, which yield experience for improving the technology, have needed more help with time and information, than with accounting issues. So, accounting support in SDS is largely untested, except for doing billings to customers.

This is a wonderful example of backwards reasoning. Accounting was devised to manage time--a history of what happened. In the patterns community there is a majority who believe that patterns do not have a formal underlying structure. This is so patently absurd to anyone who has ever built real things in the real world, that it causes one to wonder just how the modern technologist is trained.

Accounting is the formal underlying system upon which time and information receive their structural orders. Time and information have structure, just like a building has structure. If one throws everything together in a heap, then one must get accustomed to hunting for needles in haystacks. In short they have it backwards. The accounting *must* come first.


Rod Welch wrote...

"Context" is a design goal for SDS called "Controlled Visibility," as shown in the record on 970116. ref SDS 12 2909 and above on pattern recognition. ref SDS 0 0960

I can't say enough about the importance of managing context in a computerized world. Double entry bookkeeping was worked out for just that reason. And it has has a 600 year monopoly of experience. If there is a better way to manage and reconstruct context, there is a good chance someone in the world, in 600 years, would have discovered that better way.


Rod Welch wrote...

A principle control for context is time; specifically, chronology, or the sequence of events, which imparts cause and effect, that is the foundation of human intelligence. This is the driving force of SDS, as reviewed on 900303. ref SDS 1 3002

Whoever generated this speculation as to the role of time in the control of context could benefit a great deal from the universal patterns that have grown out of my experience with network bookkeeping.

Take for example the clip from POIMS above:

From POIMS:

Personal and Organizational Integrated Management

If you study people in organization you will find that time for the individual is very different from time for an integrated management. So the above statement: "A principle control of context is time" forces the obvious question, "what type of time, individual or common?"

If that question can't be answered intelligently by the users--in other words there is no shared pattern language with which to differentiate the two times--then the underlying structure of the management is sitting upon swampland.

Without a definition that takes in both cases, people will pick the one that fits their immediate needs but is not necessarily the right thing to do. This is what accountability sets out to discourage. But the people must have the tools with which to be accountable. Given the proper tools, I find, people find great comfort in being accountable. Without the tools people go into denial, simply because no one likes being wrong.

Sincerely,


Dan

Dan Palanza
dan@capecod.net


Copy to:

  1. jcservo
    jcservo@dawnbreaker.com

  2. Nerlove, Sara B"
    snerlove@nsf.gov