The Future of Software Architecture

1. The Future of Software Architecture Maarten Boasson Universiteit van Amsterdam Quærendo Invenietis bv mb@quaerendo.com

2. 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

3. 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

4. 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

5. 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

6. … 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

7. We don’t know what we are doing

8. Typical system functionality time now 1968

9. Typical system cost • Desired system: • Truly supportive • Highly flexible • Sometimes right • Affordable • Very limited functionality • Inflexible • Always wrong • Very expensive functionality functionality cost time now 1968

10. 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).

11. Examples of bad software FAA Air Traffic Control Windows Cockpit blackouts in 747 http://catless.ncl.ac.uk/Risks

12. 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!

13. 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

14. 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?

15. Higher education • Education is about learning essential skills and attitudes • Education is not about preparing students for immediate productivity in industry

16. 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, …

17. Fundamental research • Research is about • Understanding • Finding general principles • Research is not solving problems for industry

18. 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?

19. 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

20. 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!”

21. 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?

22. 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

23. 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