1. Architecture Session Discussion Marseilles September 1999 John Harvey CERN / LHCb

2. Introduction to Architecture Session, Marseilles, September 1999 Slide 2 Technical Forum qContinue to promote discussion between interested parties qContinue to learn from others experience - successes and failures qDocument this experience and make information widely available qPromote the notion that every software production unit should appoint an architect qAll architects would be encouraged to participate in this forum

3. Introduction to Architecture Session, Marseilles, September 1999 Slide 3 Architectural Guidelines qEstablish a set of guidelines for architects to follow…examples could be ãcomponents should be orthogonal to each other i.e. use of a particular histogramming component should not imply use of a particular visualisation component ãunderlying model for interfaces ãsuggestions on packaging i.e. physical design ãdocument architectural design patterns that experiments are using qImportant to agree to adhere to these guidelines to avoid problems that can be anticipated in advance

4. Introduction to Architecture Session, Marseilles, September 1999 Slide 4 OO Design Patterns qDocument OO design patterns that have been used for building typical HEP algorithms e.g. track finding qPull out experience from existing experiments such as BaBar, CDF, D0… qDocument those patterns that did not work as well qInformation needs to be well distilled qSpawn another technical forum? qTheme for a parallel session at CHEP?

5. Introduction to Architecture Session, Marseilles, September 1999 Slide 5 Java qCreate a study group to assess the impact of Java ãconsolidate on experience we have gained so far e.g. JAS, WIRED... ãassess suitability through realistic prototypes e.g. track reconstruction ãstudy problems of mixing with other languages ãstudy interfacing with other frameworks like GEANT4 ãif outcome of studies positive, plan for HEP-wide Java library

6. Introduction to Architecture Session, Marseilles, September 1999 Slide 6 I) Framework Worries - seems to be too intricate - modularity is often not evident - serious issue is that modifications to code are difficult to make if they were not foreseen from the beginning Q1: What helps to give an architecture and a framework an understandable and easy to use interface? Q2: Why do people find making changes difficult?

7. Introduction to Architecture Session, Marseilles, September 1999 Slide 7 2) Performance Worries - performance is a fundamental requirement for our data processing needs and the OO approach results in overheads which impairs performance Q1: Does an architecture force compromises to performance? Q2: Is there a trade-off between quality and maintainability on the one hand and performance on the other and if so what performance penalty is acceptable? Q3: Are there real examples which demonstrate penalties (or benefits) to performance?

8. Introduction to Architecture Session, Marseilles, September 1999 Slide 8 3) Migration Worries - a change to OO does not allow an adiabatic change from existing software - all existing investment in FORTRAN code is lost - the best programming method should be used to execute a given task (e.g. languages close to mathematical reasoning for certain algorithms) Q1: How can an architecture/framework help in the migration to OO? Q2: Are there examples where this has been managed successfully?

9. Introduction to Architecture Session, Marseilles, September 1999 Slide 9 4) Language Worries - C++ is heavy to use and leads to nasty problems which are difficult to debug (e.g. memory leaks) - several years experience are needed and initial developments have to be redone from scratch - the complexity of C++ is not needed and a mature C++ code is often difficult to understand Q1: Do these problems stem from an absence of architecture/framework? Q2: Is C++ an appropriate language, or is it a system programmer's language? Q3: Are we doing enough to investigate the use of other languages such as Java?

10. Introduction to Architecture Session, Marseilles, September 1999 Slide 10 5) Participation Worries - many skills and too much time is spent on solving mundane problems such as those related to language, memory management, library management - only a restricted number of people can participate effectively Q1: Can an architecture help to identify areas where physicists contribute? Q2: What skills does an algorithm developer need to have to contribute effectively?

11. Introduction to Architecture Session, Marseilles, September 1999 Slide 11 6) Collaboration Worries - reuse does not seem to work in practice Q1: How can an architectural vision help us to be more efficient in the production of code? Q2: Should we be trying to agree on integration standards and are we doing enough to develop standard HEP libraries that we can all share?