390 likes | 479 Views
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
E N D
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 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
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
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
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
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
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
Components to Services • In a service- based architecture: • Acquire • Use • Disengage • Demand led • Ultra late binding • Core idea. SaaS
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?
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
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..)
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.
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
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
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.
Results • User analysis and requirement • InformalSaaS Architecture • Two case studies on publish/find • NOT yet multi-disciplinary team
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?
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?
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.
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
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
END See:..www.service-oriented.com keith.bennett@durham.ac.uk
Acknowledgements Keele: David Budgen, Pearl Brereton UMIST: Paul Layzell, Nic Gold, Linda Macauley Durham: Malcolm Munro, Jie Xu Funding: EPSRC, BT, Leverhulme
Plan of talk PROBLEM SOLUTION Problem domain Service architecture Service demonstrator Problem definition Method CACM paper NOW APSEC paper
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
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
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.
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
Future: Software as a Service Customer Inland Revenue SAGE Competition.com BT Service-provider.co.uk (SME) IBM Vision = instant service ICL
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
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
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