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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. More on each of the Four Levels
SOA & the-Framework
MORE…
More on each of the Four Levels

41. 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)

42. 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)

43. 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)

44. 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)

45. 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)

46. Using Scenarios
for all 4 Levels

47. 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)

48. 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)

49. 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)

50. 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)

51. What does this mean for Programmes?
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. an Institutional SOA or EA
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
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

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