E-Learning Framework

1. E-Learning Framework Tish Roberts

2. MLEs – experience JISC work in MLE development has shown • very bespoke, institutional specific, • Battle of giant system (VLE, LMS, SRS ) duplication of functionality • Complicated and expensive • Very limited transfer of development outcomes • lack of pedagogical flexibility and innovation in the design of e-learning tools, environments and architectures.

3. What we would like • Interoperability of mission critical system • Flexible solutions that can be suited to individual institutions • Integration that is affordable and repeatable • R&D outcomes that can be shared outside of their incubator projects

4. Framework Approach • Breaks MLE function into smaller components call ‘services’ • Organise into layer model, dependant on service they offer (Service Orientated Architecture ) • Use ‘web services’ and open standards to integrate components

5. ELF Today

6. Learning Domain services • Functions that at the moment seem unique to the L&T domain • Each function expressed as a service analysis, with links to specification and R&D activity • Eventually, each service will have toolkits, specifications and implementation patterns

7. Common Services • Functions that at this time seem to be shared by other domains, such as IT services, information environment, and e-science • Effort may be lead by the e-learning sector, follow efforts lead by other sectors, or investigate in collaboration

8. Open the Box • Definition of function • Specification, standards and application profiles • Open source toolkits and tools • Reference models that use it • System and application that implement it • Maturity model – state of adoption

9. Development Approach • Why Service Oriented ? • Why component based ? • Why open Standards ? • Why Open Source ?

10. Why Service Oriented ? • other major vendors also adopting the SOA/Web Services approach (Microsoft, SAP, IBM, Oracle, Sun, etc) • Builds on work of others ADL/Carnegie-Mellon, Sun/UKeU, MIT/OKI, the IMS Framework • development of Web technologies and standards, (HTTP and XML) support cross-organisational interoperability • development of Web service specifications (SOAP, WSDL, UDDI, WS Security, et al)

11. Why component based As development project deliverables are ‘context free’ at the technical level, • it is easier for diverse users to integrate these into their environment • which aids in achieving sustainable outcomes • Each small component development represents a smaller risk • Each application can be smaller and more focused on its unique aspects • Each development effort becomes a cumulative contribution to a coherent whole,

12. Why Open standards Agree unified set of standards • Support interoperability • Minimise integration costs • Service components more widely usable • Mix commercial, in-house and open source systems • Open, component service specifications allow services to be selected, tailored and mixed according to needs and budget

13. Why Open Source Open reference implementations accelerate adoption Build on other development work Sustainability model

14. International development Who –The Australian Department of Education, Science and Training (DEST) • Industry Canada • Digital Library Foundation USA • Carnegie Mellon Learning System Architecture Lab. Why –Interoperability has to be at an international level -Too much for one to do -Validation of framework - Level more out of development investment, • Share technical expertise, What • Formalise partnership • Stewardship model - manage change control

15. Expanding and Opening up the Framework • Applying the service oriented approach, principles and methodology of the ELF to the technical infrastructure requirements of the other constituent communities of JISC and DEST; • Broadening the perception of THE Framework from a service factoring and definition focus to include strategy and deployment perspectives; • Encouraging community participation in development and definition of THE Framework; • Over time, expanding collaboration in THE Framework to other Partners.

16. stewardship model Why a stewardship model, • To provide stability • Give those interested confidence to contribute • Open community participation processes • Backing of international partnership, • System for conflict resolution • Clearly define the roles and responsibilities developing and maintaining THE Framework

17. Stewardship Model

18. 3 aspects (Faces )of the Framework • Strategic tool • Definitions • Deployment

19. Strategic Tool Who – Policy Makers at institutional, regional, national and international level. Goal – Coat effective flexible diversity – ROI, efficiency gains by linking processes, plug and play, new synergies , configurations to match objective and priorities. What - Co-ordination and joint planning tool, that can be used to produce ‘roadmaps’

20. 1st face of the Framework - Strategic Tool How – Presents coherent view of complex space by providing shared context, vocabulary and methodology to map the terrain Which can be use to :- • Facilitate conversations aiming to co-ordinate and harmonise ICT infrastructure development activities • Communication tool that tracks and structures development and technical policy • Support planning and prioritisation of development activities, by • Identifying gaps and collaboration points, • prioritise investment in standards development, • container for reference and resources (eg, open standard based service and tools.)

21. In a JISC context this means • Co-ordination with other national & international funding bodies • Planning tool for JISC Programmes • Focuses Framework development on current policy areas by • mapping key JISC activities to the Framework • development projects fill out the Framework over time • Framework provides coherence to the JISC Development Strategy • while making it easier to switch emphasis as needed • without losing the benefits of earlier efforts

22. Realising Intentions THE Framework realises these strategic intentions by • Suppling guidance and a set of resources (Definitions) • Supporting the use of the framework to design, develop and implement (Deployment)

23. Face 2 – agreed Definitions, and vocabulary Who – Domain experts, development communities, system and software designers, developers and implementers What – a broad vocabulary that is used to model recurring concepts and integration environments How- by providing The principle of service oriented approach A ‘Palette of Service’ - an initial service-oriented factoring of the core services required to support education and research Defined vocabularies – Framework, Reference model, Design, Artifact ?

24. Service interface definitions Service interface definitions that include:- • Standards, specifications and application profiles • Definition of scope and purpose articulated in: • scenarios and use cases • business requirements and business processes • abstract UML service definitions including behaviour and date representation • Implementation bindings for the service interfaces

25. Models - Navigating the complexity Reference models for particular usage eg- • creating,exchanging and re-using content, • e-portfolio and assesment, • linking repositories, • collaborative working • define high level user requirements and functions, • together with component service need to support them Models to enable contextual understanding of the Framework and development of the palette of services. Eg :- • Community based views • Business Process view - functional grouping of service • Etc

26. 3rd Face Deployment Who –implementers, anybody who want to Deploy and use the toolkits, tools, reference models, resources. Set of resources to supporting the institutions and individuals design, develop and implement system their meet their organisational context, objectivies and prorities.

27. 3rd Aspect Deployment • Reference models that identifies national context that effect deployment decisions (ie national specific or mandated standards ) • Profiles of sets of services; technical interfaces, components etc. (? Defin ) • Reference set of services, tools, applications, and integration toolkits • Working examples / case studies • Supporting ‘how to’ documentation

28. What these mean to institutions Build on existing ‘monolithic’ legacy systems Don’t throw away investment in existing systems … add Web Service interfaces to them • Develop incrementally • Start in the area of greatest need • Adaptable, extensible environment • According to size, priorities and budget • In a rapidly changing field • Driven by business processes, • services are aligned with business processes and support the business model. Analysis of the business processes determine what services are needed rather than the services in the framework defining what processes are implemented.

29. The Framework Potential not Actual Need to populate the boxes THE Framework is a dynamic, living, constantly evolving set of resources and tools.