Transcript Slide Title - DSpace at Open Universiteit: Home

Slide Title
Presenter Details
Joint Information Systems Committee
16/07/2015 | | Slide 1
Funding bodies' concerns
 Funders think they want you to follow the agreed workplan
– But following a tight workplan doesn't fit innovation
• If you know what you are going to deliver, it's a
production project, not an innovation project
 Funders want to make a worthwhile difference
 How do you know?
– Benchmark and change? - difficult
– What you provide is being used to good effect before the
end of the project…
“This was taken up and used”
Joint Information Systems Committee
16/07/2015 | | Slide 2
Invention vs Innovation
 “Invention” is the production of something different
 “Innovation” is the adoption of an invention to make a
difference in the way things are done
 So innovation is “a difference that makes a difference”
– Gregory Bateson's definition of meaning
 Innovation necessarily has an aspect of effective use
 ... and is a function of social change
Joint Information Systems Committee
16/07/2015 | | Slide 3
Disruptive and incremental innovation
Clayton Christensen: The Innovators Dilemma
Companies do all the right things:
– Find out what their customers want
– Carry out the R&D needed
– Rapidly bring the new product to market
– Maintain good value for money
... and still get nixed by an upstart
... with a disruptive innovation
Joint Information Systems Committee
16/07/2015 | | Slide 4
Why?
 Disruptive technologies start beneath the radar
 They attract a market not being served
– Cheaper, but less functional
– More convenient/ quicker/ easier to use
 But has superior development potential
 Ignored while its technology and support infrastructure
evolves
 Successful companies have well developed filters for
screening out R&D outputs that don't enhance their market
position
 By the time disrupted incumbent market leader wakes up…
it's too late!
Joint Information Systems Committee
16/07/2015 | | Slide 5
Informal Learning is Potentially a Disruptive Technology
 It appears beneath the radar
 It doesn't award degrees or other qualifications
 Typically ad hoc and short
 Cheap = flaky business model =
"It's not a competitor"
 The lightweight technology and supporting
infrastructure significantly lower costs
 Just in time – convenient & used straight away
Joint Information Systems Committee
16/07/2015 | | Slide 6
Informal Learning is Potentially a Disruptive Technology
 Resources, activities and support can be found
when needed
 Find others wanting the same thing at the same
time
 But technology increases in capability and reduces
in cost
 Incumbents are ignoring informal learning
 ... and they are locking out the technology it uses
Joint Information Systems Committee
16/07/2015 | | Slide 7
Cycles of Innovation
1. Disruptive innovation
2. A series of incremental innovations
strengthen it
3. Reaches the end of its 'improvability’
4. … but probably disrupted already
Joint Information Systems Committee
16/07/2015 | | Slide 8
An Innovation Matrix
Radical
Incremental
Semi-Radical
innovation
Semi-Radical
Low
Practices / Processes
(also Business Models / Markets)
High
Practice / Software Innovation Matrix
Low
innovation
High
Technology
(Software / Services)
Joint Information Systems Committee
16/07/2015 | | Slide 9
Addressing the Dilemma
 Disruptive developments have to be separated off
organisationally to survive
 ... but still 'available‘ (maybe to the owners of the company)
Joint Information Systems Committee
16/07/2015 | | Slide 10
Technology Adoption Life-Cycle
Marketing Hi-Tech
Discontinuous
Innovation
Supported through its
lifecycle by
Main Street
Incremental
Innovations
Tornado
Assimilated
Early Market
Technology Visionaries
Enthusiasts (Early Adopters)
(Innovators)
Joint Information Systems Committee
Pragmatists
(Early Majority)
Conservatives
(Late Majority)
Skeptics
(Laggards)
16/07/2015 | | Slide 11
The CHASM… and Sustainability
What should JISC
Development do…
Main Street
...to get successful
Pilots across?
Tornado
into the
CHASM
Assimilated
Early Market
Technology Visionaries
Enthusiasts (Early Adopters)
(Innovators)
Joint Information Systems Committee
Pragmatists
(Early Majority)
Conservatives
(Late Majority)
Skeptics
(Laggards)
16/07/2015 | | Slide 12
Technology Adoption Lifecycle
Is this why many funded technology projects
fail?
What must be done to cross the Chasm?
Organisations need to know it is valuable
Then they will cover the costs of maintaining it
... whether through commercial or open
source channels
Joint Information Systems Committee
16/07/2015 | | Slide 13
IDEO’s Rough Innovation Pattern
Identify
Problem /
Opportunity
Closely
Observe
(ethnography)
Brainstorm
Solutions
Rapid
Prototyping
(observe use)
Trial / Pilot
fully-working
Prototype
Production
& Continue
to Observe!
Joint Information Systems Committee
16/07/2015 | | Slide 14
How Do We Identity Problems?
 Work with existing communities – for JISC these might be:
– UCISA (have Identified Top 10 Issues)
– CETIS SIGs (start from existing Reference Models)
– AUA, HEA Subjects Centres…
 Work with them to Map their Territory
– Start Rough and get Approximate ‘Big Picture’
– Fill in Detail over Time to Evolve Models
 Reflect on the Map
– Identify Problem Areas
– Agree Priorities
– Study Problems in the Real World
Joint Information Systems Committee
16/07/2015 | | Slide 15
Applying this in the e-Framework
 Technical development takes place in a vacuum
 There is always a human context
 A key aspect of the SOA approach is seeking to link ICT
services to human tasks and context of use
 In JISC e-Learning Programmes this has been done through
– Reference Models
– Service Adapter Toolkits
– Demonstrators
– Pilots
Joint Information Systems Committee
16/07/2015 | | Slide 16
From Reference Modelling to Domain Mapping
 The-Learning Reference Models have now completed
 They have produced very useful resources as a starting point
for any development project in their domain
 But “Reference Model” has narrower, normative associations
 Seeking reusable Domain Knowledge, that is relatively stable
 This forms the basis for Community to:
• Identify and agree Key Problem Areas
• Collaborate with Developers (open source or commercial)
in Co-evolving Practices, Processes & Software
• Ensure Coherence across their ‘Family’ of Applications
• Save re-doing the same work (differently) each time
Joint Information Systems Committee
16/07/2015 | | Slide 17
Process Models
Domain
Learner / Teacher /
Researcher
Need
Learning/Teaching/Research/… Process
User’s Computer
Use Case 1
User’s Computer
Use Case 2
User’s Computer
Use Case 3
Many tasks require several people to work together in a workflow.
In such cases Scenarios & Process Models set this out,
showing how people and computers work together to accomplish the task.
Joint Information Systems Committee
16/07/2015 | | Slide 18
Process Models
Domain
Learning / Teaching / Research /… Process
Lightweight Application
User Interface
Application Specific Functions
Service A Interface
Service B Interface
Service C Interface
Service A Interface
Service B Interface
Service C Interface
Service A
Service B
Service C
Joint Information Systems Committee
16/07/2015 | | Slide 19
Service Usage Models
User’s Computer/Portal
Use Case
‘Orchestration’
Web Service
Service A
Service B
Invoke
Invoke
Typically User Tasks need to call on several services.
Typically User Tasks need to call on several services.
‘Orchestration’ standards are emerging for coordinating a set of services.
The e-F’Orchestration’
calls a coordinated
set emerging
of services
a ‘Service
Usage
Model’.
standards are
for creating
‘composite
services’.
Joint Information Systems Committee
16/07/2015 | | Slide 20
Emerging Tools to Support Process Modelling and Development
 As well as standards to describe processes there is an
emerging standard for graphically displaying processes
 The OMG has developed BPMN 1.0 & now working on v 2
(Business Process Modelling Notation)
 Developers are incorporating it into graphical tools
– To model processes
– To generate executable code
 ICT support becomes flexible, easy to create and change,
rather than set in hard to change system
 The lightweight composite application is easier to create
 Interchange between practice and process becomes easier
Joint Information Systems Committee
16/07/2015 | | Slide 21
Domain Maps & Models
Domain
Model
Workflow
(Practice
&Layer
Process)
Models
Domain
Map
(informal)
or Model
(formal)
Application
Specific
Service
Usage
Model
(Human + Systems) Domain Context
As-Is & To-Be
Model
Internal
SUM
User
Workflow/Process
Models
Workflow/Process
Models
Domain
Service
Practice
Description
Interface
Process-specific
(Human
+ Systems)
(Human
+ Systems)
Information
Co-ordination
Description
and
Stakeholder
Goal
&
Information
Model
Orchestration
As-Is
& To-Be
As-Is
& To-Be
Model
/ Model
Use
Case
Choreography
&
Function
Application
Project
Role
Models
Models
Specific
Case
Application
Application
Domain
Functions
Studies
(UI, (UI,
application
specific
software,
service
coordination)
application specific software, service coordination)
Service
System
Services
Scenarios
Process
Use
Case
Use
Cases
Model
Used
(Workflow
Service
Service
Service
Model
Model
Service
Usage Model
Narratives)
Consumer
Consumer
Consumer
(aInterface
set of services organised
Interfaceand coordinated
Interface
to provide an function within an application)
Joint Information Systems Committee
16/07/2015 | | Slide 22
Learning Design
Application Specific Layer
User
Interface
Learning
Design
Engine
Service
Joint Information Systems Committee
Service
Service
16/07/2015 | | Slide 23
LD “Problems”
 Confusion of LD spec with implementation limitations
– "Too difficult for ordinary teachers"
– "No way of searching and previewing, and hence
of sharing, UoLs"
– "It's too slow and doesn't scale"
– "Cannot change a run after it has started"
 But if don't resolve, can act as Showstoppers
 TEN Competence is taking the lead on this
Joint Information Systems Committee
16/07/2015 | | Slide 24
"Too difficult for ordinary teachers“ – and Learners!
 This is a question of providing usable authoring
interfaces
 Learn from LAMS’ graphical interface
 Authoring used by Teacher with Students to create
Activities
 This would greatly strengthen informal learning
communities
 But LAMS functionality is simpler than LD
 Can we create something as easy as LAMS for LD?
Joint Information Systems Committee
16/07/2015 | | Slide 25
Proposal for “LAMS-alike” Graphical UI
 Draggable LAMS activity =
– LD Activities + LD Environment
– Some fields preset, some open
 Modify an existing editor to produce “LD Components”
 Create small LD components
– Activity + Environment
– Fill in some fields
– Place ??? In editable fields
– In CP Organisation call it LD:Activity or LD:Activity-Structure, etc
– Save with Icon in a Content Package
Joint Information Systems Committee
16/07/2015 | | Slide 26
Proposal for “LAMS-alike” Graphical UI
 Create a separate Graphical editor which:
– Reads in components and puts icons on a palette
– When dragged and dropped, adds element code to UoL
– Linking Activity icons in parallel or sequence creates
Activity structures
– All editable fields, across all LD elements in a component,
are presented in a single pop-up Property Box
– If people don’t like defaults, can go back to the
component editor and change them
Joint Information Systems Committee
16/07/2015 | | Slide 27
The Services Dilemma
 Limited number of explicit services constrains use
 But too many and you can lose interoperability
 … and hard to get approval in standards bodies!
 Can we increase the range of Services that can be used
in LD without losing interoperability (too much)?
 Could we create an ‘open learning service’ element?
– LS Services are open on the LD ‘Roles’ side
– Can they be open also on the Service side?
 What do others do? (How does BPEL handle it?)
Joint Information Systems Committee
16/07/2015 | | Slide 28
Finding Services
 Two ways:
1. Downloadable for local use
 Open source
 Commercial (pay for download)
2. Available as an online service
 Free
 Commercial (pay for use)
 Need to be able to include references for one or both of
these in a generic LD Service element
Joint Information Systems Committee
16/07/2015 | | Slide 29
Talking to Services
 Run time communication between LD Engine & Service
needed:
1. At set up time
2. At launch of service
3. On completion of use
4. During use
 1. needs special handling
 2. & 3. can probably be handled using existing property
mechanisms in LD but need to define service interface
 4. Is more complex and being explored by LAMS
Joint Information Systems Committee
16/07/2015 | | Slide 30
The Future of LD
 LD has a key role to play in the integration of
services into learning flows
 LD learning flows parallel developments in process
support
 Usability is a key issue
 Engage those who already need informal learning
 Work with them iteratively to create usable
systems
Joint Information Systems Committee
16/07/2015 | | Slide 31