PowerPoint Slides

Joint Information Systems Committee

The Domains? – the Future?

Bill OlivierDevelopment Director

JISC


Potential Benefitsof

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


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


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


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


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

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


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


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


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.


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


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


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.


How?


Domain Models & Engagement

But how are Issues & Needs to be identified?

–not just for an institution?

–but across a sector?



Have to work with

–Stakeholders

–Domain Experts & Practitioners

through their Communities

– HOW?



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

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


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


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


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


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 BasePresent and Future


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:


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


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


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





Sc

ena

rio

s

Stable: Reusable Knowledge

Innovation: Variable & Changing

Innovation: Variable & Changing

Stable:Standardised Distributed Components


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


SOA & the-Framework

Thank you


SOA & the-Framework

MORE…

More on each ofthe Four Levels


JISC Approach: Four Layers above Services





Sc

ena

rio

s


Sc

ena

rio

sDomain 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


Sc

ena

rio

sPractice & Process Models





Workflow/Process Models (Human + Systems) As-Is & To-Be


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


Sc

ena

rio

sApplication Models





Application Specific Layer

User Interface

Application Specific

Functions

Service Consumer Interface




Sc

ena

rio

sService Usage Models (SUM)





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


Using Scenariosfor all 4 Levels


Sc

ena

rio



Service Usage Model(a set of services organised and coordinated to provide an function within an application)



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


Sc

ena

rio








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


Sc

ena

rio






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


Sc

ena

rio






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


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


From JISC soa outputsto

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

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


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



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?



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?

Date post:	10-May-2015
Category:	Technology
Upload:	aamir97
View:	273 times
Download:	0 times

PowerPoint Slides

Technology