 |
component design |
|
component design |
|
design |
context |
home |
| design for connectivity
design for flexibility & biodiversity
|
This discussion is based on an ecological model of component supply. |  |
|
design goals |
example: nail |
| Increase information content
Look for ways of making component more active, more intelligent Expand connections with other components - networks enlarge small advantages Focus: critical mass |
Standard contractor size fits into standard air-powered hammers
SKU designation fits into retail sales network Bar code fits into laser-read checkout system Embedded chip warns door of breakage fits into smart house network |
|
design goals |
where is flexibility located? |
where is diversity located? |
| Distribute intelligence
Don’t just support the execution of transactions, support the design of transactions as well Automate / animate change Zero latency The weaker the interface specification, the more things will fit. |
in individual component
in component kit
in configuration
in architecture
|
in the component kit
in the configuration
in the management process |
|
design goals |
examples |
Whole product
Consider giving the key components away free
Focus: market share examples |
browser wars
search engines shareware |
|
design goals |
examples |
| Systems should be robust and fault-tolerant.
Components should tolerate erratic system behaviour. |
military systems
Internet |
|
design goals |
example: semiconductor |
| Aggressively exploit and anticipate the learning curve
Align to the scale economies of your business / market Repackage and reuse knowledge assets at all levels
|
Initial production cost: $100
Competing (old) product cost $1.05 We sell ours for same price - at a huge loss. Gain 90% market share. Within 2 years, selling the same product for 50¢ - at a profit. |
|
design goals |
examples |
reduce tension / stress
support self-preservation engage users balance contradictory forces
|
small changes with revolutionary potential
|
Components should be meaningful from five perspectives.
A component should serve a useful purpose, relative to the intentions of some community of agents.
A component should be semantically meaningful. Its interface has to have an information model that is recognisable by other agents within the service use ecosystem
The behaviour of a component needs to fit with the expectations of other agents. It must conform to standard or local interfaces and protocols.
The internal design must be compatible with the quality and performance demands of the device use ecosystem.
Technical requirements must be compatible with the available infrastructure and resources within the device use ecosystem.
This leads to an articulated component supply strategy.
|
Customization = maximum variation |
Standardization = minimum variation |
| Enterprise / Purpose
Information / Semantics Computational / Behaviour Engineering / Design Technology / Infrastructure |
Enterprise / Purpose
Information / Semantics Computational / Behaviour Engineering / Design Technology / Infrastructure |
contact details
Richard Veryard is a technology consultant, based in London. |
Please send comments and questions |
|
Last updated June 14th, 1999.
Copyright © 1999 Richard Veryard
http://www.veryard.com
