1 / 39

Software as a Service - an example of interdisciplinary research

Software as a Service - an example of interdisciplinary research. Keith Bennett University of Durham keith.bennett@durham.ac.uk. Pennine Research Group. UMIST, Manchester University of Keele University of Durham. DiCE. Durham Maintenance. IBHIS project. ISEN Network. Keele

zeke
Download Presentation

Software as a Service - an example of interdisciplinary research

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software as a Service - an example of interdisciplinary research Keith Bennett University of Durham keith.bennett@durham.ac.uk

  2. Pennine Research Group • UMIST, Manchester • University of Keele • University of Durham

  3. DiCE Durham Maintenance IBHIS project ISEN Network Keele Design & components UMIST SW management BT Etc. 2001 1996 Requirements CACM 1999 SEBPC programme 2nd case Study ICSM2001 1st. Case study COMPSAC 2001 SEISN network Architecture APSEC 2000 Industry FEAST

  4. Preamble

  5. Changing Nature of Business • 40% of Fortune 500 companies in 1979 are no longer corporate entities • 30% of firms under 10 employees generate 70% of EU turnover • Competitiveness through time to market is major driver

  6. Distinctive Domains • Systems Domain • Well defined boundaries and requirements • Business Domain • Emergent Organisations • “Organisations in a state of continual process change, never arriving, always in transition” D. Truex, R.Baskeville and H.Klein, “Growing Systems in Emergent Organizations”, Comm.ACM, Vol.42, No.8, August 1999

  7. Coping with Evolution • 60-80% of lifetime costs of software relate to change • Evolution technologies • Program comprehension, re-engineering, reverse engineering and design recovery • Design for maintainability – v. hard

  8. Requirements

  9. Key User Drivers • Necessary and sufficient capability • Personalisation for each user • Adaptable/ self-adaptation to changes • Distribution and granularity (small & simple) • Transparency (to location, faults etc.) • P.Brereton, D.Budgen, K.Bennett, M.Munro, P.Layzell, L.Macaulay, D.Griffiths and C.Stannett, “The Future of Software: Defining the Research Agenda”, Comm. ACM, Vol.42, No.12, December 1999

  10. Ambition x100 Vision: Software as a Service Speed Time to Mkt x50 Software as Product x10 0 year 2000 2001 2002 2003 2004 2005 2006

  11. The key idea

  12. Components to Services • In a service- based architecture: • Acquire • Use • Disengage • Demand led • Ultra late binding • Core idea. SaaS

  13. FAQs • Is this not Netscape plug-ins or .NET? • Why does this speed up evolution? • What is new? • What is significant? • What about security etc? • Doesn’t this give poor quality?

  14. Ownership -> Service • Software will remain basically rigid • Organisations & marketplacesare adaptable • Ownership is the problem. Users just want to USE software to get RESULTS. • Combine service and marketplace

  15. Software • Software moves from a PRODUCT to a SERVICE. • A SERVICE is something you find, use as and when needed – and then discard. • The user decides what services are needed, and the technology negotiates, agrees and implements their binding, which involves many non-technical attributes (trust, cost, redress..)

  16. Service • An E-service represents a self contained internet based application, capable of completing tasks on its own, and able to discover and engage other E-services to complete higher level transactions. • Engagement = functional and non functional properties.

  17. Software as a Service • NOW • Mass maintenance • Rental, Pay per use • Web based software update • Jini type service lookup, UDDI • Device level services • ebXML, Crossflow, TPAML, e-Speak etc • This doesn’t solve terms & conditions

  18. Vision of Service • At the time of need we locate and then ‘bind’ (connect) to a service or services we need from the marketplace • When we have finished use, we discard the service. Tomorrow we’ll have moved on. We’ll form new bindings. Hence EVOLUTION • Bindings are both technical and non technical – and the latter are HARD

  19. Summary • We solve ultra rapid evolution, not by a magic bullet, but by using the well proven mechanisms of the market and adapting them to software for emergent organisations. • Markets don’t just respond – they anticipate and plan.

  20. Results to date

  21. Results • User analysis and requirement • InformalSaaS Architecture • Two case studies on publish/find • NOT yet multi-disciplinary team

  22. Conclusions

  23. Research Issues 1 • How do consumers know what services are available? • How do consumers express their requirements? • How are services composed and evaluated? • How are services tested? • What is the appropriate, high integrity, service delivery infrastructure? • How must consumers’ data be held to enable portability between different service suppliers?

  24. Research Issues 2 • What standards can be used or must be defined to enable portability of service? • What will be the impact of branded services and marketing activities high quality v low price? • How can organisations benefit from rapidly changing services and how will they manage the interface with business processes? • How will individuals perceive and manage rapidly changing systems? What is the limit to the speed of change? • What payment and reward structures will be necessary to encourage SME service suppliers? • What will be the new industry models and supply chain arrangements?

  25. Multidisciplinary Research • Multidisciplinarity = the use of knowledge, models and skills from outside the IT domain. However multidisciplinary research is only truly interdisciplinary when driven by a unified need to achieve a common goal, in this case to model software as a service, and then it provides the opportunity of bringing together, academics and industrialists from a range of disciplines with a common objective.

  26. Conclusion • Long term software engineering research and innovation is a multidisciplinary activity • SEISN has been very successful in • better mutual understanding of SE and IS, and extrapolation to other fields e.g. law • Research process • Win/win collaborative research

  27. Acknowledgements • EPSRC, BT and Leverhulme Trust • Colleagues and co-authors at Keele, UMIST, Durham • David Budgen, Pearl Brereton • Paul Layzell, Linda Macauley, Nicolas Gold • Malcolm Munro, Jie Xu

  28. END See:..www.service-oriented.com keith.bennett@durham.ac.uk

  29. end

  30. Acknowledgements Keele: David Budgen, Pearl Brereton UMIST: Paul Layzell, Nic Gold, Linda Macauley Durham: Malcolm Munro, Jie Xu Funding: EPSRC, BT, Leverhulme

  31. Plan of talk PROBLEM SOLUTION Problem domain Service architecture Service demonstrator Problem definition Method CACM paper NOW APSEC paper

  32. Project Philosophy Interdisciplinary Inclusive Interdisciplinary teams across universities, industry UK and international visitors, industrial secondments Software As a Service Outwardfacing Research themes Partnerships with industry, access to SMEs, user engagement, spin-outs, technology transfer, domains Architecture, data, formalisation, evaluation, supply chains

  33. The UK Software Engineering Enterprise Cohesive software engineering research agenda, re-engaged with users Wealth generation EPSRC curiosity- driven research Exemplar Service provider Strategic Partnerships Incubation Units New start-ups, innovative market development, strengthened UK industrial base Partnership benefits to major suppliers and SMEs through the software service supply chain Core Funding Spin-off Companies Industrial research Technology transfer & consultancy Education and Training Educated workforce and Increased public understanding Enhanced industrial technology and increased competitiveness

  34. Strategic issue • Not a technical issue • High profile company problems • Headlines in FT, shareholder return disasters • Board level problem • A few recent headline examples • Strategic: research needs to help those at top level in companies, many of which are ever more IT businesses.

  35. Record hours Today: Software is a Product “If the seal is broken, the guarantee is void” Payroll Produce payslips Calculatepay Check legislation Recharge to cost centres Transfer money Print slips

  36. Future: Software as a Service Customer Inland Revenue SAGE Competition.com BT Service-provider.co.uk (SME) IBM Vision = instant service ICL

  37. Payment terms and conditions Personalisationandconfiguration Privacy,protection and security Performance criteria Licences and ownership Organisational procedures and impact Responsibilities prior to use System failure recovery and redress The Business of Software Software

  38. Serviceware Payment terms and conditions Trust and confidence Personalisation and configuration Responsibilities prior to use Software System failure recovery and redress Privacy, protection and security Binding Performance criteria

  39. How do we realise this? • Web based demonstrators already exist • EPSRC network Interdisciplinary software engineering • Research grants with industry as uncles and supporters • Case studies with industry • Direct sponsorship of research by industry • Transition routes for industry

More Related