Design: Business Design Induction/Deduction

hex-business-design-01

This is my latest incarnation of the Business Design Process.  Induction (Brainstorming–generation of ideas) is Counter-Clockwise.  Deduction (Refinement–elimination of ideas) is Clockwise.

Below is the Intelligence Architecture:

hex-business-design-03

Here is the Media Architecture:

hex-business-design-04

This is the Data Architecture for this model.  Note that all values are accepted even if they are wrong:

hex-business-design-05

Below is the Network Architecture of this model.  Note that the values are unique (nodes) and they are sequential (edges):

hex-business-design-06

Here is the Text Architecture:

hex-business-design-08

Here is the Numeric Architecture:

hex-business-design-07

Here is the Octonion Architecture:

hex-business-design-octonion

Advertisements

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.

Universe: Interrogative Spaces

iconuniverse14

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.

Universe: The Czerepak Framework

I just visited the archive of Tim Brown’s Design Thinking Blog and came across the following post:

Definitions of design thinking

Tim Brown » 07 September 2008 » In design thinking »

In my HBR article I gave a ‘definition’ of design thinking. It was:

Design thinking can be described as a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.

On reflection this is a narrow description that focuses on design thinking’s role within business. The next sentence that I wrote.“….design thinking converts need into demand” , which I borrowed from Peter Drucker, broadens things out a bit but still assumes an economic motivation.

I am grappling with two questions as I think about this.

1. Is there a general definition of design thinking?

2. Is it useful to have one?

I think Tim has something very good here and suggest that the following would be a further breakdown of his classification:

  • Viable: Business
    • How Much: Quality
    • How Many: Quanitity
  • Feasible: Technology
    • What: Material
    • How: Process
  • Desirable: Human
    • Why: Goal
    • Who: People

Obviously, if you have been following my blog, you can see the same pattern appearing and reappearing as we explore other’s concepts.  The six interrogatives continue to reassert themselves.  However, I think I finally nailed one more aspect on the head.  I hate to say it, but it came to me in a dream about working on a programming project:

  • Reliable:
    • Where: Location
    • When: Timing

Quantity and Quality are two aspects of design/system thinking that are continually overlooked by academics and specialists, but not business people.

Interestingly enough this perspective is not new.  Clayton M. Christensen in his book The Innovator’s Dilemma discusses a four part model that fits nicely with this:

  1. Availability
  2. Compatibility
  3. Reliability
  4. Cost

I consider, Clayton’s the most empirical ordering.  Consequently, I would like to mesh Tim’s, Clayton’s and my perspective into the following:

  1. Feasibility: Technology
    1. How
    2. What
  2. Compatibility: Personality
    1. Why
    2. Who
  3. Availability: Market
    1. Where
    2. When
  4. Viability:  Business
    1. How Much
    2. How Many

Now, looking at this I am reminded of Malcolm Gladwell’s book, Tipping Point, and it adds the following character to the model:

  1. Feasability: Mavin
    1. How: Processes
    2. What: Materials
  2. Compatibility: Connector
    1. Why: Goals
    2. Who: People
  3. Availability: Salesman
    1. Where: Locations
    2. When: Schedules
  4. Viability: Customer
    1. How Much: Costs
    2. How Many: Units

Universe: A Multi-Dimensional Medium

Let’s do a thought experiment.  I want to take design thinking and abstract it to a system.

doble-vortice

Imagine that there are no solids, liquids, gases or plasmas or particles.  That the Universe is a fluid medium swirling between equilibrium and non-equilibrium in multiple dimensions.  What we perceive to be solid, liquid, gas or plasma are not states, but intersections of dimensions that describe interdimensional vortices.  Energy is the intensity of a vortice.  Mass is a vortice of a set of dimensions.  Light is a vortice of a set of dimensions.  All of the particles are vortices of sets of dimensions.  Each influence the other based upon which dimensions they are composed of.

R. Buckminster Fuller clearly states in his work that we should perceive the systems as finite four dimensional spheres.

There are only four fundamental states:  vortice verge, vortice converge, vortice emerge, vortice diverge.

iconuniversestates1

Everything we perceive are combinations of these vortice states.  The states are +/- vortice yaw, +/- vortice pitch, +/- vortice roll.

If any vortice is spiraling toward you it is positive, if any vortice is spiraling away from you it is negative.  By definition, no vortice can be stationary with respect to you.

There are only eight fundamental vortices: How, What, Why, Who, When, Where, How Much, How Many.

This gives us the following eight vortice, four state table:

iconuniverse13

Take the time to look at the terms defining each of the white cells in the table.  Each row is the addition of a dimensional vortice.  For example: Each additional “when” vortice is another separate clock.  Each additional “where” vortice is another separate radius.  All of them are factors in a system or a design.

And even this representation is inaccurate.  If we consider fractal geometry and chaos theory, there are no points, no straight lines, no arcs, no planes, no circles, no polygons, no polyhedrons, no spheres, only vortices that are above, within or below our range of perception.  Space cannot be filled with any geometric shape.  Everything is composed of vortices–spirals.

We have to abandon the flat world, flat space models we currently cling to.  The world and the universe are not infinite planes.  The world is a finite island of non-equilibrium in a predominantly equilibrium universe.

And that is it, the Czerepak (Chair-eh-pak) Framework.

Copyright (c) 2008 Grant Czerepak.  All rights reserved.

Links:

Systema: Operation, Tactic, Strategy

entityassociation2

iconsrelate

iconsenterpriserelate

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

enterpriserelateabstract

Concrete Relationships

enterpriserelateconcrete1

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:

iconscreate2

Accord Icon Set

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

iconsrelate2

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

enterpriserelateicons2

Record Icon Set

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

iconsrecord1

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

enterpriserecordicons

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: Seven Hats, Seven Links

watch-parts1

Parable of the Watchmakers

There once were two watchmakers, named Hora and Tempus, who made very fine watches. The phones in their workshops rang frequently; new customers were constantly calling them. However, Hora prospered while Tempus became poorer and poorer. In the end, Tempus lost his shop. What was the reason behind this?

The watches consisted of about 1000 parts each. The watches that Tempus made were designed such that, when he had to put down a partly assembled watch (for instance, to answer the phone), it immediately fell into pieces and had to be reassembled from the basic elements.

Hora had designed his watches so that he could put together subassemblies of about ten components each. Ten of these subassemblies could be put together to make a larger sub- assembly. Finally, ten of the larger subassemblies constituted the whole watch. Each subassembly could be put down without falling apart.

sevenhats2.jpg

For the longest time I have been playing with interrogatives and associations.  Now, I think I finally have a complete representation and taxonomy.

Abstractly, it looks like the following:

enterpriseabstract3

Concretely, it appears as follows:

enterpriseseven5

As I mentioned in my earlier post, I was not satisfied with a six interrogative, four association model.  Consequently, I worked to resolve this and came up with the table above with the interrogative columns (seven hats) and the associative rows (seven coats).  I also came up with the data model below:

enterprisefact1

My hypothesis is, used correctly, the above data model can address all relational/dimensional requirements.

Related Posts: