Transcript The Future of Software Architecture

The Future of Software Architecture
Maarten Boasson
Universiteit van Amsterdam
Quærendo Invenietis bv
[email protected]
What is Software Architecture?
• The definition has changed over the years
– From very technical
• components interacting through connectors
– To including everything
•
•
•
•
Stakeholders
Requirements
Management
…
• I like to limit architecture to technical issues
– An architect obviously has other problems to attend to as well
• In essence it is the first step in design
• Why is it so important?
– Is sets the framework for all further design work:
It guarantees certain system properties
at the cost of
Reduced freedom for the designer
• We do not grasp the essence of architecture
Technically, there has been little progress
Therefore, we concentrate on process aspects
• Exactly as happened in software engineering
With the same detrimental effect
35 years of research in SE
• Software Crisis now worse than in 1968
– 85% of large software projects fail
• Never complete
• Way over budget and/or over time
• Reduced functionality
– Reliability of software very questionable
– Incredible waste of resources
– Development effort out of proportion
… characterized by
• Process orientation
– Taken from the engineering analogy
• product = process ( design, materials)
• Tools that support current practice
– If the only tool available is a hammer …
– Add complexity to the problem
• Lack of fundamental understanding
– No theory
• No learning - we re-invent the wheel over and over
again - and get it always wrong
We don’t know what we are doing
Typical system
functionality
1968
now
time
Typical system
•
cost
functionality
Desired system:
–
–
–
–
Very limited
Truly
supportive
functionality
Highly flexible
Inflexible
Sometimes
Always
wrong
right
Affordable
Very
expensive
functionality
cost
1968
now
time
The wrong engineering analogy has been the
basis for almost all research in SE during the
past decades ... one should not be surprised
that the effect on quality and productivity is
almost negligible (if not negative).
Examples of bad software
FAA Air Traffic Control
Windows
Cockpit blackouts in 747
http://catless.ncl.ac.uk/Risks
• Complex software cannot be designed by mediocre
programmers
• Yet, that is what the industry tries to do
– 4 top designers will produce quality software in less time
than 100 unskilled ones — there is widespread agreement,
but nobody acts accordingly
Note that in software we do not have the luxury of safety margins!
Industrial needs
• Predictable development
in terms of
– functionality
– delay
– cost
– robustness
• Flexible development
– requirements creep
– all kinds of constraints on solutions
• Theory-based rules-of-thumb (engineering)
– with associated techniques for measuring progress
• Domain expertise
– Current education does not provide enough basis
How can we meet these?
• Unfortunately, society cannot step back in its
dependence on computer-based systems
• So, the only hope lies in migrating from the sad state
of affairs today to a better situation in the future
• Higher education is key
• Fundamental research is vital
• Is agreeing on best practice a viable path?
Higher education
• Education is about learning essential skills
and attitudes
• Education is not about preparing students for
immediate productivity in industry
Higher education
• We must teach fundamentals
– various abstraction mechanisms
– different ways of expressing behaviour
• functional, imperative, OO, logic, algebraic ...
– different process approaches
• We should not teach today’s fads
– specific programming languages
• Java, ML, C#, Prolog, …
– specific process models
• Spiral, XP, CMM, …
Fundamental research
• Research is about
– Understanding
– Finding general principles
• Research is not solving problems for industry
Fundamental research
•
Is it worth trying to find an approach to software development
analogous to engineering?
– Such as e.g. formal description of behaviour followed by an engineering
step to deal with the “ilities”
– Not obvious: the quality attributes are the really difficult part!
•
Should we search for something radically different?
– View software construction as an art, and learn from the arts, e.g.
•
Or should we continue the path that has not led us anywhere?
– Hoping that it will eventually, but knowing that it won’t
•
Does anybody really understand software design?
– if we don’t, how can we prescribe how to do it?
Is there a Good Practice?
•
How do we know a practice is good?
– there are no metrics
– we hardly analyse finished or failed projects
– we never conduct parallel experiments
“Producing reliable software: an experiment”
The Journal of Systems and Software 61 (2002) 213-224
•
What is universally good practice?
– Don’t put undue pressure on developers
Unfortunately, this is not practiced …
•
Depends on application domain
– high-reliability is approached very different from low-cost (maybe it shouldn’t
...)
•
Depends on chosen tools
– Object Oriented design is different from Functional Programming
State of the Practice
“I don’t care if the experts say this project can’t be
done in less than 6 months. I want you to do it in 4!”
Can we agree on good practice?
•
•
•
•
In general: I am afraid not
Risk: blindly following unchecked ideas
In specific instances: probably to some extent
Ultimately yes, but there is a long way to go
– How long does it take to undo 35 years of faulty practice?
– What do we replace it with?
Can we migrate to good practice?
Only if
–
–
–
–
–
–
we grow up and start behaving responsibly
we analyse practices and learn from it
put the best minds to solving difficult problems
make sure we educate well
Incorporate research results into practice
take time when time is needed
The future of software architecture
• Optimistic view
– We will understand the relationship between architecture and
application type
– We will have guidelines for selecting an architecture, given required
properties
– We will have guidelines for design as a function of the selected
architecture
– There will be theory for proving properties of systems
• Pessimistic view
– Architecture will have become an empty container concept
– The architecting process will solve all problems
or
– Architecture will have been obscured by yet another fad