Shearing Layers – Part 1 physical buildings

In Stewart Brand’s terrific work, “How Buildings Learn”, there are some great analogies to what we do in Enterprise Architecture. He expanded on the concept of “shearing layers” introduced by Robert V. O’Neill in his “A hierarchical concept of ecosystems”. The primary notion being that we can hierarchically understand our ecosystems better by understanding the different rates of change possible at the different layers.

 
 
The diagram above is reproduced from How Buildings Learn, and represents the parts of a building which change at different rates. It is arranged from outside in with, in this representation, no absolute correlation between the parts and rate of change. 
Using Brand’s own explanation, the layers have the following descriptions:

Site

The site is the geographical setting, the urban location and the legally defined lot whose boundaries and context outlast generations of ephemeral buildings

Structure

The foundation and load bearing elements are perilous and expensive to change, so people don’t. These are the building.

Skin

External surfaces can change more frequently than the structure of the building. Changes in fashion, energy cost, safety, etc. cause changes to be made to the skin. However tradition and preservation orders often inhibit changes to the skin since the skin is very much the aesthetic.

Services

These are the working guts of the building, communications/wiring, plumbing, air handling, people moving. Ineffective services can cause buildings to be demolished early, even if the surrounding structure is still sound.

Space Plan

The space plan represents the interior layout – the placement of walls, ceilings, doors, etc. As buildings are re-purposed, as fashion changes so can the interior quickly be reconfigured.

Stuff

The appurtenances that make the space useful for its intended purpose. Placement of tables, chairs, walls cubicles, etc.
 
In further articles, I will develop this theme in 2 directions. First in thinking about how data can affect the way that retail organizations can think about their layout and organization (shearing at the Stuff/Space Plan layers of both brick and mortar and web stores. Second in looking at Enterprise Architecture through the lens of shearing layers – by analogy with Brand’s writing and thinking.

Shearing Layers – Part 1 physical buildings

In Stewart Brand’s terrific work, “How Buildings Learn”, there are some great analogies to what we do in Enterprise Architecture. He expanded on the concept of “shearing layers” introduced by Robert V. O’Neill in his “A hierarchical concept of ecosystems”. The primary notion being that we can hierarchically understand our ecosystems better by understanding the different rates of change possible at the different layers.

 
 
The diagram above is reproduced from How Buildings Learn, and represents the parts of a building which change at different rates. It is arranged from outside in with, in this representation, no absolute correlation between the parts and rate of change. 
Using Brand’s own explanation, the layers have the following descriptions:

Site

The site is the geographical setting, the urban location and the legally defined lot whose boundaries and context outlast generations of ephemeral buildings

Structure

The foundation and load bearing elements are perilous and expensive to change, so people don’t. These are the building.

Skin

External surfaces can change more frequently than the structure of the building. Changes in fashion, energy cost, safety, etc. cause changes to be made to the skin. However tradition and preservation orders often inhibit changes to the skin since the skin is very much the aesthetic.

Services

These are the working guts of the building, communications/wiring, plumbing, air handling, people moving. Ineffective services can cause buildings to be demolished early, even if the surrounding structure is still sound.

Space Plan

The space plan represents the interior layout – the placement of walls, ceilings, doors, etc. As buildings are re-purposed, as fashion changes so can the interior quickly be reconfigured.

Stuff

The appurtenances that make the space useful for its intended purpose. Placement of tables, chairs, walls cubicles, etc.
 
In further articles, I will develop this theme in 2 directions. First in thinking about how data can affect the way that retail organizations can think about their layout and organization (shearing at the Stuff/Space Plan layers of both brick and mortar and web stores. Second in looking at Enterprise Architecture through the lens of shearing layers – by analogy with Brand’s writing and thinking.

Business Architects: Do Not Start With Strategy

Frequently, when reading articles or books on business architecture, the following advice emerges:

Business architects start with the strategy of an organization.  They take that strategy and map it to the capabilities of the enterprise to clarif…

Categories Uncategorized

Fragility of Markets and Architecture Failure

As the NASDAQ exchange came to a grinding halt this past week, I, as well as many of you perhaps thought about system failure and what was the series of events and initial conditions that preceded the shutdown. Did a human did something strange that set a series of events in motion that jeopardized the…

The Zachman Framework Requires ZERO Documentation

The Framework is the Ontology

I have no idea where people get the idea that the Zachman Framework requires any documentation at all.  The Zachman Framework is an ontology – the theory of the existence of essential components of an enterprise (actually, of anything) that warrant description in order to successfully create it, operate it or change it. Whether any or all of those components are described (documented, made explicit) is a function of a methodology and the choice of the Enterprise… not a requirement of the Framework.

Models give you Power

Somehow or other, people hear me say, “Stop the music for 15 or 20 years until you get all of these models built and then you can start writing code again.” I have NEVER said anything even close to that.

What I have said is, “Some day… SOMEDAY, you are going to wish… forget you… SOMEDAY the ENTERPRISE is going to WISH they had all of these models made explicit, all of them Enterprise-wide, all of them horizontally integrated, all of them vertically integrated, all of them at excruciating level of detail.” Why?  Because, if they had all of those models made explicit, they would have a VERY powerful capability to accommodate extreme complexity and extreme rates of change. I have NEVER said when I thought that would be. I have ALWAYS said that might even be utopia… you might NEVER formalize all of the models. I have said, the 80/20 rule probably is in effect. If you have 80%, you might not need the other 20%. In fact, if you had 20% of the models, you might not need the other 80%. I also have said that in order to achieve the utopian condition of all the models formalized, it likely would require a lot of work and therefore, methodologically, you will probably have to figure out how to achieve that iteratively and incrementally over some longer period of time.

By the way, I ALSO always say, you can deliver substantial, immediate Enterprise value from a relatively small sub-set of Primitive Models. A little order goes a long way!

By the way again, there ARE implications to not producing any one of the Primitive Models identified by the Framework. Any model that you do not make explicit is implicit. By definition, you are making assumptions about any Framework Primitive Model that you have not made explicit and those assumptions may be right… or they may be wrong. Erroneous assumptions in manufacturing are called “defects.” Removing defects from anything is expensive and the closer you get to providing the implementation of the end result into the hands of your customers (“users”) before you discover the defect, the more costly it will be to remove it. (This is statistically provable… see Capers Jones work on “Software Quality”). Therefore, SOMEDAY, it would be in your best interests to have made all of the Framework Primitive Models explicit… however, you may be willing to assume the risk of some defects (the fewer, the better) at any given point in time.

The Framework gives you Power

The Framework is the ontology… NOT a methodology. The Framework implies nothing about which models you might want to produce (make explicit) or whether you want to produce any models at all. It implies nothing about how you might want to produce the models: top-down, bottom-up, left-to-right, right-to-left, where to start, etc. Although these are significant methodology choices, they are not prescriptions of the Framework. The Framework simply identifies the total set of architecture possibilities and therefore, the nature of the risks that may be or may have been assumed.

Author

John A. Zachman

Alignment – Mobility

Positioning one’s own personal brand is something that may not come naturally to some folks. One may think that only applies to marketing types. But it doesn’t. Its important to demonstrate a sense of flexibility and awareness to one’s contirbutions within organizations. Personally, I think a bit of variety in one’s career is beneficial and […]

The Dilemma: Communicating IT Business Value

SCENE 1, MID-AFTERNOON, FADE IN:
IT walks through the door after a checkpoint meeting and sits on the couch.
Doctor: What brings you to my office today?
IT: I think the business might be leaving me for a younger, slimmer, sexier, IT alternative.
Docto…

Categories Uncategorized

Quantitative Semantic Algebra – Dr. Barry Robson (RQSA)

RQSA Theory – Develops algorithm for The QEXL Approach; overcoming limitations in gold standard Bayesian Network; while allowing for creation of generative models. Bayesian as such is an adaptive technique. (March 8 2013, Version March 10 2013) 1. INTRODUCTION 1.1. Purpose and Background. The following document describes principle features of a mathematical system of practical […]