The Future of Software Architecture Maarten Boasson Universiteit

The Future of Software Architecture Maarten Boasson Universiteit van Amsterdam Quærendo Invenietis bv mb@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 1968 now time

Typical system • cost functionality Desired system: – Very Truly limited supportive functionality – Inflexible Highly flexible – Always Sometimes wrong right – Very Affordable 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