Systema: Implicit and Explicit Structured Thinking

In an earlier post, Six Hats, Six Coats: The Structured Thinking System, I described what can be called Implicit Structured Thinking. This is the formal underlying structure of all systems described by Six Hats, Six Coats. However, there is also an informal structure that evolves that is less crystalline and more entropic that I call Explicit Structured Thinking. This structure allows for additional entities, relationships between any two entities, additional attributes and more diverse constraints and freedoms. Ultimately, as many as needed until every entity becomes unique.

The normal state of a system is neither wholly implicit or wholly explicit. Unable to find a suitable term I call this normal state “interplicit”. The interplicit state of a system I refer to as “organic” in comparison to a crystalline (implicit) or entropic (explicit) state. The tendency of a system’s interplicity towards implicity or explicity depends upon the other systems with which it interacts.

I’ll discuss this further in subsequent posts.

Advertisements

STL: Structured Thinking Language R0.3

I had a bit of an epiphany today. What I realized is that by structuring Structured Thinking Language as I have, everything can evolve as lists. Each VERB is simply the addition of another list to the NOUN you are working with.

Six Verbs: CREATE, RELATE, REPORT, RECORD, AFFORD, ENGAGE

Six Nouns: MOTIVE, LOCALE, OBJECT, METHOD, PERSON, MOMENT

Four Adjectives: INDUCED, DEDUCED and IMPLICIT, EXPLICIT

CREATE INDUCED|DEDUCED IMPLICIT|EXPLICIT
     NOUN
        (   nounname_1,
            ...,
            nounname_n
        );       

RELATE INDUCED|DEDUCED IMPLICIT|EXPLICIT
     NOUN.nounname TO
                (    NOUN_1.nounname_1,
                     ...,
                     NOUN_n.nounname_n
                );         

REPORT INDUCED|DEDUCED IMPLICIT|EXPLICIT
    NOUN.nounname
                (    attributename_1,
                     ...,
                     attributename_n
                );       

RECORD INDUCED|DEDUCED IMPLICIT|EXPLICIT
    NOUN.nounname.attributename
                (    constraintname_1,
                     ...,
                     constraintname_n
                );         

AFFORD INDUCED|DEDUCED IMPLICIT|EXPLICIT
    NOUN.nounname
                (    SELECT
                     INSERT,
                     UPDATE,
                     DELETE
                )
                ON
                (   NOUN_1.nounname_1,
                    ...,
                    NOUN_n.nounname_n
                );         

ENGAGE INDUCED|DEDUCED IMPLICIT|EXPLICIT
SELECT|INSERT|UPDATE|DELETE

Obviously, it still needs work, but we can see where the Structured Thinking Language adds value to the design process. SQL does have it’s place in data manipulation. However, STL has a place in data definition. See the related posts for background information on this syntax.

Related Posts:

Structured Thinking Language R0.3

Six Hats, Six Coats and Knowledge Management

I was passed this link to a free Knowledge Management Course by a friend today.

I gave the entire course a read (it is not that long) and concluded that there was only one thing that the course covered that is not covered by the Six Hats, Six Coats as it has been explained so far. The issue is valuation, how do we know the cost/benefit of any fact. Otherwise, the authors wave the term “knowledge” around with little restraint to the point of its being meaningless. If they had it their way, everything would be knowledge. (I’ve been known to rant that everything is objects.)

zachmanframeworkabstract03.jpg

To perform valuation of the Six Hats, Six Coats Framework, facts are each of the Six Coats columns: Motive, Locale, Object, Method, Person and Moment. Each of these can be reduced to their atomic granularity at the Blue Hat perspective row. One additional row can be added to the bottom, which is the benefit per manipulation. Each of the Six Hats is a row and can be accumulated in a seventh column, which is the cost per perspective. Each cell of the Six Hats, Six Coats Framework has a cost when it is created, but the benefit accumulates with each manipulation of its column at the Blue Hat level and is rolled up to the appropriate cell.

The rest of the Knowledge Management concepts are covered by the Six Hats, Six Coats Framework.

The Six Hats, Six Coats Framework provides not only knowledge. The Six Hats provide:

  1. Green Hat: Wisdom. Conceptualization. Creativity.
  2. Yellow Hat: Knowledge. Contextualization. Relativity.
  3. White Hat: Information. Logicalization. Optimicity.
  4. Black Hat: Data. Physicalization. Pessimicity.
  5. Red Hat: Regulation. Humanization. Anthropicity.
  6. Blue Hat: Conduction. Detectors and Effectors. Synchronicity.

The Six Hats, Six Coats Framework gives a clear definition of knowledge. Meta-Knowledge is the modeled relationships between the each of the entities within a system. This is the entity relationship diagrams for the facts. Knowledge is the actual references between each of the instances within a system. This is the actual database containing the facts. A rule relationship model, a node relationship model, a data relationship model, a function relationship model, a person relationship model and an event relationship model are meta-knowledge. Rule instance references, node instance references, data instance references, function instance references, person instance references and event instance references are knowledge.

“Mentifacts” and “Sociofacts” are obtuse terms. Person associations are extragroup, intergroup, intragroup, extrapersonal, interpersonal and intrapersonal. They are different perspectives a human takes to interaction and the adoption of facts from another system. Motive, locale, object, method, person and moment are all artifacts, better termed entities.

The definitions the course offers: “Know-what”, “Know-why”, “Know-how”, “Know-who” is incomplete and ill defined.

  1. Yellow Hat, Green Coat is Know-why. Contextual Motive.
  2. Yellow Hat, Yellow Coat is Know-where. Contextual Locale.
  3. Yellow Hat, White Coat is Know-what. Contextual Object.
  4. Yellow Hat, Black Coat is Know-how. Contextual Method.
  5. Yellow Hat, Red Coat is Know-who. Contextual Person.
  6. Yellow Hat, Blue Coat is Know-when. Contextual Moment.

Knowledge management is not simply Informal and Formal. Knowledge Management can be Implicit, Explicit, Tacit and Sonit. Implicit knowledge management handles knowledge that is documented and unchanging in the organization. Explicit knowledge management handles knowledge that is documented and changing. Tacit knowledge management handles knowledge that is undocumented and unchanging. Sonit knowledge management handles knowledge that is undocumented and changing.

The Six Hats, Six Coats Framework does not use the metaphor of a factory for knowledge processing. Instead the framework uses a system lifecycle of induction and deduction. The system repeats, refines, records, reports, relates and revises input; and revises, relates, reports, records, refines and repeats output. Only during the relate phase is input or output knowledge.

The concept of knowledge claims, I found intriguing, but confused between what is meta-knowledge and what is knowledge. I could only conclude that a knowledge claim is really a meta-knowledge claim. Validation of references, knowledge, is protected by referential integrity. A meta-knowledge claim would be validated by a corroboration of exceptions.

The quality of meta-knowledge is a question of how well the relationships for the dimensions handle input and output. If the probability of no exceptions is high the quality of the meta-knowledge is high. A change in context is a change in interacting systems and will affect the quality of an entire system’s performance not just one of its dimensions or of only its knowledge.

Validation of a system is not only knowledge validation. Validation of Conduction, Regulation, Data, Information, Knowledge and Wisdom are all necessary excercises. Because no system is completely Implicit, Explicit, Tacit or Sonit there will always be room for normal and exceptional input and output that has not been accounted for.

Knowledge has intrapolative predictive capabilities. Wisdom has extrapolative predictive capabilities. From this course Knowledge Management appears to know little about systems at all.

The course also attempts to use the three layer ANSI model of World, Knowledge, Meta-Knowledge to describe itself. I have no problem with that. However, because of the poor definition of knowledge in the first place the author begins fantasizing about endless additional layers. I have only found there needs to be three layers in every case I’ve tested. There is the world, the referential and the relational layers.

The sixth lesson of the course talks about innovation as the goal of Knowledge Management. I beg to differ. Innovation is a completely different perspective in the Six Hats, Six Coats Framework. Innovation is the Green Hat, conceptualization perspective. Knowledge assists conceptualization, however conceptualization is concerned with the entities of each of the fact dimensions, not the relationships. Relationships are interpolative, they can only exist between entities that exist. Entities are extrapolative, they can come into existence out of nothing and do not depend upon relationships to exist.

As far as the seventh section, Metrics, goes there is ultimately a cost/benefit ratio. All other metrics are irrelevant if the cost/benefit is done correctly. Cost is the expenditure required to build each cell, each model, of the system framework down to the atomic level. Benefit is the profit gained from each manipulation of the system at the atomic level.

“Knowledge Transfer” is the ability of your system to induct another system and then deduct with a profitable outcome.

You don’t need a Knowledge Management Team. You need a System Modeling Team and the Six Hats, Six Coats Framework. “Everything is a system” holds up to scrutiny better than any knowledge management claim.

Implicity and Explicity

Nothing can be so amusingly arrogant
as a young man who has just discovered an old idea
and thinks it is his own.
Sidney J. Harris

By now I think I have established the legitimacy of the Six Hats, Six Coats Framework and I am presenting it here in what I am going to consider its final form:

zachmanframeworkabstract03.jpg

Every notational technique is a combination of two or more of the Six Coats. What we are working toward ultimately is a language to interrelate all Six Hats and Six Coats at once.

In this post I want to think about the terms “implicit” and “explicit” and how they relate to the Six Hats, Six Coats Framework. For the purpose of this framework implicit is defined as unchanging and invisible; explicit is defined as changing and visible.

Every entity, relationship, attribute, constraint, definition and manipulation has an implicit and explicit name. As well, every motive, locale, object, method, person and event has an implicit and explicit name. An implicit name is unique and once assigned cannot be changed. An explicit name is unique, but it can be changed. The implicit name is not visible to the user. The explicit name is visible to the user.

An entity which contains its own primary key is an implicit entity. An entity which contains a key from another entity in its primary key is an explicit entity.

A relationship that connects one entity’s primary key as part of the attributes of another entity is an implicit relationship. A relationship that connects one entity’s primary key as part of another entity’s primary key is an explicit relationship.

If the primary key is never made visible to the user and cannot be changed it is an implicit primary key. If the primary key is visible and can be changed as long as it is unique it is an explicit primary key.

Attributes that are foreign keys are implicit attributes. Attributes that are non-key are explicit attributes.

Constraints are implicit when they are data listed in a foreign entity. Constraints are explicit when they are a datatype.

Definitions are implicit when they protect explicit child tables. Definitions are explicit when they cascade manipulations.

Implicit manipulations maintain an audit trail. Explicit manipulations do not maintain an audit trail.

So, what is the purpose of implicity and explicity? Primarily it is strength and flexibility. Implicit design results in rigid, but more integral systems. Explicit design results in flexible, but less complete systems. For example, in an office you have work to rule, which is implicit, and work to allow, which is explicit. Ultimately, in dealing with implicity and explicity it is best to strike a balance. No system is fully normalized or fully exceptionalized. It is necessary to allow for both normality and exceptions as no system is fully closed or fully open.

Implicity and Explicity