Slide Title Slide Title by leader6

VIEWS: 8 PAGES: 31

									                                      Slide Title


  Presenter Details




Joint Information Systems Committee        27/05/2012 | | 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                          27/05/2012 | | 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                  27/05/2012 | | 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                               27/05/2012 | | 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                27/05/2012 | | 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                 27/05/2012 | | 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                 27/05/2012 | | 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               27/05/2012 | | Slide 8
                                                                                                                      An Innovation Matrix
                                                                                    Practice / Software Innovation Matrix


                                                                       High
            (also Business Models / Markets)



                                               Practices / Processes


                                                                                           Semi-Radical             Radical
                                                                       innovation




                                                                                           Incremental            Semi-Radical
                                                                       Low




                                                                                     Low             innovation                  High
                                                                                               Technology
                                                                                               (Software / Services)
Joint Information Systems Committee                                                                                                     27/05/2012 | | 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                    27/05/2012 | | Slide 10
                                                               Technology Adoption Life-Cycle

  Marketing Hi-Tech                                                                       Supported through its
                                                          Main Street
   Discontinuous                                                                              lifecycle by
     Innovation                                                                              Incremental
                                                                                             Innovations

                          Tornado



                                                                                                Assimilated

       Early Market




Technology Visionaries                 Pragmatists                      Conservatives                 Skeptics
Enthusiasts (Early Adopters)           (Early Majority)                 (Late Majority)               (Laggards)
(Innovators)

 Joint Information Systems Committee                                                                27/05/2012 | | Slide 11
                                                            The CHASM… and Sustainability

  What should JISC                                        Main Street               ...to get successful
  Development do…                                                                       Pilots across?




                          Tornado

                  into the
                  CHASM                                                                    Assimilated

       Early Market




Technology Visionaries                 Pragmatists                      Conservatives            Skeptics
Enthusiasts (Early Adopters)           (Early Majority)                 (Late Majority)          (Laggards)
(Innovators)

 Joint Information Systems Committee                                                           27/05/2012 | | 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                        27/05/2012 | | 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                                                 27/05/2012 | | 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                     27/05/2012 | | 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                          27/05/2012 | | 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                               27/05/2012 | | Slide 17
                                                                         Process Models

                          Domain
                                                 Learner / Teacher /
                                                    Researcher
                                                       Need



                                      Learning/Teaching/Research/… Process




                        User’s Computer          User’s Computer       User’s Computer

                             Use Case 1              Use Case 2           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                                                      27/05/2012 | | 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                                                                27/05/2012 | | 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.
         ’Orchestration’ standards set of services a ‘Service Usage Model’.
  The e-F calls a coordinated are emerging for creating ‘composite services’.
  Joint Information Systems Committee                                               27/05/2012 | | 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                      27/05/2012 | | Slide 21
                                                           Domain Maps & Models

               Domain Model
               Workflow (Practice Layer or Models
               Application Specific& Process)Model (formal)
                     Domain Map (informal)
                Service Usage Model
               (Human + Systems) Domain Context
                As-Is & To-Be                  Model
                                              Internal
                                                  User                     SUM
                      Workflow/ProcessPractice   Models
                           Workflow/Process Models
                                              Service
                                                Interface              Domain
                                                                       Description
                     (Human + Systems)
                          (Human + Systems)
                                          Co-ordination
                                             Description              Process-specific
                                                                     Information
                                                                            and
                    StakeholderTo-Be Orchestration
                       As-Is & & To-Be / Model
                             As-Is             Goal &               Information Model
                                                                         Model
                                                                         Use Case
                            &                Function
                                           Choreography
                    Project
                   Role Models                Application
                                              Models
                     Case
                     Application                 Specific
                          Application                                   Domain
                           application specific Functions
                    Studies application specific software, service coordination)
                     (UI, (UI,                  software, service coordination)
                                                                          Service
                                             Services                  System
                                            Scenarios
                                                Process
                                                Used
                                                                          Use
                                                                         ModelCase
                                                                        Use Cases
                        Service             (Workflow
                                                 Service
                                                 Model                   Service
                                                                            Model
                     Service Usage Model
                      Consumer             Narratives)
                                               Consumer                Consumer
                        set of services organised and coordinated
                     (aInterface                Interface               Interface
                     to provide an function within an application)

Joint Information Systems Committee                                           27/05/2012 | | Slide 22
                                                    Learning Design

               Application Specific Layer

                                          User
                                        Interface


                                        Learning
                                         Design
                                         Engine



                              Service   Service      Service



Joint Information Systems Committee                            27/05/2012 | | 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             27/05/2012 | | 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                27/05/2012 | | 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                                 27/05/2012 | | 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                              27/05/2012 | | 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                       27/05/2012 | | 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                    27/05/2012 | | 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                 27/05/2012 | | 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              27/05/2012 | | Slide 31

								
To top