The Zen of Systems and Networks


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.


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.


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.


Buckminster Fuller: In, Around and Out


There is no “up” or “down”.  There is only “in”, “around” and “out’.

– R. Buckminster Fuller

What Buckminster says is not so hard to understand if you think about planetary bodies.  You can fall into the gravitational well, orbit the gravitational well or escape the gravitational well.  There are only the three choices.  The same goes for all forces ultimately.

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:

Systema: The Six Relationships

For years I have been thinking that there are only four relationships in data modeling:

  1. Many to Many
  2. One to Many
  3. One to One
  4. Recursive

At least that’s what the books seemed to say. However I have been reconsidering since I began exploring the Zachman Framework on my own. It has become apparent to me through many practical applications that the textbooks are not always right. Below are the six basic data modeling relationships:

As you can see there are three cursive and three recursive relationships. The cursive relationships are between two separate entities. The recursive relationships are between an entity and itself. Restating them, they are:

  1. Cursive Many to Many
  2. Cursive One to Many
  3. Cursive One to One
  4. Recursive Many to Many
  5. Recursive One to Many
  6. Recursive One to One

Many to many relationships are resolved as illustrated below:

How does this fit into the Zachman Framework? Let’s examine the framework as I illustrate it below:

As you can see relationships each serve a purpose. Concepts are associations between intstances of differing entities. Contexts are one to many relationships between instances of differing entities. Logics are one to one relationships between instances of differing entities. Physics are associations between instances of the same entity. Spherics are one to many relationships between instances of the same entity. Episodics are one to one relationships between instances of the same entity.

Another way to consider this diagram is the first three relationships involve attributes, while the second three relationships involve domains.

Rules: The Connecting Tissue


The nodes for the network graphics are Cause states, Observer states, Energy states, Mass states, Space states and Time states.  To make this more relevant to business we can use the terms Goals, People, Functions, Data, Locations and Events.  The edges that connect the nodes in all the networks are Cause rules, Observer rules, Energy rules, Mass rules, Space rules and Time rules.  Nodes give the system its concepts, while edges give the system context.  States provide extegrity (new term) while Rules provide integrity.

Each of the networks is composed of finite steps between the starting and terminal node called paths, the potential ways of following the rules to perform the steps are called the strategies, the actual strategy followed is called the tactics, the edges operations and the  nodes are states .

Whether you are negotiating Goals, People, Functions, Data, Locations or Events, you have to create and observe the rules to maintain the integrity of the networks.  Goals are connected by Rules, People are connected by Rules, Functions are connected by Rules, Data are connected by Rules, Locations are connected by Rules and Events are connected by Rules.  Even Events (Time) is a network, because we are continuously referring to different clocks in different frames of reference.

All rules have the same characteristics:


We’ll explore how we will model this for each of the Six Hats, Six Coats networks in a subsequent post.

Now we have the connecting tissue of our networks.  Knowing this, we can embark on a course to model all six networks separately.  Once that is complete we can work on integrating two, three, four, five and finally all six networks into a single set of conventions.

Related Posts:

Systema: Seven Hats, Seven Links