the future of software architecture maarten boasson universiteit van amsterdam quærendo invenietis...
Post on 24-Dec-2015
222 Views
Preview:
TRANSCRIPT
The Future of Software Architecture
Maarten BoassonUniversiteit van Amsterdam
Quærendo Invenietis bvmb@quaerendo.com
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
time1968 now
Typical system
functionality
cost
time
• Desired system:– Truly supportive
– Highly flexible
– Sometimes right
– Affordable
– Very limited functionality
– Inflexible
– Always wrong
– Very expensive
functionality
cost
1968 now
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 developmentin 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 problemsor– Architecture will have been obscured by yet another fad
top related