eFramework Presentation MinEd Bill Olivier


Published on

Presentation by Bill Olivier at eFramework meeting Oslo 26012007

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • eFramework Presentation MinEd Bill Olivier

    1. 1. <ul><li>The e-Framework for Education & Research </li></ul><ul><li>an Overview </li></ul><ul><li>Ministry of Education, Norway 25 Jan 2007 </li></ul><ul><li>Bill Olivier, JISC </li></ul>
    2. 2. The e-learning framework <ul><li>Started in 2003 </li></ul><ul><li>Emerged from JISC’s work on virtual learning environments and managed learning environments </li></ul><ul><li>Attempt to address various problems by using service oriented approaches </li></ul>
    3. 3. The challenges: silos <ul><li>Core data and functionality are locked up in individual applications . </li></ul><ul><ul><li>Monolithic applications duplicate functionality. </li></ul></ul><ul><ul><li>Difficult to customise systems to meet diverse requirements </li></ul></ul><ul><ul><li>Legacy systems (& integration) costly to replace </li></ul></ul><ul><li>Result: obstacles to deliver users with: </li></ul><ul><ul><li>The right information </li></ul></ul><ul><ul><li>At the right time </li></ul></ul><ul><ul><li>In a familiar environment </li></ul></ul>
    4. 4. The challenges: lack of co-ordination <ul><li>In isolation, different communities and different domains: </li></ul><ul><ul><li>duplicate effort </li></ul></ul><ul><ul><li>solve the same problem in incompatible ways </li></ul></ul><ul><ul><li>solve different problems in incompatible ways </li></ul></ul><ul><li>Result: </li></ul><ul><ul><li>no network effect </li></ul></ul><ul><ul><li>lost opportunities for synergy </li></ul></ul>
    5. 5. The challenges: isolated innovation <ul><li>New e-learning tools fail to flourish because: </li></ul><ul><ul><li>too many resources are lost solving ‘boring’, known problems </li></ul></ul><ul><ul><li>too many dependencies on unique infrastructures </li></ul></ul><ul><ul><li>too idiosyncratic to be sustainable beyond a particular person or project </li></ul></ul><ul><li>Result: </li></ul><ul><ul><li>poor return on R&D investment </li></ul></ul><ul><ul><li>slow development of new practice </li></ul></ul>
    6. 6. A potential solution <ul><li>Service oriented approach: </li></ul><ul><ul><li>Breaks down common functions into discrete services… </li></ul></ul><ul><ul><li>… used independently of underlying systems, applications and platforms. </li></ul></ul>
    7. 7. E-Learning Framework origins <ul><li>The ELF built on previous work: </li></ul><ul><ul><li>the Open Knowledge Initiative (OKI) and Sakai </li></ul></ul><ul><ul><li>designs by Carnegie-Mellon Learning Systems Architecture Lab </li></ul></ul><ul><ul><li>Sun e-learning platform </li></ul></ul><ul><ul><li>the IMS Abstract Framework </li></ul></ul><ul><ul><li>large number of SOAs from other domains </li></ul></ul>
    8. 8. Take one
    9. 9. Take two
    10. 10. Developing components of the e-learning framework <ul><li>Funded projects during 2004-2006 and ongoing </li></ul><ul><li>Toolkit projects to build web service interfaces </li></ul><ul><li>Demonstrator projects to show how web services can be implemented and used in university or college systems </li></ul><ul><li>Examples </li></ul>
    11. 11. <ul><li>Why the e-Framework? </li></ul><ul><ul><li>Growing awareness that the problem that the ELF was trying to solve was a wider issue </li></ul></ul><ul><ul><li>JISC already using SOA for its Information Environment activity (architecture for digital library resources) </li></ul></ul><ul><ul><li>Same issues and approaches in research area (e-Science and the Grid using Web Services) </li></ul></ul><ul><ul><li>Same issues for administration </li></ul></ul><ul><li>Successful expansion of the ELF to support other domain areas, building on previous activities </li></ul><ul><li>Gained a high level of international interest and enthusiasm to collaborate </li></ul>
    12. 12. What is the e-Framework now? <ul><li>The International e-Framework Initiative </li></ul><ul><ul><li>JISC </li></ul></ul><ul><ul><li>Australian Dept for Education, Sc. & Technology </li></ul></ul><ul><ul><li>SURF in Holland </li></ul></ul><ul><ul><li>New Zealand Ministry of Education </li></ul></ul><ul><li>The e-Framework Knowledge Base/Web site </li></ul><ul><ul><li>Most visible output of the Initiative </li></ul></ul><ul><li>Each Partner’s own e-Framework Programme </li></ul><ul><ul><li>Supports the first two </li></ul></ul><ul><ul><li>Co-operates with other Partners </li></ul></ul><ul><ul><li>Works with its other Programmes to add to & gain from the e-Framework </li></ul></ul>
    13. 13. Sharing Services
    14. 14. Scope <ul><li>The e-Framework context is the communities active in education and research, and the technical infrastructure that supports them. </li></ul><ul><li>(Technical infrastructure is defined as including applications, services and the network.) </li></ul><ul><li>The e-Framework analyses, models & documents USER DOMAINS (goals, tasks, processes, info, etc.) and the supporting SERVICES . </li></ul>
    15. 15. Guiding Principles <ul><li>A service-oriented approach to system and process integration </li></ul><ul><li>Development, promotion and adoption of Open Standards </li></ul><ul><li>Community involvement in development of the e-Framework </li></ul><ul><li>Open collaborative development activities </li></ul><ul><li>Flexible and incremental deployment </li></ul>
    16. 16. Purpose <ul><li>To: </li></ul><ul><li>Provide a strategic approach to technical infrastructure development within and across domains </li></ul><ul><li>Provide a consistent technical vocabulary </li></ul><ul><li>Provide a focal point for interaction with software developers and those providing services to education and research. </li></ul><ul><li>Act as a catalyst for the development of further specifications and standards </li></ul>
    17. 17. Benefits - Partners <ul><li>A map of a complex environment </li></ul><ul><li>A strategic planning tool for </li></ul><ul><ul><li>Prioritised investment in standards </li></ul></ul><ul><ul><li>Prioritised investment in interoperability technologies </li></ul></ul><ul><li>Improved return on investment through coordination and collaboration between Partners </li></ul>
    18. 18. Benefits - Institutions <ul><li>Alignment of strategies and infrastructure development </li></ul><ul><li>More choice of systems and suppliers </li></ul><ul><li>Improved return on investment in existing systems </li></ul><ul><li>More effective communications between communities through shared understanding </li></ul><ul><li>Establishing interoperability within and across institutions and national boundaries </li></ul>
    19. 19. Benefits - Developers <ul><li>Better engagement with, & understanding of, institutions, domain experts and users </li></ul><ul><li>More rapid development cycles through reusable components </li></ul><ul><li>Faster response to new requirements </li></ul><ul><li>Entry of small innovative players into the market </li></ul><ul><li>Communication and collaboration between developers </li></ul><ul><li>Flexible business models for software development </li></ul>
    20. 20. How Do We Identity Problems? <ul><li>Work with existing communities – for JISC these might be </li></ul><ul><ul><li>UCISA (have Identified Top 10 Issues) </li></ul></ul><ul><ul><li>CETIS SIGs (start from existing Reference Models) </li></ul></ul><ul><ul><li>AUA, HEA Subjects Centres… </li></ul></ul><ul><li>Work with them to Map their Territory (Domain Map) </li></ul><ul><ul><li>Start Rough and get Approximate ‘Big Picture’ </li></ul></ul><ul><ul><li>Fill in Detail over Time to Evolve Models (Agile Modelling) </li></ul></ul><ul><li>Reflect on the Map </li></ul><ul><ul><li>Identify Problem Areas </li></ul></ul><ul><ul><li>Agree Priorities </li></ul></ul><ul><ul><li>Study Problems in the Real World </li></ul></ul>
    21. 21. Applying this in the e-Framework <ul><li>Technical development takes place in a vacuum </li></ul><ul><li>There is always a human context </li></ul><ul><li>A key aspect of the SOA approach is seeking to link ICT services to human tasks and context of use </li></ul><ul><li>In JISC e-Learning Programmes this has been done through: </li></ul><ul><ul><li>Reference Models (now Domain & Process Models) </li></ul></ul><ul><ul><li>Service Adapter Toolkits </li></ul></ul><ul><ul><li>Demonstrators </li></ul></ul><ul><ul><li>Pilots </li></ul></ul>
    22. 22. From Reference Modelling to Domain Mapping <ul><li>The-Learning Reference Models have now completed </li></ul><ul><li>They have produced very useful resources as a starting point for any development project in their domain </li></ul><ul><li>But “Reference Model” has narrower, normative associations </li></ul><ul><li>Seeking reusable Domain Knowledge, that is relatively stable </li></ul><ul><li>This forms the basis for Practitioners to: </li></ul><ul><ul><li>Identify and agree Key Problem Areas </li></ul></ul><ul><ul><li>Collaborate with Developers (open source or commercial) in Co-evolving Practices, Processes & Software </li></ul></ul><ul><ul><li>Ensure Coherence across their ‘Family’ of Applications </li></ul></ul><ul><ul><li>Save re-doing the same work (differently) each time </li></ul></ul>
    23. 23. Process Models Domain Learning/Teaching/Research/… Process Learner / Teacher / Researcher Need 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.
    24. 24. Process Models Domain Learning / Teaching / Research /… Process Personal Environment Container with Lightweight Application User Interface Application Specific Functions Service A Interface Service B Interface Service C Interface Service A Interface Service A Service B Interface Service B Service C Interface Service C Hot-download Application Components
    25. 25. Service Usage Models User’s Computer/Portal Use Case ‘ Orchestration’ Web Service Service A Invoke Service B Invoke Typically User Tasks need to call on several services. ’Orchestration’ standards are emerging for creating ‘composite services’. Typically User Tasks need to call on several services. ‘Orchestration’ standards are emerging for coordinating a set of services. The e-F calls a coordinated set of services a ‘Service Usage Model’.
    26. 26. Emerging Tools to Support Process Modelling & Development <ul><li>As well as standards to describe processes there is an emerging standard for graphically displaying processes </li></ul><ul><li>The OMG has developed BPMN 1.0 & now working on v2 (Business Process Modelling Notation) </li></ul><ul><li>Developers are incorporating it into graphical tools </li></ul><ul><ul><li>To model processes </li></ul></ul><ul><ul><li>To generate executable code </li></ul></ul><ul><li>ICT support becomes flexible, easy to create and change, rather than set in hard to change system </li></ul><ul><li>The lightweight composite application is easier to create </li></ul><ul><li>Interchange between practice and process becomes easier </li></ul>
    27. 27. Domain Maps & Models Domain Map (informal) or Model (formal) Workflow/Process Models (Human + Systems) As-Is & To-Be Service Usage Model (a set of services organised and coordinated to provide an function within an application) Application (UI, application specific software, service coordination) Domain Model Stakeholder & Role Models Goal & Function Models Domain Information Model Domain Context Model Scenarios (Workflow Narratives) Domain System Model Workflow/Process Models (Human + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Workflow (Practice & Process) Models (Human + Systems) As-Is & To-Be Project Case Studies Process Model Process-specific Information Model Practice Description / Model Use Case Model Service Usage Model SUM Description and Use Case Services Used Service Use Cases Internal Service Co-ordination Orchestration Choreography Application Specific Layer User Interface Application Specific Functions Service Consumer Interface Service Consumer Interface Service Consumer Interface
    28. 28. Documented by: <ul><li>Domain, Information, Process and Service Usage Models </li></ul><ul><li>Services: Interface Types, Definitions and Descriptions </li></ul><ul><li>Guides, Methodologies, Analysis </li></ul>Service Usage Models
    29. 29. Partner Collaboration <ul><li>6 Collaboration Themes... 20 SUMs for: </li></ul><ul><ul><li>National level implementations of Shibboleth / SAML for authentication and authorisation </li></ul></ul><ul><ul><li>Examples of Enterprise Architectures in institutions based on SOA </li></ul></ul><ul><ul><li>Federated Repositories </li></ul></ul><ul><ul><li>Movement of student data between institutions </li></ul></ul><ul><ul><li>Collation of research quality data </li></ul></ul><ul><ul><li>e-Portfolios (separate from 4) </li></ul></ul>
    30. 30. Progress <ul><li>Partnership now active </li></ul><ul><li>Initiatives in each partner country </li></ul><ul><li>Knowledge base now ‘live’ </li></ul><ul><ul><li>Free to use </li></ul></ul><ul><ul><li>Soon open to contributions </li></ul></ul><ul><ul><li>www.e-framework.org </li></ul></ul>