Joint Information Systems Committee The Domains? – the Future? Bill Olivier Development Director JISC
Dec 19, 2015
Joint Information Systems Committee
The Domains? – the Future?
Bill OlivierDevelopment Director
JISC
Joint Information Systems Committee
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
Joint Information Systems Committee
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
Joint Information Systems Committee
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
Joint Information Systems Committee
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
Joint Information Systems Committee
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
Joint Information Systems Committee
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)
Sc
ena
rio
s
Joint Information Systems Committee
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
Joint Information Systems Committee
Domain?
The e-Framework Consortium sees a University as composed of five sub-domains:
1. Learning and Teaching
2. Research
3. Libraries
4. Administration
5. Information Services
Joint Information Systems Committee
Domain?
Each of these in turn breaks down into further sub-domains, e.g.
Learning & Teaching:Course ManagementContent Preparation and ManagementStudent EnrolmentCourse Delivery (lectures, seminars, projects, etc.)Assignments and ActivitiesAssessment
etc.
Joint Information Systems Committee
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
Joint Information Systems Committee
JISC Develops for Domains that cut across Institutions
Institution A
Institution B
Institution C
Institution D
Institution E
Institution F
Learning & Teaching Domain
Research Domain
Library / Resources Domain
Admin Domain
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
Joint Information Systems Committee
The Role of Domain Models
Domain Models form a Bridge between Users’ Needs & Services
Reference Implementations, Demonstrators, Pilots,
Institutional SOAs
A Domain Model shows howthe 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 buildReference Implementations, Demonstrators and/or institutional service architectures.
Joint Information Systems Committee
Domain Models & Engagement
But how are Issues & Needs to be identified?
–not just for an institution?
–but across a sector?
Joint Information Systems Committee
Domain Models & Engagement
Have to work with
–Stakeholders
–Domain Experts & Practitioners
through their Communities
– HOW?
Joint Information Systems Committee
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
Joint Information Systems Committee
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?
Joint Information Systems Committee
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
Joint Information Systems Committee
Domain Model
Internal Stakeholders &
Roles
Goals
External Stakeholders & Related Domains
Scenarios (Workflow Narratives)
Domain Functions
make requests of
are the actors inhow done / described in
have
realised by
have
carry out
provide
Elaborated Practice and Process Models
Practitioners Developers
provide the narratives for, inform anddevelop
(re-)used by
collaborate
co-developworkflow and software
Products/Services
provide
satisfyDomain
Information Model
Domain System Model
used in
used in
informinform
inform
used for info stored in & exch anged between systems
used by
used by
Joint Information Systems Committee
Cas
e S
tud
ies
/ Sce
nar
ios
/ Pra
ctit
ion
er S
tori
es
Domain Maps & Models
Domain Model
Domain Context Model
Domain Information
External Stakeholder
Providers
Domain Function
Goal / Outcome
Internal Stakeholders /
Practitioner Roles
OutputsInputs
External StakeholderBeneficiaries
Op
po
rtu
nit
ies
/ Pro
ble
ms
/ Des
ign
Sce
nar
ios
Domain Specific Entities
Sub-Domains, Processes & Sub-Functions
Goal / Outcome
Learning & Teaching Domain
Learners&
Teachers
Function:Learn & Teach
includesPrepare, Assess
Goal: Enhance Learners’
knowledge, skills & understanding
DegreesResearch papers
Class Lists, Timetables… Resources, Assessments,
Researchers, Admissions
Officers
(SROs et al) Employers
Fulfil Mission, Make Money
Joint Information Systems Committee
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?
Joint Information Systems Committee
The JISC e-Framework:
a ‘Meta-Programme’that works
through other JISC Programmes
Joint Information Systems Committee
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
Joint Information Systems Committee
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
Joint Information Systems Committee
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
Joint Information Systems Committee
The (Current) International e-Framework Web site
Service Usage Models (which may be derived from and link back toDomain, Information and Process Models)
Services: definitions and descriptions
Guides, Methodologies, Analyses
ServiceService Usage Usage ModelsModels
International e-Framework Web site currently supports technical information:
Joint Information Systems Committee
The (Future) JISC/International e-Framework Web site
Domain Maps & Models
Practice & Process Models
Application Design Models
Domain Maps Domain Maps & Models& Models
Extension to Web site will support more human & organisational information:
Practice & Practice & Process Process ModelsModels
Application Application Design Design ModelsModels
Joint Information Systems Committee
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
Joint Information Systems Committee
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)
Joint Information Systems Committee
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
Joint Information Systems Committee
The Innovation Layer 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)
Sc
ena
rio
s
Stable: Reusable Knowledge
Innovation: Variable & Changing
Innovation: Variable & Changing
Stable:Standardised Distributed Components
Joint Information Systems Committee
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 manyopen 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?
Joint Information Systems Committee
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)
Sc
ena
rio
s
Joint Information Systems Committee
Sc
ena
rio
sDomain 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)
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
Joint Information Systems Committee
Sc
ena
rio
sPractice & 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)
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
Joint Information Systems Committee
Sc
ena
rio
sApplication 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)
Application Specific Layer
User Interface
Application Specific
Functions
Service Consumer Interface
Service Consumer Interface
Service Consumer Interface
Joint Information Systems Committee
Sc
ena
rio
sService 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)
Service Usage Model
SUM Description, Structure,
Function and Usage Scenarios
Services Used
with cross-links
Diagram of Service
Structure
Internal Service
Co-ordinationOrchestration Choreography
Links back to Supported Processes
and Business Functions
Joint Information Systems Committee
Sc
ena
rio
sService 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)
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
Joint Information Systems Committee
Sc
ena
rio
sService 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)
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
Joint Information Systems Committee
Sc
ena
rio
sService 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)
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
Joint Information Systems Committee
Sc
ena
rio
sService 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)
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
andto build the
Service Composition
Helps to test that the Service
Composition delivers what was needed
Joint Information Systems Committee
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!!!
Joint Information Systems Committee
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
Processes
SOA-based Applications
e-FrameworkSOA & e-Framework focus onthe interface betweenthe Organisation and ICT
Enterprise Architecture looks at the whole
So the e-Framework can supportEA as well as SOA
Joint Information Systems Committee
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
Joint Information Systems Committee
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
Joint Information Systems Committee
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
Joint Information Systems Committee
Enterprise Architectures: New Understanding and New Skills
Which ever balance of Top Down and Bottom Up,realising the potential benefits of soaneeds new understanding and new skills
Enterprise Architecture provides a basis for both Top Down and Bottom Up approaches
Joint Information Systems Committee
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
Joint Information Systems Committee
Enterprise Architecture Pilot GroupWhat 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?
Joint Information Systems Committee
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?
Joint Information Systems Committee
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?