PowerPoint Slides
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
513
On Slideshare
513
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
3
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Developing ICT to support the core businesses of Education & Research , and supporting processes makes clear the huge complexity and variation involved . Organising the sub-areas and functionality helps to create a map of this complex environment Populating it with information helps to see both: What has been done What remains to be done (much larger task) The scale of the task requires collaboration, and the map provides a strategic planning tool. This helps agreement on prioritising: Where to invest in further development of standards Where to invest in establishing working interoperability Partners & Industry need to work together to significantly improve ROI by reducing the costs of : agreeing required service specifications establishing interoperability through accelerating the whole cycle sharing the costs (optional expansion) Collaborative tasks include: Establishing priority requirements Prototyping specifications Creating Demonstrators and Pilots Creating OS Reference Implementations Carrying out Interoperability Testing Establishing Conformance Testing and Kitemarking Dissemination when interoperability is established
  • SOA offers many potential benefits , but a central promise is that it enables a more flexible infrastructure that can be more easily adapted to organisational strategies (which in turn are increasingly seen as a continuous rather than a five year process ) Others include: More modular systems allowing better match of infrastructure to needs, priorities & budgets Greater benefit from existing information silos through service interfaces The e-Framework adds : Increased and shared understanding across different communities Helping to establish wider interoperability and lower costs
  • They Key to successful development is close collaboration between Customers & Suppliers Developers want to be able to deliver more at lower cost, enabling faster response to customers (Customers want to get more at a lower price!) Note: A Component can also be embedded functionality in an existing system that is exposed as a service With a more modular approach , functionality that is not core can be outsourced to innovative specialists Developers need neutral spaces, over and above standards bodies , to prototype and trial new standards as well as to establish interoperability The service oriented approach is changing the way software is developed and, in the process, giving rise to new, more flexible and innovative business models
  • SOA offers many potential benefits , but a central promise is that it enables a more flexible infrastructure that can be more easily adapted to organisational strategies (which in turn are increasingly seen as a continuous rather than a five year process ) Others include: More modular systems allowing better match of infrastructure to needs, priorities & budgets Greater benefit from existing information silos through service interfaces The e-Framework adds : Increased and shared understanding across different communities Helping to establish wider interoperability and lower costs
  • Thus Doamin Models play a key role in the definition and use of services Domain Models should be cross-checked and agreed on by the relevant User & Stakeholder Community - at least as providing a typical solution to a common problem Where the practice is immature , they should evolve over time with enhanced understanding and technology
  • The e-Framework Knowledge Base has three main elements: A set of ‘Service Usage Models’ A set of ‘Services’ A set of Guidelines on how to create and use these Reference Models & Services ‘ Service Usage Models ’ are a “set of services that provide usage scenarios ” Services are technical services and focus on classifying & describing Open Service Interface Standards Both provide links to a variety of further information
  • The e-Framework Knowledge Base has three main elements: A set of ‘Service Usage Models’ A set of ‘Services’ A set of Guidelines on how to create and use these Reference Models & Services ‘ Service Usage Models ’ are a “set of services that provide usage scenarios ” Services are technical services and focus on classifying & describing Open Service Interface Standards Both provide links to a variety of further information

Transcript

  • 1. The Domains? – the Future? Bill Olivier Development Director JISC
  • 2. Potential Benefits of Domain Mapping / Modelling
  • 3. Benefits – Funders and Partners
    • A map of a complex environment
    • With Stakeholders identify opportunities & problems
    • A strategic planning tool for
      • Prioritised investment in standards
      • Prioritised investment in interoperability technologies
    • Projects build on each other, increasing value
    • Improved return on investment through coordination and collaboration between international partners
  • 4. Benefits - Practitioners
    • Able to play a Bigger role in development
    • Able to innovate new practices & processes together with supporting software
    • Build Domain & Process Maps & Models to capture relatively stable, agreed and reusable knowledge
    • Able to identify Opportunities & Problems
    • Able to use and evolve domain knowledge with Developers
  • 5. Benefits - Developers
    • Better engagement with, & understanding of, institutions, domain experts and users
    • More rapid development cycles through reusable knowledge
    • Faster response to new requirements
    • Communication and collaboration between developers
  • 6. Benefits - Institutions
    • Better understanding of specialist potential to contribute and of their support needs
    • Sharing good practice across institutions through domain communities
    • Continuous co-evolution of institution’s unique practices & processes - together with supporting IT
    • More effective communications between communities through shared understanding
  • 7. Other Potential SOA Benefits to Institutions
    • Better software
      • Software better aligned with institutional functions & processes (balances bespoke vs packaged applications)
      • Work practices and processes co-designed with software
      • Easier to change = easier to innovate, with less risk
      • ICT infrastructure better aligned with needs
      • Modular, more flexible
      • ICT that facilitates strategic change rather than hinders it
      • Result: a more agile and adaptive organisation
  • 8. Domains
  • 9. JISC Approach: Four Layers above Services Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Service Usage Model (a set of services organised and coordinated to provide a function within an application) Application (UI, application specific software, service coordination) Scenarios
  • 10. Domain?
    • What is a Domain?
    • For our purposes, it is:
    • “ a recognisable area of work or activity - as recognised by those working in it - and those who engage with it.”
    • Domains can be at different levels
    • … and nested
  • 11. Domain?
    • The e-Framework Consortium sees a University as composed of five sub-domains:
        • Learning and Teaching
        • Research
        • Libraries
        • Administration
        • Information Services
  • 12. Domain?
    • Each of these in turn breaks down into further sub-domains, e.g.
    • Learning & Teaching:
    • Course Management Content Preparation and Management Student Enrolment Course Delivery (lectures, seminars, projects, etc.) Assignments and Activities Assessment
    • etc.
  • 13. Domain?
    • Typically a domain has:
    • Practitioners
    • Specific Functions and Expertise
    • Specialised Vocabulary
      • with associated inter-related concepts
    • Tend to form (professional) Communities
      • to exchange ideas, share problems & solutions
  • 14. JISC Develops for Domains that cut across Institutions Institution A Institution B Institution C Institution D Institution E Institution F Institution A X X X X Institutions develop Architectures Practitioners develop Domain Maps and Models - JISC Programme Outputs are used to Implement Institutional Architectures - Domain Models are used to Develop Institutional Architectures Learning & Teaching Domain Research Domain Library / Resources Domain Admin Domain
  • 15. The Role of Domain Models
    • Domain Models form a Bridge between Users’ Needs & Services
    Reference Implementations, Demonstrators, Pilots, Institutional SOAs A Domain Model shows how the needs of its practitioners can be met by a set of Services. User Needs Domain Model Services Design A Domain Model may used to help build Reference Implementations, Demonstrators and/or institutional service architectures.
  • 16.
    • How?
  • 17. Domain Models & Engagement
    • But how are Issues & Needs to be identified?
      • not just for an institution?
      • but across a sector?
  • 18. Domain Models & Engagement
    • Have to work with
      • Stakeholders
      • Domain Experts & Practitioners through their Communities
      • HOW?
  • 19. Domain Models & Engagement
    • To Map and Model their Domain
      • To reflect & reflect on current practice
      • To identify problem areas & new opportunities
      • To set out what is common across multiple applications…
      • as a basis for identifying services
  • 20. Elements of a Domain Model
    • Stakeholders & Roles Who?
    • Aims & Goals Why?
    • Functions / High Level Tasks What?
    • Practices & Process Models How?
    • Scenarios & Case Studies How? Where? When?
  • 21. Domain Map Domain Model Internal Stakeholders & Roles Goals External Stakeholders & Related Domains Scenarios (Workflow Narratives) Domain Functions Products/ Services Domain Information Model Domain System Model External to Domain Domain Internal
  • 22. Domain Model Internal Stakeholders & Roles Goals External Stakeholders & Related Domains Scenarios (Workflow Narratives) Domain Functions make requests of are the actors in how done / described in have realised by have carry out provide Elaborated Practice and Process Models Practitioners Developers provide the narratives for, inform and develop (re-)used by collaborate co-develop workflow and software Products/ Services provide satisfy Domain Information Model Domain System Model used in used in inform inform inform used for info stored in & exch anged between systems used by used by
  • 23. Domain Maps & Models Case Studies / Scenarios / Practitioner Stories Domain Model Domain Context Model Domain Information External Stakeholder Providers Domain Function Goal / Outcome Internal Stakeholders / Practitioner Roles Outputs Inputs External Stakeholder Beneficiaries Opportunities / Problems / Design Scenarios Domain Specific Entities Sub-Domains, Processes & Sub-Functions Goal / Outcome Learning & Teaching Domain Learners & Teachers Function: Learn & Teach includes Prepare, Assess Goal: Enhance Learners’ knowledge, skills & understanding Degrees Research papers Class Lists, Timetables… Resources, Assessments, Researchers, Admissions Officers (SROs et al) Employers Fulfil Mission, Make Money
  • 24. Domain Mapping: over to you!
  • 25.
    • Domain Elements
    • External Stakeholders & Related Domains (who benefits (or not!)) :
      • Who?
    • Internal Stakeholders & Roles (who does the work + how they relate ) :
      • Who?
    • Goals (what are they trying to achieve + how they relate ) :
      • Goals?
    • Domain Functions (what are the key services &/or products provided) :
      • Do What?
    • Products / Services (what the function uses and what it provides) :
      • What Provided?
    • Domain Information Model (glossary of terms/info used + how they relate ) :
      • Term?
    • Domain Systems (what typical systems are used; what info is exchanged) :
      • System? Tool?
    • Simple Scenarios (workflow narratives that unpack functions) :
      • Main elements of a workflow?
  • 26. The JISC e-Framework: a ‘Meta-Programme’ that works through other JISC Programmes
  • 27. What Domain Mapping is for
    • Supporting the conversation:
      • between Stakeholders/Practitioners & Developers
      • about (Innovation) Needs & Possibilities
    • Domain Mapping & Process Modelling to:
      • Identify common and reusable domain knowledge
      • Identify common and reusable machine services
      • Support an ‘Innovation Layer’ developing new:
        • Practices & Processes
        • Lightweight Supporting Applications
  • 28. Outputs of JISC Programmes & Projects
    • Knowledge outputs of JISC projects :
      • Case studies and Scenarios, Reviews and Analyses
      • Domain Maps and Models
      • Good Practices and Guidance
      • Process Models
      • Pilots
    • Technical outputs of JISC projects:
      • Software functional designs
      • Prototype open service interfaces and information standards
      • Service implementations
      • Compositions of services (Service Usage Models)
      • Lightweight Apps & Integration Demonstrators
  • 29. Benefits of the e-Framework & SOA to JISC Programmes & Projects
    • Knowledge outputs of JISC projects more reusable:
      • captured in the knowledge base
      • separate what is institutionally specific from what is common
      • can be reused as-is or modified
      • can be extended, updated
    • Technical outputs of JISC projects more reusable:
      • More modular
      • Use cross-platform open interfaces and standards
      • Able to be used together… and used with commercial products
  • 30. The e-Framework Knowledge Base Present and Future
  • 31. The (Current) International e-Framework Web site
    • Service Usage Models (which may be derived from and link back to Domain, Information and Process Models)
    • Services: definitions and descriptions
    • Guides, Methodologies, Analyses
    Service Usage Models International e-Framework Web site currently supports technical information:
  • 32. The (Future) JISC/International e-Framework Web site
    • Domain Maps & Models
    • Practice & Process Models
    • Application Design Models
    Extension to Web site will support more human & organisational information: Domain Maps & Models Practice & Process Models Application Design Models
  • 33. Project Contributions
    • Simplest: Add a brief description and pointer to the projects own web site against knowledge, services and systems they’ve used
    • Next: Add to what is already there:
      • Contribute to the Domain Map or extend the Model
      • Add enhanced Practice and/or Process
    • Some will: Add something new (created or used) :
      • New Domain Maps or (parts of) Models
      • New Practices and/or Processes
      • New Applications that integrate Services
      • New Service Usage Models (could be a Mashups)
      • New Services
  • 34. Project Use
    • As the Knowledge Bases builds, when a project starts:
    • Search the Knowledge Base(s) for relevant resources (we hope that the Domain Maps in the upper level KB will provide a natural route to finding the rest)
    • Evaluate relevance to their project
    • Select resources to use or build on
    • Note what is missing from their project’s viewpoint
      • (this indicates where they can contribute)
  • 35. Institutional Contributions and Use
    • As Institutions start to use the Knowledge Bases to develop their own systems
    • They must be able to easily find what they need
    • They too can contribute
      • Additions to Domain Maps & Models
      • Case Studies
      • Good Practices & Processes
      • Lightweight Apps
      • New uses for Services
  • 36. JISC Approach Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Service Usage Model (a set of services organised and coordinated to provide a function within an application) Application (UI, application specific software, service coordination) Stable: Reusable Knowledge Innovation: Variable & Changing Innovation: Variable & Changing Stable: Standardised Distributed Components The Innovation Layer Scenarios
  • 37. SOA & the-Framework
    • Parting Questions
  • 38. Over to You…
    • HOW DO WE MODEL OUR WORLD?
    • How can JISC programmes work most effectively with communities (which communities?) to articulate their current, tasks, practices and processes, information models, ICT systems and capabilities?
    • How do we help them reflect on these to identify critical problem areas …
    • … and work with developers to identify new opportunities ?
    • HOW DO WE DEVELOP SERVICES?
    • How do we work through our programmes AND with our partners
    • (funders, industry, standards bodies, OSS developers) to define the many open service specifications that are needed to fill out the e-Framework?
    • HOW DO WE SUPPORT ADOPTION?
    • How should we be supporting institutions adopting a service oriented approach?
    • How can we share experiences?
    • How should we communicate successes (and failures) more widely?
  • 39. SOA & the-Framework
    • Thank you
  • 40. SOA & the-Framework
    • MORE…
    • More on each of the Four Levels
  • 41. JISC Approach: Four Layers above Services Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Service Usage Model (a set of services organised and coordinated to provide a function within an application) Application (UI, application specific software, service coordination) Scenarios
  • 42. Domain Maps & Models Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Service Usage Model (a set of services organised and coordinated to provide a function within an application) Application (UI, application specific software, service coordination) Scenarios Domain Model Internal Stakeholder & Role Models Goal Model Domain Information Model External Stakeholder & Domain Context Model Scenarios (Workflow Narratives) Domain System Model Domain Function Model
  • 43. Practice & Process Models Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Service Usage Model (a set of services organised and coordinated to provide a function within an application) Application (UI, application specific software, service coordination) Scenarios 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 Process Model Process-specific Information Model Practice Description / Model Use Case Model As-Is Case Studies, To-Be Scenarios
  • 44. Application Models Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Service Usage Model (a set of services organised and coordinated to provide a function within an application) Application (UI, application specific software, service coordination) Scenarios Application Specific Layer User Interface Application Specific Functions Service Consumer Interface Service Consumer Interface Service Consumer Interface
  • 45. Service Usage Models (SUM) Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Service Usage Model (a set of services organised and coordinated to provide a function within an application) Application (UI, application specific software, service coordination) Scenarios Service Usage Model SUM Description, Structure, Function and Usage Scenarios Services Used with cross-links Diagram of Service Structure Internal Service Co-ordination Orchestration Choreography Links back to Supported Processes and Business Functions
  • 46.
    • Using Scenarios
    • for all 4 Levels
  • 47. Service Usage Models (SUM) Domain Map (informal) or Model (formal) Service Usage Model (a set of services organised and coordinated to provide an function within an application) Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Scenarios Domain Scenarios Help build Domain Maps & Models Stakeholders & Practitioners' Worlds Stories about: What is done? Why ? What Products & / or What Services are provided? Who for? What ’s needed? Who Provides? Help check Domain Maps & Models Help Identify Opportunities & Problems
  • 48. Service Usage Models (SUM) Domain Map (informal) or Model (formal) Service Usage Model (a set of services organised and coordinated to provide an function within an application) Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Scenarios Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Workflow Scenarios Helps to build Good Practice & Process Models Practitioners' World Stories about: How are functions carried out? Who does it? What information is needed? Helps to check Good Practice & Process Models
  • 49. Service Usage Models (SUM) Domain Map (informal) or Model (formal) Service Usage Model (a set of services organised and coordinated to provide an function within an application) Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Scenarios Application Scenarios / Use Cases (human initiated) Helps to set out the requirements and to build the application Users' World Structured story: What’s the goal ? Who does it? What is the main sequence of actions & responses? What variations ? Helps to test that the application delivers what was needed
  • 50. Service Usage Models (SUM) Domain Map (informal) or Model (formal) Service Usage Model (a set of services organised and coordinated to provide an function within an application) Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Scenarios Service Composition Scenarios / Use Cases (machine initiated) Application‘s World Structured story: What’s the goal ? What System initiates ? What’s the main sequence of actions & responses? What variations ? Helps to set out requirements and to build the Service Composition Helps to test that the Service Composition delivers what was needed
  • 51. SOA & the-Framework
    • What does this mean for Programmes?
  • 52. Exercise: Review of Programme Calls and related Documents
    • eF paragraph for embedding in calls - OK? Change?
    • eF Guidance for Projects - OK? Change?
    • What should be embedded in bid forms?
    • Guidance for Markers - OK? Change?
    • Gathering and collating eF related info from projects – How? What Tags are needed?
    • How do we use this to track projects wrt the eF?
    • If we don’t get these right, the e-Framework Programme can’t get off the ground!!!
  • 53. From JISC soa outputs to an Institutional SOA or EA
  • 54. IT Strategy, Enterprise Architecture & the e-Framework
    • IT Strategy has to be aligned with Organisational Strategy
    • Enterprise Architecture seeks to align architectures for:
      • Organisation Structure & Function
        • Organisation
        • Processes
      • ICT Structure and Function
        • Applications
        • ICT Infrastructure
    • SOA / e-Framework focus on:
        • Practices & Processes
        • Service-Based Applications
    SOA & e-Framework focus on the interface between the Organisation and ICT Enterprise Architecture looks at the whole So the e-Framework can support EA as well as SOA Processes SOA-based Applications e-Framework
  • 55. Turning soa into an Institutional SOA
    • JISC Programmes and Projects can
      • Help identify Services needed across the sector
      • Develop and Pilot them
      • Help establish Open Service Interface Standards
    • But each F/HEI is responsible for developing its own Architecture, based on their:
      • Strategy
      • Context
      • Priorities
      • Budget
  • 56. Turning soa into an Institutional SOA
    • Two approaches can be adopted:
      • Top-down , driven by organisational strategies and policies
      • Bottom-up , driven by immediate needs and priorities
    • Both have advantages, but also risks:
      • Pages of documents may never result in anything, or need to be reworked before they gets used
      • Many ad hoc developments may end up in a mess, or need to be reworked to establish common service interfaces
  • 57. Turning the soa into an Institutional SOA
    • The best approach seems to be a combination of both:
      • Top-down architecture:
        • broad, but not detailed to begin with
      • Incremental, bottom-up delivery by priorities
      • Each project fills out some aspect of the Top level
      • The Top level model may change in the light of:
        • Completed Projects
        • New Organisational Aims
        • Changing Environment
  • 58. Enterprise Architectures: New Understanding and New Skills
    • Which ever balance of Top Down and Bottom Up,
    • realising the potential benefits of soa
    • needs new understanding and new skills
    • Enterprise Architecture provides a basis for both Top Down and Bottom Up approaches
  • 59.
    • Enterprise Architecture
    • Pilot Group
  • 60. Enterprise Architecture Pilot Group
    • JISC has been asked to consider whether, and if so how, it should take forward Enterprise Architecture for F/HEIs
    • Planning an Enterprise Architecture Pilot Group
    • Call go out in July
    • Aim: to evaluate the Benefits of EA for F/HEIs
    • Professionally supported, working with TOGAF
      • Training for participants
      • Meetings and Forum to discuss problems and solutions
    • Fund members costs
  • 61. Enterprise Architecture Pilot Group
    • What it aims to do:
    • Ensure a good understanding of EA
      • Training delivered. Evaluation of the training provided.
    • Develop skills in Methods
      • Easiest: how many get the IT Architect Certificate (but may be too strong a focus – also: what specific knowledge was gained?)
      • Or self-assessment by participants / their colleagues
      • Or by their results in their institutions (peer assessment)
    • Support development of an Early Adopter community
      • Does the Pilot Group form a working community?
      • Does it sustain after the project?
    • Provide EA tools
      • Which tools are provided/selected? How useful are they?
  • 62. Enterprise Architecture Pilot Group
    • Support attendance at TOGAF Conferences
      • Conferences attended
        • No.of people? Evaluation? Longer term benefits?
    • Workshops with other countries working on EA for F/HE
      • Conferences attended
        • No.of people? Evaluation? Longer term benefits?
    • Consider how EA and Methods may need to be adapted
      • What features of TOGAF prove useful? Which dropped?
        • Is a revised Architecture Framework & Architecture Development Method produced for F/HEIs?
        • Is/are reference architecture/s produced?
        • Are these useful to others?
  • 63. Enterprise Architecture Pilot Group
    • Evaluate the benefits of EA for F/HEIs
      • Self-assessment by participating institutions
      • Part of final evaluation study
    • Evaluate the benefits of TOGAF for F/HEIs
      • Assessment by participating institutions
      • Part of final evaluation study
    • Write up and publish Case Studies and Report on Findings
      • Case studies, architectures, processes, cross-comparisons
    • Make Recommendations to JISC ands to F/HEIs
      • What recommendations are made to JISC / F/HEIs
        • Do they help to develop further JISC programmes?