The Innovator’s (and Zachman’s) Dilemma

 clayton_christensen.jpg

Clayton M. Christensen wrote The Innovator’s Dilemma almost a decade ago, but the insight his book provides is classic. Christensen’s research into the disk drive industry lead him to discover four categories of competition:

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

Availability answered the question: Can it be done? Compatibility answered the question: Can it be done for me? Reliability answered the question: Can it be done when I need it done? Economy answered the question: Can it be done at the lowest price? The greater the number of customers you can respond to with a “Yes” answer the broader your market. However, your smart competition is looking for the niches you are responding “No” to.

When I look at these four categories I am brought back to John Zachman’s perspectives in the Zachman Framework. These same questions are posed when developing any system:

  1. Conceptual
  2. Contextual
  3. Logical
  4. Physical

The conceputal perspective answers: Can it be done? The contextual perspective answers: Can it be done by us? The logical perspective answers: Can it be routinized? The physical perspective answers: What is the lowest cost to do it? And these questions are asked for each of the focuses (People, Data, Network, Time, Functions and Motives).

So what Christensen really achieves is to provide a substantiation of his tetrad, and consequently Zachman’s, through a solid body of historical data.

System Security

John Zachman’s use of the basic interrogatives to define a system lends itself to alternative analysis. One of these cases is system security. When it comes to security there are only four acts you can commit: Select, Insert, Update and Delete. However, you can commit these acts for each of the Zachman Framework Focuses: Data, Network, Motive, Process, People, Time and each of the Zachman Perspectives: Conceptual, Contextual, Logical, Physical, Mechanical, Instantial. What you have as a product is not just a security table, but a security cube. Below is an example of a security table defining 24 possible violations:

systemsecurity.jpg

A security cube would define 4 x 6 x 6 = 264 possible violations. It should be added that violations do not always work in isolation. For example spyware is a procedural insert and data selection. How many cells in the security cube would be affected if a plane crashed into one of your facilities?

It is also important to note that preventing snooping (or sniffing) is often an effective way to prevent the other three manipulation operations.  What they can’t see can’t hurt you.