Essay on design
This essay is just getting started. More to come, if it turns out to be interesting to anybody.
Layers
These are conceptual layers, not necessarily actually identifiable layers in the developed software. (Although most them are.)
Forced moves in design space
This is a concept originated by Daniel Dennett, an evolutionary philosopher. In a software context, it means that in order to accomplish some goal, you will be forced to use some version of some particular design.
The forced moves in value network software include:
- A network, or graph, structure of nodes and links. See Graph theory.
- The REA (Resources, Events, Agents) pattern. See Bill McCarthy's REA papers.
- Type, Plan and Event levels. See Concepts on the valnet github wiki.
You have some degrees of freedom as to how you implement those moves, but not many. And you can call them all different names. But you will use them.
Those are all in the foundation. Which, if you change, you better know what you are doing.
Hard and soft layers
Hard layers are still changeable, but they take more work to change.
The database schema is the hardest layer.
The code is the next-hardest layer. It's open source, all changeable. Less work to change than the database schema, but more work than the configuration parameters.
The configuration parameters are the next softer layer. They include Event Types and the New configuration components just added to deal with the problem of long and confusing selection lists: Faceted Classification and Process Patterns
We made a design error in exposing Event Types on the operational interfaces (as François pointed out). (But then, that's why we have feedback loops...) Event Types were too difficult to understand and have too many consequences to have people making everyday operational decisions about which Event Type to select. They are now being hidden in Admin, and selected automatically by the operational software. We do want them to be configurable, but once they are configured for a particular network, they will seldom be changed. They have logical consequences: you can introduce bugs into the system by the wrong choice of configuration parameters.
Which brings us to the next softer layer: Admin. Admin is pretty close to a raw database interface. It is intended for superusers, who set up the configuration parameters and can access and tinker with almost all the data in the system. They can also make big messes if they do not know what they are doing.
The next layers constitute the Operational interface, where you should not be able to make big messes. (The system should prevent mistakes, or at least warn you. Sometimes it fails. Those are bugs. They will be fixed.)
The hardest layer in the Operational interface is the Type level: Resource Types, Process Types and Recipes. Recipes are the configuration layer for manufactured products. Projects and the Value Equation also live in the Type Level.
The next softer layer is the Plan level: Orders, R&D projects, process and task schedules, material requirements, etc.
Then there's the Event level: Time Contributions, Financial Contributions, resource production and consumption, etc. That's where most people will do most of their work.
The Event Level will be used by the Value Equation to distribute income according to contributions.