Design: Business Design

HexSheet

In an earlier post I was reflecting on the concept of a curriculum shared by Tim Brown of IDEO on his Design Thinking Blog.  At that time I shared a list of areas I felt would compose a curriculum.  I have continued to reflect on this and I have come up with the following table:

table-market-segments

The rows in the above table are the market segments the columns are the market segment actions.

The Brain: ZenUniverse: Seven Senses

zensevenuniversebrain1

  1. GREEN: EYE: OCCIPITAL LOBE: visual center of the brain
  2. YELLOW: EAR: TEMPORAL LOBE: sensory center of hearing in the brain.
  3. SKY: NOSE: BRAINSTEM: control of reflexes and such essential internal mechanisms as respiration and heartbeat.
  4. BLUE: TONGUE: PARIETAL LOBE: Complex sensory information from the body is processed in the parietal lobe, which also controls the ability to understand language.
  5. RED:  JAW: FRONTAL LOBE: control of skilled motor activity, including speech, mood and the ability to think.
  6. ORANGE: BODY:  CEREBELLUM: regulation and coordination of complex voluntary muscular movement as well as the maintenance of posture and balance.
  7. GREY: SELF: CORPUS CALLOSUM: The arched bridge of nervous tissue that connects the two cerebral hemispheres, allowing communication between the right and left sides of the brain.

zensevenuniversecolumn2

If you look at my first ZenUniverse post, you will see a six column model.  However, the System International Units require seven columns.

Here is a table of two hemisphere intersections.  I am using Latin roots, but you will recognize many of the terms:

zensevenuniversetable2

Here is a blank table you can print out and experiment with correlations and intersections of your own:

zensevenuniversecolumnblank

zensevenuniverseblank1

zensevenuniversebrain1

Link:

The Zen of Systems and Networks

zencircle01

My own work with Enterprise Frameworks and Networks has led me to come up with the following table.  It describes the Nodes and Links in a Complete System Network.  I am saying that the Nodes representing Goals, People, Time, Locations, Code, Data, Qualities and Quantities can all be represented as Scale-free Networks and that each of these Node Networks require only one datatype.  I am also saying that there are only three types of links in networks: recursive links within a set, multiple links between sets, single links between sets.  I know of no case where this has been attempted in the manner I am attempting to represent it.

systemnetworkslinks1

If you have been following my blog you are aware that I have been struggling for a long time to come up with a framework and a clean terminological set to describe systems.  I think I have come one step closer to that goal today.  The table above describes a Fact composed of eight Nodes (first white row illustrating entities) and the Links (last three white rows illustrating recursive, multiple and singular relationships) for each of the System Networks (Interrogative columns).  One of the interesting aspects of this System Network Model is every Fact is composed of a Unique Set of all eight Nodes.  However, all the Nodes in one Fact do not have to have Links to all the Nodes in another Fact.  Each Node within a Fact is independent regarding its Links.  Therefore you have a single set of System Facts with each Fact containing a single set of Interrogative Nodes each connected by their respective Link Networks.

I have recently been writing with the intent to challenge centrism on any one of these networks and advocate a more integrated view. I still remember dealing with data centrism, event centrism, user centrism, goal centrism, program centrism and schedule centrism over the course of my career. All of them have a role to play. My insight into all of these Nouns being Linked by Verbs in only three ways required me to look at all of the Enterprise Architectures and disengtangle the Nouns, Links and Verbs from the reasoning and representations that extend back beyond computing itself.

The Data Model below is a hybrid of Relational Models and Dimensional Models.  I call this an Associational Model.  It is using Relational Architecture to represent it.  However, I think that an alternate Entity-Attribute-Value (EAV) architecture called the Associative Model of Data would be better suited to the task.  I am using relational representation as I am still trying to communicate with a community only familiar with Relational technology.

The first thing to note about this model is Links are represented by Associations.  Associations link two Nouns using a Verb.  What is interesting about this model is every Verb, Association, Noun and Fact is unique.  The vertical connections are Many to Many relationships which allow two vertically adjacent Verbs, Associations or Nouns to have multiple unique relationships between each other.  What this means is there are no integrity problems (duplicate values) as the system network would enforce uniqueness.

amdschema031

The premise of this model is that the Nodes are not dimensions at all.  I am rejecting the traditional concept of dimensionality instead I am saying that there are three dimensions of Links: recursive, multiple and singular.  All we perceive are Facts, Nodes and the Links between them.

So you could come away with the following Zen koan:

entity without entity,

source without source,

path without path,

target without target,

size without size,

dimension without dimension.

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.