Generation 2 Philosophy

10/4/99 - Go Back

---

People's Needs

To gain a concise, crystal clear understanding of people's needs, we examine the key system stakeholders. Each stakeholder has only a few key needs, that once identified form a "needs pattern" themselves. Along with each need we list the key UHR best practices that fulfill that need. We tried layering these but it didn't come out clean.

7. Society - This is a little bogus. :-)
Key Need	Supported By
More environmental awareness	The habit of part reuse can spread to the habit of recycling, etc.
More cooperation, less competition, less proprietary and lock in approaches	The interconnectedness resulting from standards, part and tool reuse, and end user system configuration as the norm will lead to a more cooperative nature. This will be demanded by end users as they more and more drive the Digital Industry.
More contentment	Users can more easily express their own needs directly. Developers can focus more on self-expression and customer satisfaction, and less on code grinding. Managers can focus more on satisfaction and less on unpredictable schedules.

---

Foundational Philosophy

Given these needs and how UHR supports them, we can see dependencies and what helps the most. Add a dash of intuition, and you have:

1. DK is the timeless foundation for everything else. DK does one simple thing. It describes a structure populated with collaborating, configured parts. The structure itself is created by anything reasonable, such as adequate core parts today, better core parts tomorrow, and nanotech ten years from now.

As the years go by, more and more corporate investment will lie in describing system structures with DK, and not in coding systems. DK and code can vary independently, allowing periodic replacement of old code with better code or other mechanisms. It's like gradually replacing a car piece by piece while the driver goes on, and on, and on.... And so the largest investment, DK, is the safest - Just like the DNA in nature. Think of DK as "corporate DNA". If you want your IP to last longer, put it into DK, not code.

2. DK drives Circuit Based systems. DK really just describes great big circuit boards of parts. The Circuit Based pattern is so powerful it provides the main architecure. As a bonus, this architecture is congruent with electronics, making symbiosis much easier. The architectural elements are:

• Cellular Plugpoint Structure is the circuit board.
• Parts are the reusable, standardized devices.
• Datatrons are the electricity.
• Message chains are the circuits connecting devices.

3. Only Evolution Aware systems can avoid obsolescence.

• DK is the DNA that drives the entire system's behavior.
• The behavior of each part is varied by varying its DK.
• New behavior is achieved by editing a system while running.
• Parts can edit their own system, allowing self evolution.
• No framework can remain stable. It has to evolve to meet changing needs. Thus a chief requirement is "Infinite Extensibility".
• Infinite Extensibility is achieved via a domain neutral core, DK and the ability to do custom cores by merely using different core parts.
• Meanwhile, stability can be achieved in DK, because all it does is express what to do. The instablity occurs in how to do it.

4. Visual Tools sitting on the above will make programming as easy as writing. When this happens, the Software Age will have started its decline, and the ToolWare Age will be hitting its stride. After all, it was the discovery of the right tools that made the difference in The History of Man.

Remember, all the Visual Tools have to do is edit DK and show the conceptual representation of system form, such as models, System Tree, animation of Message travel, part dependencies, parts with personalities dancing, Datatrons feeding, etc. Why not make it fun! When speech comes to GUIs, users will converse with tools and parts, making programming even easier. The cool thing is the tools are built with parts themselves!

Thus the second generation reference implementation of UHR needs to first provide a DK layer, and then Circuit Based Plugpoint Structure on top of that. Above that "core" lies Part Inventories and Visual Tools. Everything else will tend to fall into place fairly automatically, because we have chosen the correct driving abstractions. We hope! :-)

---

Stability

We can see that UHR can be partitioned into DK, Parts, Core and Visual Tools. What about their stability?

1. The most stable must be the DK. This is a matter of defining a system's structure (Container DK) and how parts are initialized for reuse (Part DK). Really only Container DK is a challenge. If all it does is define what parts in in a container, where a part's DK comes from, what the circuits are, and what parts are started when the container is started, then it can remain stable. This looks straightforward. We will use no additional part configs like in the BA, which required reflection.

2. The second most stable must be Parts. Part stability is a matter of consistent, flexible interfaces that can handle all possible collaborations in a generic, anonymous manner. We have not yet analyzed this in detail with the goal of stability. It may boil down to a DK interface, a lifecycle interface, a Message in interface, and a Message out interface. These are the basics. Then there are more interfaces such as NodeUser and PartUser. The basics are starting to be well understood. The others are not so well understood.

3. The Core can vary easily as long as it honors Part expectations. Since most domain Parts don't use the core, this should be somewhat easy. It's only Visual Tool Parts, high performance Parts needing direct links, and Parts manipulating the System Tree for dynamic behavior that need Core access. We will carefully design various Fascades around the Core, such as PartReader.

4. Visual Tools use the Core, Parts and DK. They have the most expectations, but the good news is there are far fewer Visual Tools than everything else. So when the others change, only a few Visual Tools are affected.

Actually at first Parts must be the most stable, because that's where the greatest investment is. But over the years, Part reuse and substitution in many systems will cause DK to have the greatest investment.

So our first next step is defining clear, flexibile, stable interfaces between these partitions.