seisn 2001 1 software as a service - an example of interdisciplinary research keith bennett...
TRANSCRIPT
1
SEISN 2001
Software as a Service - an example of interdisciplinary
research
Keith BennettUniversity of Durham
2
SEISN 2001
Pennine Research Group
• UMIST, Manchester• University of Keele• University of Durham
3
SEISN 2001
2001
2nd case Study ICSM2001
1st. Case studyCOMPSAC 2001
ArchitectureAPSEC 2000
RequirementsCACM 1999
IBHISproject
ISENNetwork
SEBPCprogramme
SEISNnetwork
FEAST
DurhamMaintenanceKeele
Design & componentsUMISTSW management
BT
DiCE
1996
Industry
Etc.
4
SEISN 2001
Preamble
5
SEISN 2001
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
SEISN 2001
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
SEISN 2001
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
SEISN 2001
Requirements
9
SEISN 2001
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
SEISN 2001
Ambition
2000 2001 2002 2003 2004 2005 2006
0
x100
year
x10
Vision: Software as a Service
Software as Product
x50
SpeedTime toMkt
11
SEISN 2001
The key idea
12
SEISN 2001
Components to Services
• In a service- based architecture:– Acquire– Use– Disengage
• Demand led
• Ultra late binding
• Core idea. SaaS
13
SEISN 2001
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
SEISN 2001
Ownership -> Service
• Software will remain basically rigid• Organisations & marketplaces
are adaptable• Ownership is the problem. Users
just want to USE software to get RESULTS.
• Combine service and marketplace
15
SEISN 2001
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
SEISN 2001
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
SEISN 2001
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
SEISN 2001
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
SEISN 2001
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
SEISN 2001
Results to date
21
SEISN 2001
Results
• User analysis and requirement
• Informal SaaS Architecture
• Two case studies on publish/find
• NOT yet multi-disciplinary team
22
SEISN 2001
Conclusions
23
SEISN 2001
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
SEISN 2001
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
SEISN 2001
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
SEISN 2001
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
SEISN 2001
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
29
SEISN 2001
end
30
SEISN 2001
Acknowledgements
Keele: David Budgen, Pearl Brereton
UMIST: Paul Layzell, Nic Gold, Linda Macauley
Durham: Malcolm Munro, Jie Xu
Funding: EPSRC, BT, Leverhulme
31
SEISN 2001
Plan of talk
Problemdomain
Problem
definition
PROBLEM SOLUTION
Service architecture
Servicedemonstrator
MethodCACM paper
APSEC paper NOW
32
SEISN 2001Project Philosophy
Interdisciplinaryteams across universities,industry
UK and internationalvisitors, industrialsecondments
Partnerships withindustry, access toSMEs, user engagement,spin-outs, technologytransfer, domains
Interdisciplinary Inclusive
Outward facing Research themes
Architecture, data,formalisation, evaluation,supply chains
SoftwareAs a
Service
33
SEISN 2001
The UK Software Engineering Enterprise
CoreFunding
ExemplarServiceprovider
Technologytransfer& consultancy
EPSRCcuriosity-drivenresearch
Industrialresearch
StrategicPartnerships
EducationandTraining
IncubationUnits
Spin-offCompanies
Enhanced industrial technologyand increased competitiveness
Educated workforce andIncreased public understanding
New start-ups, innovative marketdevelopment, strengthened UK industrial base
Cohesive software engineering research agenda, re-engaged with users
Partnership benefits to major suppliers and SMEs through the software service supply chain
Wealth generation
34
SEISN 2001
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
SEISN 2001
Today: Software is a Product“If the seal is broken, the guarantee is void”
Payroll
Recordhours
Calculatepay
Checklegislation
Recharge tocost centres
Producepayslips
Transfermoney
Print slips
36
SEISN 2001
Future: Software as a Service
Vision = instant service
Customer
Inland Revenue
BT
Service-provider.co.uk
(SME)
SAGE
IBMICL
Competition.com
37
SEISN 2001
SoftwareLicences and
ownership
Responsibilitiesprior to use
System failurerecovery and
redress
Organisationalprocedures and
impact
Personalisationand
configurationPrivacy,
protectionand security
Performancecriteria
Payment termsand conditions
The Business of Software
38
SEISN 2001
Serviceware Payment terms
and conditions
Personalisationand configuration
Privacy, protectionand security
Performance criteria
Binding
System failurerecovery and
redress
Responsibilitiesprior to use
Trust and confidence
Software
39
SEISN 2001
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