The Domains? – the Future? Bill Olivier Development Director JISC

Potential Benefits of Domain Mapping / Modelling

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 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

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 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

More rapid development cycles through reusable knowledge 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 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

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 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

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

Domains

JISC Approach: Four Layers above Services Scenarios Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Service Usage Model (a set of services organised and coordinated to provide a function within an application)

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

Domain? The e-Framework Consortium sees a University as composed of five sub-domains: Learning and Teaching Research Libraries Administration Information Services

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.

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

JISC Develops for Domains that cut across Institutions - Domain Models are used to Develop Institutional Architectures JISC Develops for Domains that cut across Institutions - JISC Programme Outputs are used to Implement Institutional Architectures Learning & Teaching Domain Research Domain Library / Resources Domain Admin Domain X Institution A Institution A Institution B Institution C Institution D Institution E Institution F Institutions develop Architectures X X X Practitioners develop Domain Maps and Models

The Role of Domain Models User Needs Reference Implementations, Demonstrators, Pilots, Institutional SOAs Domain Model Design Services 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 A Domain Model shows how the needs of its practitioners can be met by a set of Services. A Domain Model may used to help build Reference Implementations, Demonstrators and/or institutional service architectures. Domain Models form a Bridge between Users’ Needs & Services

How?

Domain Models & Engagement But how are Issues & Needs to be identified? not just for an institution? but across a sector?

Domain Models & Engagement Have to work with Stakeholders Domain Experts & Practitioners through their Communities HOW?

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

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?

Domain Map Domain Model External Stakeholders & Related Domains 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

External Stakeholders & Related Domains Domain Model External Stakeholders & Related Domains make requests of have provide used by Internal Stakeholders & Roles Goals Domain Information Model Products/ Services have satisfy realised by used by provide carry out inform Domain Functions inform used in used for info stored in & exch anged between systems how done / described in are the actors in Scenarios (Workflow Narratives) inform Domain System Model used in provide the narratives for, inform and develop Elaborated Practice and Process Models (re-)used by collaborate Practitioners Developers co-develop workflow and software

Domain Maps & Models Learning & Teaching Domain Domain Model Domain Context Model External Stakeholder Providers External Stakeholder Beneficiaries Researchers, Admissions Officers (SROs et al) Employers Fulfil Mission, Make Money Goal / Outcome Domain Information Research papers Class Lists, Timetables… Inputs Outputs Degrees Case Studies / Scenarios / Practitioner Stories Opportunities / Problems / Design Scenarios Resources, Assessments, Domain Specific Entities Internal Stakeholders / Practitioner Roles Domain Function Function: Learn & Teach includes Prepare, Assess Learners & Teachers Goal: Enhance Learners’ knowledge, skills & understanding Goal / Outcome Sub-Domains, Processes & Sub-Functions

Domain Mapping: over to you!

Domain Elements External Stakeholders & Related Domains (who benefits (or not!)): Who? Internal Stakeholders & Roles (who does the work + how they relate): 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?

The JISC e-Framework: a ‘Meta-Programme’ that works through other JISC Programmes

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

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

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

The e-Framework Knowledge Base Present and Future

The (Current) International e-Framework Web site International e-Framework Web site currently supports technical information: 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 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 (Future) JISC/International e-Framework Web site Extension to Web site will support more human & organisational information: Domain Maps & Models Domain Maps & Models Practice & Process Models Application Design Models Practice & Process Models 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 Application Design Models

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

As the Knowledge Bases builds, when a project starts: 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)

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

The Innovation Layer JISC Approach Scenarios Domain Map (informal) or Model (formal) Stable: Reusable Knowledge Workflow / Process Models (Humans + Systems) As-Is & To-Be Innovation: Variable & Changing Application (UI, application specific software, service coordination) Innovation: Variable & Changing Stable: Standardised Distributed Components Service Usage Model (a set of services organised and coordinated to provide a function within an application)

SOA & the-Framework Parting Questions

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?

SOA & the-Framework Thank you

More on each of the Four Levels SOA & the-Framework MORE… More on each of the Four Levels

JISC Approach: Four Layers above Services Scenarios Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Service Usage Model (a set of services organised and coordinated to provide a function within an application)

Domain Maps & Models 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 Scenarios Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Service Usage Model (a set of services organised and coordinated to provide a function within an application)

Practice & Process Models 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 Scenarios Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Service Usage Model (a set of services organised and coordinated to provide a function within an application)

Application Models Domain Map (informal) or Model (formal) Application Specific Layer User Interface Application Specific Functions Service Consumer Interface Scenarios Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Service Usage Model (a set of services organised and coordinated to provide a function within an application)

Service Usage Models (SUM) 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 Scenarios Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Service Usage Model (a set of services organised and coordinated to provide a function within an application)

Using Scenarios for all 4 Levels

Service Usage Models (SUM) 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 Help Identify Opportunities & Problems Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Service Usage Model (a set of services organised and coordinated to provide an function within an application)

Service Usage Models (SUM) 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 Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Service Usage Model (a set of services organised and coordinated to provide an function within an application)

Service Usage Models (SUM) 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 Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Service Usage Model (a set of services organised and coordinated to provide an function within an application)

Service Usage Models (SUM) 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 Domain Map (informal) or Model (formal) Workflow / Process Models (Humans + Systems) As-Is & To-Be Application (UI, application specific software, service coordination) Service Usage Model (a set of services organised and coordinated to provide an function within an application)

What does this mean for Programmes? SOA & the-Framework What does this mean for Programmes?

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!!!

an Institutional SOA or EA From JISC soa outputs to an Institutional SOA or EA

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 Enterprise Architecture looks at the whole Processes SOA-based Applications e-Framework SOA & e-Framework focus on the interface between the Organisation and ICT So the e-Framework can support EA as well as SOA

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

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

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

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

Enterprise Architecture Pilot Group

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

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?

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 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?

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 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?