Engineering Large Evolving Systems Ben Potter Department of Informatics and Sensors, Cranfield...
-
Upload
agnes-dalton -
Category
Documents
-
view
215 -
download
2
Transcript of Engineering Large Evolving Systems Ben Potter Department of Informatics and Sensors, Cranfield...
Engineering Large Evolving Systems
Ben Potter
Department of Informatics and Sensors, Cranfield University
Contents
• The case study – Network Enabled Capability• Challenges for engineering• Discussion
What is NEC?
• The attainment of a Network Enabled Capability in UK Defence• Sometimes also referred to as Capability Enhanced by
Networking – not as snappy but perhaps more descriptive!• UK MOD Joint Service Publication JSP 777 says:
– ‘The achievement of military effect will, in future, be significantly enhanced through the networking of existing and future military capabilities, under the banner of NEC’
What is NEC ?
Working definition (from MOD website):"Linking sensors, decision makers and weapon systems so that information can be translated into synchronised and overwhelming military effect at optimum tempo"
“NEC is about the coherent integration of sensors, decision-makers and weapon systems along with support capabilities”
What is NEC ?
A Navy view?
An Army view?
An aside
• 1976 Networkshop…
Some questions:
• Given (say) a 12 year horizon for NEC:1. Who can describe the military threats to be met?
2. Who can imagine the technologies to be used?
3. How can ‘traditional’ systems engineering help, given that:– 1 above suggests we can’t write the requirements– 2 above suggests we can’t describe a solution which
will not be obsolete
– First – a definition: Engineered Large Yet Evolving Systems – ELYES. NEC is an ELYES.
– This leads us to appeal to the origins of systems engineering for help – or, at least – guidance
What is a ‘System?’
System as a set of interacting parts
“A system is an open set of complementary, interacting parts with properties, capabilities, and behaviours emerging both from the parts and from their interactions.”
Hitchins, Advanced Systems Thinking, Engineering and Management, 2003
System as a way of conceptualising
“… the concept of ‘system’ is used not to refer to things in the world but to a particular way of organising our thoughts about the world. [..] we consider the notion of ‘system’ as an organising concept …”
Flood and Jackson, Creative Problem Solving – Total Systems Intervention, 2004
Different ‘organising concepts’
Family Person
Engineer
Cyclist
Chancellor of Exchequer
The System Boundary
“… the scientist has to have a way of thinking about the environment of a system that is richer and more subtle than a mere looking at for boundaries. He does this by noting that, when we say that something lies ‘outside’ the system, we mean that system can do relatively little about its characteristics or its behavior. Environment, in effect, makes up the things and people that are ‘fixed’ or ‘given’, from the system’s point of view. …”
Churchman, The Systems Approach, 1968
A system’s emergent properties
“Emergence is the phenomenon of properties, capabilities and behaviours evident in the whole system
that are not exclusively ascribable to any of its parts.”
Hitchins, Advanced Systems Thinking, Engineering and Management, 2003
Summary: a system is …
• A organising concept – a way of structuring a concept or problem or a thing from a particular perspective.
• A system is made up of a set of interacting parts
• The system has properties and behaviour that emerge from the interaction of the properties and behaviours of the individual parts.
• The system has a boundary defined in terms of ‘things that affect it but that it cannot affect.’ – but the boundary can be broad and permeable.
How do we analyse ‘Systems’?
How we analyse systems“… This is the basic principle of ‘classical’ science, which can be circumscribed in different ways: resolution into isolable casual trains, seeking for ‘atomic’ units in the various fields of science, etc. The progress of science has shown that these principles of classical science – first encountered by Galileo and Descartes – are highly successful in a wide range of phenomena.
Application of the analytical procedure depends on two conditions. The first is that interactions between ‘parts’ be non-existent or weak enough to be neglected for certain research purposes. Only under this condition, can the parts be ‘worked out’, actually, logically and mathematically, and then be ‘put together’. The second condition is that the relations describing the behaviour of the parts be linear; only then is the condition of summativity given …”
Bertalanffy, General Systems Theory, 1969
How we analyse systems“… This is the basic principle of ‘classical’ science, which can be circumscribed in different ways: resolution into isolable casual trains, seeking for ‘atomic’ units in the various fields of science, etc. The progress of science has shown that these principles of classical science – first encountered by Galileo and Descartes – are highly successful in a wide range of phenomena.
Application of the analytical procedure depends on two conditions. The first is that interactions between ‘parts’ be non-existent or weak enough to be neglected for certain research purposes. Only under this condition, can the parts be ‘worked out’, actually, logically and mathematically, and then be ‘put together’. The second condition is that the relations describing the behaviour of the parts be linear; only then is the condition of summativity given …”
Bertalanffy, General Systems Theory, 1969
How we analyse systems“… This is the basic principle of ‘classical’ science, which can be circumscribed in different ways: resolution into isolable casual trains, seeking for ‘atomic’ units in the various fields of science, etc. The progress of science has shown that these principles of classical science – first encountered by Galileo and Descartes – are highly successful in a wide range of phenomena.
Application of the analytical procedure depends on two conditions. The first is that interactions between ‘parts’ be non-existent or weak enough to be neglected for certain research purposes. Only under this condition, can the parts be ‘worked out’, actually, logically and mathematically, and then be ‘put together’. The second condition is that the relations describing the behaviour of the parts be linear; only then is the condition of summativity given …”
Bertalanffy, General Systems Theory, 1969
How we analyse systems“… This is the basic principle of ‘classical’ science, which can be circumscribed in different ways: resolution into isolable casual trains, seeking for ‘atomic’ units in the various fields of science, etc. The progress of science has shown that these principles of classical science – first encountered by Galileo and Descartes – are highly successful in a wide range of phenomena.
Application of the analytical procedure depends on two conditions. The first is that interactions between ‘parts’ be non-existent or weak enough to be neglected for certain research purposes. Only under this condition, can the parts be ‘worked out’, actually, logically and mathematically, and then be ‘put together’. The second condition is that the relations describing the behaviour of the parts be linear; only then is the condition of summativity given …”
Bertalanffy, General Systems Theory, 1969
How we analyse systems
“… the method of classical science was most appropriate for phenomena that either can be resolved into isolated causal chains, or are the statistical outcome of an ‘infinite’ number of chance processes, as is true of statistical mechanics, the second principle of thermodynamics and all the laws deriving from it. The classical modes of thinking, however, fail in the case of interaction of a large but limited number of elements of processes. Here those problems arise which are circumscribed by such notions as wholeness, organisation and the like, and which demand new ways of thinking.”
Bertalanffy, General Systems Theory, 1969
How we analyse systems
“… the method of classical science was most appropriate for phenomena that either can be resolved into isolated causal chains, or are the statistical outcome of an ‘infinite’ number of chance processes, as is true of statistical mechanics, the second principle of thermodynamics and all the laws deriving from it. The classical modes of thinking, however, fail in the case of interaction of a large but limited number of elements of processes. Here those problems arise which are circumscribed by such notions as wholeness, organisation and the like, and which demand new ways of thinking.”
Bertalanffy, General Systems Theory, 1969
How we analyse systems
“… the method of classical science was most appropriate for phenomena that either can be resolved into isolated causal chains, or are the statistical outcome of an ‘infinite’ number of chance processes, as is true of statistical mechanics, the second principle of thermodynamics and all the laws deriving from it. The classical modes of thinking, however, fail in the case of interaction of a large but limited number of elements of processes. Here those problems arise which are circumscribed by such notions as wholeness, organisation and the like, and which demand new ways of thinking.”
Bertalanffy, General Systems Theory, 1969
‘System space’
Increasing number of ‘nodes’
Increasing intricacy of the ‘couplings’
Statistics and dynamics relating to very large numbers of well defined nodes and couplings.
Statistics and dynamics relating to very large numbers of well defined nodes and couplings.
Decoupled or very well defined couplings between relatively few nodes.
Decoupled or very well defined couplings between relatively few nodes.
Nodes that have ‘adaptive’, non-trivial couplings.
Nodes that have ‘adaptive’, non-trivial couplings.
Coping strategies
Increasing number of ‘nodes’
Increasing intricacy of the ‘couplings’
Tendency to treat ‘complex’ systems within ‘comfort zones’
Tendency to try to inappropriately extend ‘comfort
zone’ techniques
Example Systems
Increasing number of ‘nodes’
Increasing intricacy of the ‘couplings’
TeamsTeams
OrganisationsOrganisations
WeatherWeather
ClimateClimate
Space shuttleSpace shuttle
AircraftAircraft
CarCar
Termite hillTermite hillFlock of birdsFlock of birds
Gas in a containerGas in a container
Detailed example systems
Gas in a container
Gas atoms and
molecules
Car
Driver Engine Drive Train
Fuel system
Emergent behaviour: ride comfort,
acceleration…
… and is very determinant
Emergent behaviour: pressure…
… and can be determined through
statistical and probabilistic analysis
Detailed example ELYES
Military Capability
Command
InformPrepare
ProjectOperate
Protect Sustain
Emergent behaviour: effects…
… and cannot be determined to any
degree of certainty
Example Systems
Increasing number of ‘nodes’
Increasing intricacy of the ‘couplings’
TeamsTeams
OrganisationsOrganisations
WeatherWeather
ClimateClimate
Space shuttleSpace shuttle
AircraftAircraft
CarCar
Termite hillTermite hillFlock of birdsFlock of birds
Gas in a containerGas in a container
SystemSystem
OrganisationsOrganisations
ELYES
• ELYES Architecture is concerned with optimisation at the global level, sometimes necessarily at the expense of local considerations
• In pursuit of this goal, the ELYES Architect may be tempted to over-simplify and
• Adopt a one-size-fits-all approach
• See more homogeneity in the ELYES than there really is
• Assume linear, predictable systems
• Focus on static, structural elements, while ignoring dynamic interactions
• While this response is understandable, is it reasonable?
Architecting an ELYES
The problem
• Changing environments require systems/ELYESs to change:
• Either to reflect the changes in the environment or anticipate them.
• The unpredictable nature of the environment includes:
• Dynamic entities (threats and contributors) within the environment.
• New entities that are constantly evolving and old ones disappearing.
• Relationships between the entities that are constantly changing.
• The overall behaviour exhibited by inter-related entities are emergent.
• The characteristics of the system/ELYES have to be at least as complex as its environment.
Thesis / Premise
• Traditionally we design systems by identifying the ‘static’ customer need, using a top-down, reductionist approach. This single mode of analysis struggles to cope with:
• Dynamic interactions within the system
• Non-functional requirements (e.g. agility and flexibility)
• Complex emergent properties and behaviours
• We argue that for ELYESs to operate it requires appropriate developmental and operational environments in which traditional systems can be developed and used.
Very clear distinction between development/design, production and use.
Development, production and use all run in parallel.
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
The ELYES depends on both internal cooperation and internal competition to stimulate its evolution.
Unwanted possibilities and unknowns are removed before use of the system
New possibilities are constantly assessed for utility and feasibility in the evolution of the ELYES.
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
The ELYES is self-integrating and re-integrating in order to meet the changing need.
Development always ends for each instance of system realisation
ELYES development never ends – the ELYES evolves
System has well-defined boundaries and behaviour. The ELYES has ambiguous boundaries and unpredictable behaviour.
System is realised to meet a single, pre-conceived need
No single, or set of needs can be pre-conceived for the ELYES. The ELYES has to continually evolve to meet the changing need.
System is reproducible No two instantiations are alike
Systems and ELYESsSystems ELYES
Systems: Implications for developmentSystems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
Implications for Development
Once the design is fixed the production can be ‘mechanized’.
The design can be fixed, the ‘need’ does not change once it has been agreed. There is an agreed ‘product’.
Development and production can be decomposed into sub-products with well defined behaviours, which can then be composed to form the whole.
No further development once the product is handed over to the user.
The user cannot change the product.
The behaviour of the delivered product is bounded and known.
The product is not delivered until the user knows how to use it.
Design, production and use can be treated as totally separate phases with mechanised processes and well defined boundaries and products.
ELYESs: Implications for developmentImplications for Development
The ‘design’ cannot be fixed and the production cannot be ‘mechanized’.
The need for the ELYES is continually changing. The ELYES can only evolve through use.
Not all sub-units can be identified and some may not be controllable. Achieving the desired behaviour is about creating the appropriate environment and influencing sub-units.An appropriate environment has to be developed that lets the system evolve through use.
The user has freedom to re-integrate as required. The ELYES must be designed to be ‘modular’ with configuration ‘rules’.
The ELYES is never completed and the role of development and production is to provide the user with the means for evolution.
The ELYES is heterogeneous and relies on conflicts and collaborations to evolve. These must not be ‘designed out’.
The development, production and use lifecycle must be adaptable and not prescriptive.
ELYESs
No two instantiations are alike
No single, or set of needs can be pre-conceived for the System. The system has to continually evolve to meet the changing need.
System has ambiguous boundaries and unpredictable behaviour.
System development never ends – system evolves
System is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the system
System depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
System acquisition
Spe
cific
atio
nAbility to do stuff
Time
Target
Require-ments
Programme
ELYES Acquisition
Ability to do stuff
Time
Spe
cific
atio
n(T
ole
ran
ce)
? Principles ?
?
Programme
?
Implications for engineeringan ELYES
It’s about setting the right environment NOT designing top down.
Designing the ELYESOperational
Need
ELYES Design
ELYES Architecture
Cap 1
Development Environment
Cap 2 Cap 3 Cap n
Kit Kit Kit
Operational Environment
Kit
Evolving the ELYES
Operational Need
‘Big Picture’
Partition Rules
ELYES Architecture
Orchestration Rules
Cap 1 Cap n
Development Environment
Orchestration Rules
Kit Kit Kit
Operational Environment
• Capability development is enabled by providing the appropriate development environment.
• Number of and definition of capability building blocks– Cannot be predetermined
– Will evolve independently
– Will have overlapping functionality with one another.– Redundancy, i.e. variety, in the system is desirable
• Operational use of the capability is defined by orchestration rules which will encourage appropriate ‘usage’ philosophy.
• The orchestration rules are defined during development and will evolve.
• Evolution during operational use must drive development.
Implications for engineeringan ELYES
Discussion
Example: A Bridge
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
ELYES
No two instantiations are alike
No single, or set of needs can be pre-conceived for the ELYES. The ELYES has to continually evolve to meet the changing need.
The ELYES has ambiguous boundaries and unpredictable behaviour.
ELYES development never ends – the ELYESr evolves
The ELYES is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the ELYES
The ELYES depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Sp
eci
fica
tion
Target
Example: Software
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
ELYES
No two instantiations are alike
No single, or set of needs can be pre-conceived for the ELYES. The ELYES has to continually evolve to meet the changing need.
The ELYES has ambiguous boundaries and unpredictable behaviour.
ELYES development never ends – the ELYES evolves
The ELYES is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the ELYES.
The ELYES depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Sp
eci
fica
tion
Target
Example: Space Race
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
ELYES
No two instantiations are alike
No single, or set of needs can be pre-conceived for the ELYES. The ELYES has to continually evolve to meet the changing need.
The ELYES has ambiguous boundaries and unpredictable behaviour.
ELYES development never ends – the ELYES evolves
The ELYES is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the ELYES
The ELYES depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Sp
eci
fica
tion
Target
Sub-Target
Sub-Target
Sub-Target
Example:My kitchen
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
ELYES
No two instantiations are alike
No single, or set of needs can be pre-conceived for the ELYES. The ELYES has to continually evolve to meet the changing need.
The ELYES has ambiguous boundaries and unpredictable behaviour.
ELYES development never ends – the ELYES evolves
The ELYES is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the ELYES
The ELYES depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Sp
eci
fica
tion
(To
lera
nce
)
Example:NEC
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
ELYES
No two instantiat6ions are alike
No single, or set of needs can be pre-conceived for the ELYES. The ELYES has to continually evolve to meet the changing need.
The ELYES has ambiguous boundaries and unpredictable behaviour.
ELYES development never ends – the ELYES evolves
The ELYES is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the ELYES
The ELYES depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Sp
eci
fica
tion
(Ra
ng
e o
f u
ses)
Spe
cific
atio
nS
peci
ficat
ion
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
Enterprise
No two instantiations are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterpriser evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
Enterprise
No two instantiations are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterpriser evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Ability to do stuff
Time
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
Enterprise
No two instantiations are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterpriser evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
Enterprise
No two instantiations are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterpriser evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Enterprise
No two instantiations are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterpriser evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
TargetTarget
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
Enterprise
No two instantiations are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterprise evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise.
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Ability to do stuff
Time
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
Enterprise
No two instantiations are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterprise evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise.
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Enterprise
No two instantiations are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterprise evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise.
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Spe
cific
atio
n
Target
Spe
cific
atio
nS
peci
fica
tion
Target
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
Enterprise
No two instantiations are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterprise evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Ability to do stuff
Time
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
Enterprise
No two instantiations are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterprise evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Enterprise
No two instantiations are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterprise evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Spe
cific
atio
n
Target
Sub-Target
Sub-Target
Sub-Target
Spe
cific
atio
nS
peci
ficat
ion
Target
Sub-Target
Sub-Target
Sub-Target
Summary: Lifecycles
Bridge
Software
Space Race
Kitchen
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
Enterprise
No two instantiations are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterprise evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Ability to do stuff
Time
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
Enterprise
No two instantiations are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterprise evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Enterprise
No two instantiations are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterprise evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Spe
cific
atio
n(T
oler
ance
)S
peci
ficat
ion
(Tol
eran
ce)
NEC
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
Enterprise
No two instantiat6ions are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterprise evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Ability to do stuff
Time
Ability to do stuff
Time
Systems
System is reproducible
System is realized to meet a single, pre-conceived need
System has well-defined boundaries and behaviour.
Development always ends for each instance of system realization
External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.
Unwanted possibilities and unknowns are removed before use of the system
Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed
Very clear distinction between development/design, production and use.
Enterprise
No two instantiat6ions are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterprise evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Enterprise
No two instantiat6ions are alike
No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.
The Enterprise has ambiguous boundaries and unpredictable behaviour.
Enterprise development never ends – the Enterprise evolves
The Enterprise is self-integrating and re-integrating in order to meet the changing need.
New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise
The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.
Development, production and use all run in parallel.
Spe
cific
atio
n(R
ang
e of
use
s)S
peci
fica
tion
(Ra
nge
of u
ses)