Apeldoorn It 2008 - Adaptiviteit In Software Architectuur
1. “Great designs come from great designers” - F. P. Brooks
Adaptivity in Software Architecture
2. Who?
• Angelo van der Sijpt
• Software engineer
• Fontys Eindhoven, Computer Science, 2003
• TU Eindhoven, Computer Science and Engineering,
2007
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 2
3. Who?
• luminis
• 25 employees
• Arnhem, Enschede
• Innovative software
• In-house and at customer
• Share knowledge
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 3
4. Adaptivity
in
Software Architecture
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 4
5. Associations
• Robustness
• Intelligence
• Scalability
• Flexibility
• Autonomy
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 5
6. What is adaptivity?
• “Any sufficiently advanced technology is
indistinguishable from magic.” –Arthur C. Clarke
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 6
7. What is adaptivity?
• “Any sufficiently advanced technology is
indistinguishable from magic.” –Arthur C. Clarke
• Adaptivity is
• Something we ‘know when we see it’
• But we cannot point it out
• Something desirable
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 6
8. Emergence
www.robbaker.org
http://en.wikipedia.org/wiki/Internet
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 7
9. Redundancy
• What?
• Making elements expendable
• Current examples
• P2P systems, backups, RAID
• Issues
• No guarantees
• How to shut down?
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 8
10. Decoupling
• Localizing effects
• “Something has to give”
http://flickr.com/photos/33006928@N00/32979973/
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 9
11. Service awareness
• Everything is a resource
• Use when available, cope when not
• Trading, e.g.
• correctness for reliability
• quality for availability
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 10
12. Parallelizability & Distributability
• Some trends
• Multi-core systems
• Mobile equipment
• Increased networking
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 11
13. Scalability
Qu
ce
ali
an
ty
orm
of
se
rf
Pe
rvi
ce
Resource consumption
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 12
14. Adaptivity
in
Software Architecture
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 13
15. A concept
• What exactly is a concept?
• A fundamental choice of focus
• Could be a choice of technology, but underlying
this is likely something else.
• We can bind concepts together to form styles,
• or to form architectures
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 14
16. From concept to architecture
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 15
17. From concept to architecture
Style
Architecture
Concept
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 15
18. From concept to architecture
Quality factor
Style
Architecture
Concept
Artifact
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 15
19. From concept to architecture
Quality factor Nonfunctional
Style
Architecture
Concept
Artifact System
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 15
20. Adaptivity and software architecture?
• Useful styles
• Event based
• P2P
• SOA
• Measurable by concepts, but corresponding with
intuition
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 16
21. Adaptivity
in
Software Architecture
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 17
22. Whoops...
• Concepts...
• capture intuition, and
• are ‘recognizable’
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 18
23. Whoops...
• Concepts...
• capture intuition, and
• are ‘recognizable’
• But...
• are not ‘creatable’, and
• do not correspond to methods
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 18
24. Yes, there is a problem
• There are no fool-proof methods
• Still, there are many projects that end more or
less satisfactory. Why?
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 19
25. Yes, there is a problem
• There are no fool-proof methods
• Still, there are many projects that end more or
less satisfactory. Why?
• People
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 19
26. Any advice?
• Continue progress, but do not look for a silver
bullet.
• Be aware of oversimplification. Creating good
software is hard.
• Trust good people!
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 20
27. In the end
• Flexible, adaptive software needs a new way of
making it.
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 21
28. Angelo van der Sijpt
angelo.vandersijpt@luminis.nl
“Adaptivity in Software Architecture”, TU/e, 2007
tue.nl/bibliotheek
luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 22
Editor's Notes
Gee, hey, welcome. What do you expect this workshop will be about?
Oh, and please do interrupt me.
About this presentation: I want to look at adaptivity from a number of angles, show the six concepts written up recently, and arrive show that concepts as these are valid ‘input’ for an architecture process. Finally, this examples shows that the current ways of creating software might very well be the wrong ones.
This presentation is roughly based on ‘An engineer is not a carpenter’ and ‘Architecting adaptive software’
Any Associations? (It is not about adapting an architecture, it is about catching adaptive behavior in a system’s architecture. No, architecture does not change.)
Adaptivity leads to visions of autonomous robots that ‘do their own thing’ in a self sufficient way. Hardware is, of course, important, but we are reaching the limits of the complexity of software we can handle.
Example: IP routing. It is in essence very simple, but it displays seemingly intelligent behavior. This is all by design, but not from its architecture.
Basically, adaptivity is something we can recognize, but cannot point out or engineer; it does not really exist, but is an artifact of other concepts.
Coming next: those concepts!
Basically, adaptivity is something we can recognize, but cannot point out or engineer; it does not really exist, but is an artifact of other concepts.
Coming next: those concepts!
Left: Safari ants. Soldiers create a tunnel for other ants to pass under when the colony migrates.
Right: Partial internet topology, 2005
Binding: noone is ‘the boss’
Even simple combined behavior gets way over our head.
‘sufficient complexity’ & ‘balance in rules’
Ring of uselessness. In stead, we should not be interested in adding superfluous components, but how to make components in such a way that the can be superfluous
Technology has some nice examples, but so does nature (species) and society (culture).
However, we could lose determinism.
Stuff that breaks is not bad. Stuff that breaks and breaks the system, is.
We want to localize the effect: analogy of a guitar string.
Interfaces as a part of OO are a step in the right direction, but they try to localize effects in a single component.
Examples: Google news, audio system
Coping with changes in the available services a basic component of service frameworks; however, it can easily be misused.
Together, these trends lead to many sort-of isolated elements of calculation, which we might want to work together.
(Vision: only use processing power when we really need it, and adopt it to our surroundings when not)
(IBM stated in the 50’s that there would be a world market for 5 computers. It might even be 1.)
Redundancy allows us to make systems either more reliable, or bigger, or cheaper. Ideally, we want to be able to trade these. We saw something similar in resource consumption.
Combination of other concepts, but that also means that it could be harder to create.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Bottomline: we use concepts as binding and defining entities.
Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
Guess what, those are fashionable styles!
We don’t want to go from small to large,but the other way around! We don’t want unpredictability!
- Formalization doesn’t cut it
- An engineer is not a carpenter
- Software is not wood, and the engineer is not the ‘worker’
- Is software engineering really engineering?
We don’t want to go from small to large,but the other way around! We don’t want unpredictability!
- Formalization doesn’t cut it
- An engineer is not a carpenter
- Software is not wood, and the engineer is not the ‘worker’
- Is software engineering really engineering?
We don’t want to go from small to large,but the other way around! We don’t want unpredictability!
- Formalization doesn’t cut it
- An engineer is not a carpenter
- Software is not wood, and the engineer is not the ‘worker’
- Is software engineering really engineering?
Wickedness: describing the problem is the problem, no stopping rule, one-shot
Wickedness: describing the problem is the problem, no stopping rule, one-shot
Wickedness: describing the problem is the problem, no stopping rule, one-shot
Wickedness: describing the problem is the problem, no stopping rule, one-shot
Trust those good people. give them room, and do not think they are expendable and replaceable.