The Domains? – the Future? Bill Olivier Development Director JISC
Potential Benefits of Domain  Mapping / Modelling
Benefits – Funders and Partners <ul><li>A map of a complex environment </li></ul><ul><li>With Stakeholders identify opport...
Benefits - Practitioners <ul><li>Able to play a Bigger role in development </li></ul><ul><li>Able to innovate new practice...
Benefits - Developers <ul><li>Better engagement with, & understanding of, institutions, domain experts and users </li></ul...
Benefits - Institutions <ul><li>Better understanding of specialist potential to contribute and of their support needs </li...
Other Potential SOA Benefits to Institutions <ul><li>Better software </li></ul><ul><ul><li>Software better aligned with in...
Domains
JISC Approach: Four Layers above Services Domain Map  (informal) or  Model  (formal) Workflow / Process Models     (Humans...
Domain? <ul><li>What is a Domain? </li></ul><ul><li>For our purposes, it is: </li></ul><ul><li>“ a recognisable area of wo...
Domain? <ul><li>The e-Framework Consortium sees a University as composed of five sub-domains: </li></ul><ul><ul><ul><li>Le...
Domain? <ul><li>Each of these in turn breaks down into further sub-domains, e.g. </li></ul><ul><li>Learning & Teaching: </...
Domain? <ul><li>Typically a domain has: </li></ul><ul><li>Practitioners </li></ul><ul><li>Specific Functions and Expertise...
JISC Develops for Domains that cut across Institutions Institution A Institution B Institution C Institution D Institution...
The Role of Domain Models <ul><li>Domain Models  form a  Bridge  between  Users’ Needs  &  Services </li></ul>Reference Im...
<ul><li>How? </li></ul>
Domain Models & Engagement <ul><li>But how are Issues & Needs to be identified? </li></ul><ul><ul><li>not just for an inst...
Domain Models & Engagement <ul><li>Have to work with </li></ul><ul><ul><li>Stakeholders </li></ul></ul><ul><ul><li>Domain ...
Domain Models & Engagement <ul><li>To Map and Model their Domain </li></ul><ul><ul><li>To reflect & reflect on current pra...
Elements of a Domain Model <ul><li>Stakeholders & Roles Who? </li></ul><ul><li>Aims & Goals Why? </li></ul><ul><li>Functio...
Domain Map Domain Model Internal Stakeholders  & Roles Goals External Stakeholders & Related Domains Scenarios  (Workflow ...
Domain Model Internal Stakeholders  & Roles Goals External Stakeholders & Related Domains Scenarios  (Workflow Narratives)...
Domain Maps & Models Case Studies / Scenarios / Practitioner Stories Domain Model Domain Context Model Domain Information ...
Domain Mapping: over to you!
<ul><li>Domain Elements </li></ul><ul><li>External Stakeholders & Related Domains  (who benefits (or not!)) : </li></ul><u...
The JISC e-Framework: a ‘Meta-Programme’ that works  through other JISC Programmes
What Domain Mapping is for <ul><li>Supporting the conversation: </li></ul><ul><ul><li>between  Stakeholders/Practitioners ...
Outputs of JISC Programmes & Projects  <ul><li>Knowledge outputs  of JISC projects : </li></ul><ul><ul><li>Case studies an...
Benefits of the e-Framework & SOA to JISC Programmes & Projects  <ul><li>Knowledge outputs  of JISC projects  more reusabl...
The e-Framework Knowledge Base Present and Future
The (Current) International e-Framework Web site <ul><li>Service Usage Models  (which may be derived from and link back to...
The (Future) JISC/International e-Framework Web site <ul><li>Domain Maps & Models </li></ul><ul><li>Practice & Process Mod...
Project Contributions <ul><li>Simplest:  Add a brief description and pointer to the projects own web site against knowledg...
Project Use <ul><li>As the Knowledge Bases builds, when a project starts: </li></ul><ul><li>Search the Knowledge Base(s) f...
Institutional Contributions and Use <ul><li>As Institutions start to use the Knowledge Bases to develop their own systems ...
JISC Approach Domain Map  (informal) or  Model  (formal) Workflow / Process Models     (Humans + Systems)   As-Is  &  To-B...
SOA & the-Framework <ul><li>Parting Questions </li></ul>
Over to You… <ul><li>HOW DO WE MODEL OUR WORLD? </li></ul><ul><li>How can JISC programmes work most effectively with  comm...
SOA & the-Framework <ul><li>Thank you </li></ul>
SOA & the-Framework <ul><li>MORE… </li></ul><ul><li>More on each of the Four Levels </li></ul>
JISC Approach: Four Layers above Services Domain Map  (informal) or  Model  (formal) Workflow / Process Models     (Humans...
Domain Maps & Models Domain Map  (informal) or  Model  (formal) Workflow / Process Models     (Humans + Systems)   As-Is  ...
Practice & Process Models Domain Map  (informal) or  Model  (formal) Workflow / Process Models     (Humans + Systems)   As...
Application Models Domain Map  (informal) or  Model  (formal) Workflow / Process Models     (Humans + Systems)   As-Is  & ...
Service Usage Models (SUM) Domain Map  (informal) or  Model  (formal) Workflow / Process Models     (Humans + Systems)   A...
<ul><li>Using Scenarios </li></ul><ul><li>for all 4 Levels </li></ul>
Service Usage Models (SUM) Domain Map  (informal) or  Model  (formal) Service Usage Model (a set of services organised and...
Service Usage Models (SUM) Domain Map  (informal) or  Model  (formal) Service Usage Model (a set of services organised and...
Service Usage Models (SUM) Domain Map  (informal) or  Model  (formal) Service Usage Model (a set of services organised and...
Service Usage Models (SUM) Domain Map  (informal) or  Model  (formal) Service Usage Model (a set of services organised and...
SOA & the-Framework <ul><li>What does this mean for Programmes? </li></ul>
Exercise: Review of Programme Calls and related Documents <ul><li>eF paragraph for embedding in calls - OK? Change? </li><...
From JISC soa outputs to an Institutional SOA or EA
IT Strategy, Enterprise Architecture & the e-Framework <ul><li>IT   Strategy  has to be aligned with  Organisational   Str...
Turning soa into an Institutional SOA <ul><li>JISC Programmes and Projects can </li></ul><ul><ul><li>Help identify Service...
Turning soa into an Institutional SOA <ul><li>Two approaches can be adopted: </li></ul><ul><ul><li>Top-down , driven by or...
Turning the soa into an Institutional SOA <ul><li>The best approach seems to be a combination of both: </li></ul><ul><ul><...
Enterprise Architectures: New Understanding and New Skills  <ul><li>Which ever balance of Top Down and Bottom Up, </li></u...
<ul><li>Enterprise Architecture </li></ul><ul><li>Pilot Group </li></ul>
Enterprise Architecture Pilot Group <ul><li>JISC has been asked to consider whether, and if so how, it should take forward...
Enterprise Architecture Pilot Group <ul><li>What it aims to do: </li></ul><ul><li>Ensure a good understanding of EA </li><...
Enterprise Architecture Pilot Group <ul><li>Support attendance at TOGAF Conferences </li></ul><ul><ul><li>Conferences atte...
Enterprise Architecture Pilot Group <ul><li>Evaluate the benefits of EA for F/HEIs </li></ul><ul><ul><li>Self-assessment b...
Upcoming SlideShare
Loading in …5
×

PowerPoint Slides

379 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
379
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Developing ICT to support the core businesses of Education &amp; 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 &amp; 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 &amp; 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 &amp; 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 &amp; 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 &amp; 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 &amp; Services ‘ Service Usage Models ’ are a “set of services that provide usage scenarios ” Services are technical services and focus on classifying &amp; 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 &amp; Services ‘ Service Usage Models ’ are a “set of services that provide usage scenarios ” Services are technical services and focus on classifying &amp; describing Open Service Interface Standards Both provide links to a variety of further information
  • PowerPoint Slides

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

    ×