Universe: Czerepak Framework R0.2

I have been thinking about the terms “convergent” and “divergent” in Tim Brown of IDEO’s Design Thinking and realized that they were products of planar (2 dimensional) thinking.  This has lead me to alter my definitions of what convergent and divergent are and to also redefine “vergent” and add “trivergent”.  I also realized that the convergence point is at the center of the ellipsoid and each verge (radius) point is separate and distinct.

Converge, diverge, verge and triverge all come from the same Latin root “verto”, to turn out.  All of the polyhedron vertexes are representations of the intersections of radii with the surface of not a sphere, but an ellipsoid.  Therefore each vertex is a unique dimension or radius.  However, there is one thing that is still not recognized.

Roll, Pitch and Yaw ellipses alone are an incorrect representation of orientation in space because they fail to include orientation relative to the observer.  Roll, Pitch and Yaw are flat earth concepts.  You cannot represent an ellipsoid with three radii.  The minimum radial representation of an ellipsoid requires four points on the surface of the ellipsoid.  The tetrahedroid is the minimal representation of the inscription of an ellipsoid.

The above three ellipse object and four ellipse object are both ellipsoids, the only difference between them and the three ellipse ellipsoid above them is the perspective–they have been rotated in space.  Using the four dimensional representation gives us the table below:

While I was illustrating the above table it became apparent to me that it accurately reflected  John Boyd’s OODA Loop.  It also became apparent to me that the OODA Loop could be conceputally simplified to:

1. OBSERVE: Range
2. ORIENT: Direction
3. DECIDE:  Elevation
4. ACT: Fire

The OODA Loop or the Czerepak Framework cycle can be graphed as a simple two dimensional sine vertice:

Now, that’s all sure and fine and it provides a way of thinking with a minimum number of variables.  However, if we think about John Boyd as a military combatant it is not the right set of variables.  The model has to cater to the following needs:

1. OBSERVE: Who and Why
2. ORIENT: Where and When
3. DECIDE: What and How
4. ACT: How Many and How Much

Suddenly, it becomes obvious that in a system involving living organisms there is added complexity and layers of consciousness.  The following table is my first attempt to illustrate this:

The yellow row and column headers are what is of importance.  The naming of the white cells will have to come later.  Obviously, there are considerable changes in the order of the columns and rows, but I believe John Boyd is closer to the truth about the process than anyone else.  Therefore I am redefining everyone else’s concept to fit his.  What is important about the table is that in the columns each icon represents a set of ellipses that one ellipse at a time intersects with the ellipses above it to converge on a subset that is the target.

Colonel Boyd’s model was simple.  Deviations from it are based more upon misunderstanding than anything else.  This is the fundamental System Development Lifecycle (SDLC):

1. OBSERVE = SELECT = SCOPE = CONTROL and COMMAND = STRATEGY = TRIVERGENT THINKING = Why and Who are the exceptions?
2. ORIENT = INSERT = ANALYSIS = CLIMATE and TERRAIN = TACTIC = DIVERGENT THINKING = When and Where are the exceptions?
3. DECIDE = UPDATE = DESIGN = FUNCTION and FORM = OPERATION = VERGENT THINKING = How and What are the exceptions?
4. ACT = DELETE = DEVELOP = QUALITY and QUANTITY = GOAL = CONVERGENT THINKING = How Much and How Many are the exceptions?

“What are we deleting?” You may ask.  We are deleting exceptions that existed in the previous system whatever that system may have been.  We are never dealing with a non-existent system.  We are SELECTing a set of exceptions the current system does not handle.  We are INSERTing those exceptions into the current system.  We are UPDATEing the system to handle those exceptions.  We are DELETEing those exceptions from the system.  I still have to work to reconsider the names for each of the cells, but I am converging on that.  The differences between methodologies are really ones of scale and nothing else.  It’s how many exceptions do you intend to address at a time.

This effort is requiring a lot of work and rework because I have never dealt with eight interrogatives before, however the fit is conceptually the best I have ever had.

Universe: Interrogative Spaces

In my previous post I gave thought to Tim Brown of IDEO’s “design thinking”, Clayton Christensen’s “Innovator’s Dilemma”, Malcolm Gladwell’s “Tipping Point”, and Buckminster Fuller’s “Synergetics” concepts.  What emerged was the above Czerepak Framework.  My claim is this framework is fundamental to designing a system.

The thing that the above table shows is interaction within what I am now going to call the “Interrogative Spaces”: HowSpace, WhatSpace, WhySpace, WhoSpace, WhenSpace, WhereSpace, HowMuchSpace, HowManySpace.  Each ellipse I call a “vortice”.  The Interrogative Spaces are composed of one or more vortices.  The Framework above shows how Spaces are composed within the Interrogatives,  but what about interactions between the Interrogative Spaces?   A good example is speed or velocity.  Speed is the intersection of WhenSpace and WhereSpace:

v = r / t

Where v is velocity, r is radius and t is time.

If you are increasing Speed, which is acceleration, you have one dimension of WhereSpace and two dimensions of WhenSpace:

a = r / t’ * t”

Where a is acceleration, r is radius, t’ is the first clock and t” is the second clock.  You cannot measure acceleration with one clock. This uniqueness of every vortice applies to all the Interrogative Spaces and all inter-relationships between all of the Spaces.  .

Another way to look at the Interrogative Spaces is as sets and subsets.  The first row are the complete Space vortice sets.  The second row are the first Space vortice subsets.  The third row is the intersect between the row two and row three Space vortice subsets. And the fourth row are the intersects between the row two and row three and row four Space vortice subsets.

I do not believe that anything is constant.  Not the speed of light, not gravity, not cosmology.  Every intersection of dimensions creates a vortex in Universe and every one is unique.  We are simply unable to measure and manage the uniqueness of everything, therefore we make generalizations which create models that can always be falsified.

Icons: Systema Iconic Language: Part I

In this series of posts I will be exploring the concept of an iconic language built upon the vocabulary I have been incrementally creating as part of the Systema Framework.

Abstract Relationships

Concrete Relationships

I have worked with icons before and this is a revisit of some of those ideas as well as modifications.

Apport Icon Set

The Apport icon set defines the entities that can exist in a system:

Accord Icon Set

The Accord Icon set defines the relationships that can exist in a system:

Below is a cross product of the Apport and Accord Icon sets:

Record Icon Set

I am sure that the icon set below is familiar if you have followed my blog.

Note that the cross product below is only for the entities themselves and not for their relationships.

Properly utilized, an iconic language would allow you to build sentences out of the individual icons interactively.

I plan to continue to think about this subject further and will update as I go along.

Below are links to web pages and pdf documents I have read so far on the topic:

• A Methodology and Interactive Environment for Iconic Language Design
• Iconic Language for Mobile Communication
• New Frontiers in Visual and Iconic Languages (PDF)
• Beware of Style in Icon Design
• Iconic Programming, where to go?
• Graphical Encoding for Information Visualization: Using Icon Color, Shape, and Size To Convey Nominal and Quantitative Data (PDF)

SQL: Old Soldiers Never Die

Structured Query Language (SQL) has been a phenomenally useful language for the relational database era. But I see that era coming to a close.

One of the primary flaws is SQL allows for database Alters, Drops, Updates and Deletes. When diskspace was expensive this made perfect sense, but with the unlimited disk resources we have today a greater principle holds true: NO SCHEMA OR DATA SHOULD BE ALTERED, DROPPED, UPDATED OR DELETED.

A second flaw is the lack of interactive modification of the schema in real time. Changes still blow most applications all to hell.

A third flaw is supertype/subtype hierarchies. Such things should not be hard coded into a design.

That being the case SQL has four unnecessary statements just waiting to be abused. We need a better language. In fact, we need a better database architecture.

A new language would provide no means for updates or deletes. I created the first Releases of this language I called “Structured Thinking Language” (STL).

STL has the following commands:

1. CREATE – affordance concept (creates entities)
2. DIRECT – affordance context (relates entities)
3. POSIT – affordance method (entity output)
4. OBJECT – affordance pragma (entity input)
5. NEGATE – affordance cosmos (entity security)
6. INTUIT – affordance chronos (entity manipulation)

As you can see there are no means to delete data.

Each entity (noun) has only one “attribute” in the relational ERD sense and each entity value is unique.

Each relationship between entities is called an direction with a subject, verb and object.

What we are actually dealing with is a database that has data states. Data being no longer affected by Alters and Deletes are instead affected by change of state without physical alteration or deletion.

After looking at STL recently I realized I had created a command language for an existing database architecture: The Associative Model of Data by Simon Williams.

The Book on the Model and a free copy of the Enterprise Edition software is available here.

An old release of STL can be found here.

Systema: Some Basics

Chris Collins has written a good Introduction to the Zachman Framework that I recommend with a caution: I do not accept that John Zachman fully understands what he is talking about. What this means to me is I will be gradually divorcing myself from using the term Zachman Framework and use the term “Systema” instead. He himself acknowledges that he borrowed his concept from the six interrogatives and construction terminology and from all I’ve read I do not feel that John ever fully explored what he used indepth.

If he had he would have realized there is only one true dimension which are the six unities, which I borrow modified from Aristotle. Every new dimension is simply a repeat of the six unities.

My terminology continues to evolve:

1. Causus: Problem – The Mavin – provides niche – possibility
2. Cognitus: Hypothesis – The Connector – provides associations – compatibility
3. Artus: Method – The Salesman – provides purchase rationale – reliability
4. Datus: Apparatus – The Accountant – provides mass market – economy
5. Eventus: Result – The Secretary – provides delivery schedule – accessibility
6. Locus: Location – The Receptionist – provides product touchpoints – geography

This brings to mind The Innovator’s Dilemma and shows that the tipping point is between reliability and economy.

He would have also pointed out that there are only four fundamental verbs that can be performed on the six factors. I am still refining the icon design.

Icons: System Security

I have been thinking about system security and the types of threats that malware presents to a system. There really are only four types of Malware: Spyders (Malevolent Select), Viruses (Malevolent Insert), Trojans (Malevolent Update) and Bombs (Malevolent Delete).  I’ve been playing with other terms: Causus (Cause), Ductus (Person), Modus (Function), Datus (Data), Eventus (Event), Locus (Node).  I have also included standard security measures:

I hope these icon ideas get you thinking about system security not just in the context of computer systems.

Design: Attacking Convention

It’s wrong. The way we think about managing files in applications is wrong. And it is wrong for one reason. It lacks conceptual abstraction, simplicity and consistency.

“Wait!” you may say, “the icons are the same in all the applications! We’ve got the sheet of paper for ‘New’, the opening folder for ‘Open’ and the diskette for ‘Save’. We’ve even got a cute magnifying glass for ‘Search’.”

Frak the magnifying glass!

That’s part of the problem. The “New”, “Open” and “Save” icons should be sacrificed on the alter and replaced. New is relatively acceptable, but when we open it is not file we open but a folder. When we save we are not saving to a diskette. And we shouldn’t even be using the term “File” for anything. We are managing “Email”, “Documents”, “Worksheets”, “Presentations”, “Databases”, “Calendars”, “Projects”, “Drawings”, “Contacts” and “Browsers” people! If our applications are single function so should be what we are editing.

When you “Open” you could be uploading or downloading into your computer’s memory. When you “Save” a document, you could be uploading it to a hard drive on the web or downloading it to your hard drive; it could be burning it to a CD-ROM or good heavens even writing to a diskette. I’m not going to draw little hard drives. I’m going to abstract the concepts completely.

I always hated the clipboard metaphor. I just decided to call it a “content block”. You either delete it from your document, copy it from your document, update your document with it or select it in your document.

This is not my final version in the least. But I wanted to put some food for thought on the tabula rasa.

Tetrads: McLuhan’s Laws and SQL

I have been going over all the past material in this blog as I am now working on my book. One of the things I am clearing up is my understanding of McLuhan’s Laws of Media known as Tetrads. All that McLuhan discovered and I don’t mean to diminish his work is discover the four manipulations that are possible with any form of media including data.

McLuhan’s four Laws of Media were:

1. Retrieve
2. Enhance
3. Reverse
4. Obsolesce

The four correspoding manipulations are:

1. Select
2. Insert
3. Update
4. Delete

Please dismiss any past correlations I made between the Manipulations and Laws of Media with the Six Interrogatives.

Systema: Manipulating Relationships

In the last post we looked at entity manipulations. Now let’s look at the next row in the Six Hats Six Coats Framework:

Relationships are all about communication and are subject to the same manipulations as a communication link. We also established earlier that there are six relationship types:

So how do we manipulate these relationships?

The first relationship manipulation is the SELECT:

The SELECT manipulation “snoops” or “eavesdrops” on the relationship between two instances. The relationship is untouched.

The second manipulation is the INSERT:

The INSERT manipulation “throws” or “interjects” into the relationship between two instances. Extra data is added to the relationship, but the original is untouched.

Next is the UPDATE manipulation:

The UPDATE manipulation “spoofs” or “imitates” the relationship between two instances. The original data is changed in value.

Finally we have the DELETE manipulation:

The DELETE manipulation “crashes” or “denies service” between two instances. The original data is completely corrupted or the relationship broken.

And there you have relationship manipulation in a nutshell.

Systema: Manipulating Entities

The Six Hats Six Coats Framework’s first row deals with entities.

Let’s remind ourselves more visually:

In an earlier post I laid out the rows and columns for an entity security table. I’ve now abstractly filled in the cells and will share it with you:

Forgive me for coining new terms to make a consistent vocabulary.

How can these security breaches be described? First, the SELECT manipulation recognizes the instance it is dealing with. Second, the INSERT manipulation adds instances. Third, the UPDATE manipulation corrupts the original instance. Fourth, the DELETE manipulation destroys the instance. Realize that an instance can be a physical goal, a physical person, a physical function, a physical datum, a physical event or a physical node.