Technology Grid

January 12, 1999 - Jack Harich - Go Back

Overview

What do you do when you have a concept that is too large to explain easily? It's so large the conceptual model has become a 20" by 30" foamcore board with a grid of sticky notes on it. Hmmmm, there are 92 notes! Maybe what's happening is I've lived at the level of abstraction this grid represents for days, and I can't easily slip out. I've tried several documents now. They all felt awkward. Let me try again....

To the right is the original. For a readable grid, set your left and right print margins to 1/4", print Page One and Page Two, and connect the pages with tape, with Page Two on the right. (Or use the original Visio files in WinZip format. These are much higher quality and more current.) You and I are now looking at the same diagram as I write this. Let's give it a title like "Multi-Phase Technology Development Grid for Next Generation UHR Software".

We're building on what was learned from the Bean Assembler and Data Framework in 1997 and 1998. While this iteration is hard to use by anyone except the original developer, it does offer proof that certain avenues are worth continuing. Notably it validates the ideas in Structured Assembly. Its main weaknesses are hard to learn and use, no easy UI editor for parameters and system trees, and no large number of well designed parts. But it is better than classical OO design with no suitable infrastructure.

Two Stages

I can now see where parts are going. Looking beyond that, that next challange is graduating from code and prodecural logic to a whole new plateau characterized by telling systems what to do with goals and rules (configurable logic), and letting them figure out how to do it, and even eventually having the system intellegently ask for guidance and offer novel suggestions. Hence we divide the phases into the Parts Stage and the Logic Stage. The appropriate phases are in the left hand column: From bottom to top they show how we can go from where we are now to where we need to be. This will take 5 to 10 years. The first stage, Parts, has no unknown technology except Base Roles. It can be done in a year or two depending on investment rate. We are currently about 1/3 through the Parts Stage.

The purpose of the Parts Stage is to provide the infrastructure for making the Logic Stage easier. If fact, there is a bridge to make this easy. Note the two Policy Parts. The first, in the last phase of the Parts Stage, has its logic expressed with code. The second, in the first phase of the Logic Stage, has its logic expressed with configurable knowledge of some kind, such as goals and rules, aka Expert Systems. This is designed to be an easy jump. Once we have solved it, many doors open. The stage has been set for this by using Declarative Knowledge (DK) driven reusable parts in the Parts Stage. Configurable logic is thus merely a new type of DK from the system's point of view.

Actually the purpose of the Parts Stage is to make any next stage easier. We are planning for the Logic Stage because that is the toughest but offers the most benefits. Other easier stages we could branch off into once Parts have a very firm foundation are:

What is the overwhelming reason for pursuing the Logic Stage? Think about this:

The only sustainable advantage an organism can have is the ability to learn faster than its competitors.

During or after the Logic Stage a second branch explosion will occur as entirely new possibilities become evident, such as:

Productivity Impact

At first glance the 2 to 10 fold productivity gains per phase seem preposterous. It can't be done. Is this vision nuts?

But remember we are allowing 5 to 10 years for all 8 phases. Examine each phase in detail. The N Fold estimates are conservative if we do a phase well. So what if we don't do a phase well, and only get half these estimates or so? That's still not so shabby.

Plus let's remember we are already about half way through phase 2. For those that understand all this, a 2 to 4 fold gain is already being achieved. Unfortunately only the original author understands it fully. This problem will be rectified by the Ease of Use phase.

Due to the multiplier effect, we expect the gains to be multiplicative, not additive.

EPM Analysis

It's hard to know when you have the correct mechanism to achieve a goal. To make this easier we use the causal path analysis of Effect, Principle and Mechanism (EPM Analysis). This technique helps us figure out how to best cause an effect, the designer's hardest decision. Given an Effect you want to achieve, first identify the proper Principles to use, then the proper Mechanisms to support those Principles. This leads to less rework since you tend to use the correct mechanism the first time. The alternative causal path of Effect, Mechanism, Principle is only good for post-analysis, but is useful for determining which of several possible Mechanisms is better.

For example suppose you want to achieve the effect of Configurability. The beginner will think in implementation terms of property files or IDE property sheets. The pro will think at a higher level and choose Declarative Knowledge (DK), a Principle. Then they will decide the best Mechanism to implement DK, such as XML.

EPM Analysis is like patterns, which are really Principles that lead to better designs, which are Mechanisms. When we apply patterns we are using EPM Analysis, but we may not know it.

Now for the real advantage of EPM Analysis - filling design gaps. Note the upper portion of the Concept Grid. There are fewer Principles and Mechanism as we approach the top phases of Proactive and Creative. If we start with desired Effects, we can think real hard and rough in some possible Principles, as we have done. From these Principles we can make some first passes at our Mechanisms, as we have also done. For example we wrote down the main Effect of the Proactive phase to be "System anticipates user's and other system's needs." Certainly ambitious. The we wrote down the Principle "All rational behavior follows predictable patterns." From this is was obvious we needed to find those patterns, so we needed the Mechanism "Pattern Recognition." This will take lots of iterations to get right, be we have a long time to think about the upper phases.

This explains the grid organization. From left to right we have Theme (of the phase), Effects, Principles, Mechanisms, User Productivity and Developer Productivity. The last two columns are estimates of the impact of achieving a phase's Effects well.