Proposed UNSDI Tech Gov Framework

8/10/2019 Proposed UNSDI Tech Gov Framework

1/52

United Nations Spatial Data Infrastructure(UNSDI)

Proposed Technical Governance Framework

Preliminar !eport"ersion #$#%&'%'%%*

!o+ ,tkinsonPaul -o.

UNSDI Technical Governance Framework Proposal 1Preliminary Report v1.1


2/52

Table of Contents

EXECUTIVE SUMMARY............................................................................................5PART 1 - INTRODUCTION AND BACKGROUND...............................................61. Introduction............................................................................................................6

1.1 Purpose and scope..........................................................................................61.2 Distribution....................................................................................................6

1.3 Organisation...................................................................................................6

2. Consultancy terms of reference..............................................................................7

2.1 ac!ground....................................................................................................7

2.2 Ob"ecti#es.......................................................................................................7

2.3 Consultancy deli#erables...............................................................................$

2.% Consultancy approac&....................................................................................$

2.%.1 O#er#ie'................................................................................................$

2.%.2 (ta!e&older engagement........................................................................$

2.5 )*(DI +uiding Principles............................................................................,

PART 2 - CONTEXT AND REQUIREMENTS........................................................,3. Institutional and go#ernance conte-t...................................................................1

3.1 (cope and definitions...................................................................................1

3.1.1 +o#ernance..........................................................................................1

3.1.2 (O/ go#ernance...................................................................................1

3.1.3 Operational0tec&nical go#ernance and institutional go#ernance..........11

3.2 (eparation of go#ernance concerns..............................................................11

3.3 Inter and intra (DI go#ernance....................................................................12

3.% #ol#ing nature of go#ernance approac&.....................................................12

3.5 /ddressing intangible (DI success factors..................................................12

3.6 +o#ernance dimensions of an )*(DI.........................................................133.6.1 O#er#ie'..............................................................................................13

3.6.2 ultidomain.......................................................................................13

3.6.3 ulti4"urisdictional..............................................................................13

3.6.% Di#erse participation capabilities.........................................................1%

3.6.5 ultiple interoperability le#el support.................................................1%

3.6.6 Differing conte-t and reuirements for )* (DIs................................1%

3.6.7 emporal c&ange..................................................................................1%

3.7 )* reform....................................................................................................15

%. Data conte-t.........................................................................................................16

%.1 Interoperability.............................................................................................16

%.2 Data generation distribution and use...........................................................1$%.3 Data concentrations and silos.......................................................................1$

%.% Custodians&ip and sources...........................................................................1$

5. ec&nology conte-t..............................................................................................1,

5.1 merging ec&nical 8actors.........................................................................1,

5.1.1 (ignificant patterns...............................................................................1,

5.1.2 (er#ice Oriented /rc&itectures............................................................1,

5.1.3 9eb ser#ices and conformance profiles...............................................2

5.1.% Open (ource and :eference Implementations.....................................22

5.1.5 :egistries..............................................................................................23

5.1.6 Ontologies............................................................................................26

5.2 ;egacy systems and migration.....................................................................275.2.1 Currently &eterogeneous systems.........................................................27



3/52

5.2.2 igration to ser#ices............................................................................27

5.2.3 +o#ernance implications......................................................................2$

5.3 Constraints....................................................................................................2$

5.3.1 :esourcing............................................................................................2$

5.3.2 +o#ernance realities.............................................................................2$

6. :euirements........................................................................................................2$6.1 Current situation and need for c&ange.........................................................2,

6.2 +eneral reuirements...................................................................................31

6.2.1 Inter4(DI go#ernance reuirements.....................................................31

6.2.2 Intra4(DI go#ernance reuirements.....................................................32

6.3 +o#ernance of data model and &armoni


4/52

List of Boxeso- 1 *eed for data models 4 )*P ast /frican consultation..................................16

o- 2 )*?;C ransport data modelling.....................................................................16

o- 3 &e need for data models 98P (DI proposal................................................17

o- % +eoscience data &armoni


5/52

EXECUTIVE SUMMARY

&e )*(DI 'ill be a Asystem of systemsB t&at e#ol#es o#er time to create a gro'ing

capacity to meet t&e c&allenges of efficiency responsi#eness global o#er#ie' andcapability building t&at is reuired. ssentially t&e )*(DI is an enabling frame'or!.

It 'ill pro#ide go#ernance structures and !ey resources to de#elop blueprints for t&e

establis&ment of interoperating operational (DIs 'it&in )* clusters agencies

programmes and national capacity building efforts.

/ccordingly t&e governance framework for t&e )*(DI needs to be a robust

structure t&at creates co&erence bet'een t&e many different go#ernance acti#ities

&appening at many le#els t&roug& t&e system of systems t&at 'ill reali t&e o#erall s&ape of t&e structure =t&e

arc&itecture> and a mec&anism to fill t&e structure in 'it& details =a go#ernancemet&odology>.

&e go#ernance frame'or! proposed e-ploits best practices 'it&in t&e )*

information management space )*4auspiced domains e-isting (DI initiati#es

international standards bodies and general information systems design.

&is document is presented in t&ree parts

Part 1describes t&e document t&e scope and approac& of t&e consultancy.

Part describes t&e conte-ts 'it&in '&ic& t&e )*(DI and its go#ernance frame'or!'ill be de#eloped. &is part of t&e document also details t&e !ey reuirements for t&e

go#ernance frame'or!. &ese descriptions are not e-&austi#e but are intended to

identify t&e factors t&at 'ill distinguis& an effecti#e )*(DI from t&e current limited

capability.

Part !of t&e document describes t&e proposed set of measures reuired to meet t&e

reuirements from eac& of t&e perspecti#es t&at affect suc& a system. &is &olistic

arc&itectural approac& ensures t&at all concerns identified can be addressed

systematically. / 'or!4plan is presented t&at comprises discrete pro"ects t&at build

!ey elements of t&e )*(DI capability. &is 'or! plan s&ould be combined 'it& t&e

business priorities and resourcing model to establis& an initial capability for t&e)*(DI t&at pro#ides sufficient go#ernance to meet t&e tec&nical reuirements and

mec&anisms to manage t&e ongoing e#olution of t&e )*(DI.

&e document is an initial draft a Astra' manB based partly on t&e 'or! of

)*+I9+ e-tended to include feedbac! and e-perience from t&e implementing

community and ot&er identified best practices. It is &oped t&at t&e Aseparation of

concernsB 'it&in t&e sections of t&is document ma!e it possible for sta!e&olders to

focus on t&e areas of concern and e-pertise t&ey can bring and to t&en pro#ide

feedbac! to identify any critical gaps in t&e !no'ledge scope or analysis. &e

solution can t&en be refined to be t&e most practical possible approac& t&at addresses

all t&e critical issues t&at &a#e been identified by t&e sta!e&olders.



6/52

&e solution is based on t&e realities of reusability of resources t&ese resources &a#e

to be building bloc!s 'it& !no'n si


7/52

)*(DI capability and address critical c&allenges t&at relate to eac& of t&e 5

#ie'points or aspects of t&e )*(DI.

&e document is intended to be a li#ing document t&at reflects t&e articulated

reuirements feedbac! and ultimately design decisions t&at are ta!en by t&e

sta!e&older community.

$ 1onsultanc terms of reference

&is section pro#ides a brief description of t&e bac!ground to t&e )*(DI initiati#e

and outlines t&e scope of t&e consultancy and t&e approac& used to tac!le t&e problem

of go#ernance frame'or! design. &e section also articulates some important guiding

principles '&ic& inform t&e design of t&e )*(DI.

$# -ack0round

/ny comple- problem needs to be resol#ed by brea!ing it do'n into smallerproblems t&at can be tac!led using a#ailable resources. Infrastructures by definition

pro#ide benefits to multiple sta!e&olders so t&e problem is furt&er complicated by

ma!ing sure t&at t&ere is a mandate and business dri#er for eac& part of t&e solution.

In t&e case of a (patial Data Infrastructure t&e scope of t&e problem is 'ell

documented but t&e brea!do'n of t&e problem into smaller units is still an emerging

process. It is necessary for t&e )* to determine t&e fundamental factors influencing

t&e ability to Adi#ide and conuerB t&e problem of impro#ing information

management and access. One ac!no'ledged constraint is t&at t&e )*(DI 'ill be a

synt&esis of acti#ities underta!en by )* agencies and sta!e&olders and not a single

massi#e system replacing many e-isting systems.

&e !ey enabler for implementing t&e )*(DI is t&us a governance framework so

t&at t&e roles and responsibilities of eac& participant can be clearly defined.

Identification of !ey roles pro#ides a frame'or! for targeted implementation planning

of t&e critical s&ared components. It is important to &a#e a tec&nical blueprint for a

)*(DI to identify specific reuirements but to minimi and t&e (trategy for De#eloping and

Implementing )*(DI1document

detail !ey aspects of t&e operational0tec&nical go#ernance as it relates to t&e

)*(DI as an enabling and integration tool for operational infrastructures 'it&in

)* agencies national "urisdictions and regional or international collaborations

1Ibi



8/52

&ig&lig&t and ma!e recommendations regarding critical priority tec&nical

go#ernance issues t&at need to be addressed by t&e )*(DI in reference to !ey )se

Cases and associated roles for ma"or actors.

&e go#ernance frame'or! presented in t&is document 'as presented at t&e ig&t

)*+I9+ Plenary &eld from 2$43 *o#ember 27 in ang!o! &ailand.

$ 1onsultanc delivera+les

&e principle deli#erables from t&e consultancy are

a. / document describing t&e )*(DI ec&nical +o#ernance 8rame'or!

including an e-ecuti#e summary.= t&is document>

b. Draft terms of reference =O:> for #arious roles adopted by )*+I9+

'it&in t&e tec&nical go#ernance structure

c. / guidance note '&ic& 'ill &elp t&e C&air of t&e tec&nical go#ernance

session=s> to conduct a structured discussion and decision ma!ing process

on priority issues and t&e 'ay to address t&em.

d. / draft pro"ect 'or! plan for t&e de#elopment of t&e )*(DI tec&nical

arc&itecture. &e outline of a pro"ect plan 'ill be prepared for t&e ang!o!

meeting for discussion. &is document 'ill be more fully fles&ed out

based on t&e deliberations of t&e ang!o! meeting.

$& 1onsultanc approach

$&$# /verview

&e approac& of t&e consultancy 'as to e-amine 'it& t&e aid of specific e-amples of

needs t&e interoperability reuirements implied by t&e scope of t&e )*(DI. a!ing a

broad #ie' 'it& practicalities in mind an o#erall go#ernance frame'or! 'ill be

deri#ed t&roug& '&ic& t&e de#elopment of specific go#ernance and tec&nical

interoperability arrangements can be facilitated. /lt&oug& t&e details of suc&

arrangements are beyond t&e scope of t&e frame'or! specific e-amples are included

to e-plain t&e simplifying abstractions of t&e conceptual frame'or!. It s&ould be

noted t&e detail of t&ese e-amples is purely illustrati#e and not proscripti#e since

t&ere is no intention to preclude meaningful sta!e&older participation or tec&nical

#alidation processes.

rea!ing t&e scope of t&e problem into more manageable pieces is a !ey aspect of t&e

approac&. &is can be furt&er refined using a formal system modelling approac& 'it&emp&asis on identifying t&e actors and )se Cases in#ol#ed in t&e go#ernance

processes implied by t&e establis&ment of a )*(DI. est practice in (DI arc&itecture

pro#ides a basic separation of concerns '&ereby t&e problem can be bro!en do'n

into a set of issues 'it& minimal interdependence. / preliminary analysis of t&e

go#ernance reuirements for establis&ment of eac& arc&itectural component 'as

underta!en.

$&$ Stakeholder en0a0ement

(ta!e&older input to t&e go#ernance frame'or! 'as ac&ie#ed primarily t&roug& t&e)*+I9+4$ meeting in ang!o!.Dra'ing on best practice and prioritised action areas

UNSDI Technical Governance Framework Proposal $Preliminary Report v1.1


9/52

allo's t&e consultation to focus on critical issues and identifying gaps in t&e needs

analysis.

9&ile de#eloping t&e go#ernance frame'or! targeted sta!e&older engagement 'as

used to capture representati#e sta!e&older reuirements. &is 'as ac&ie#ed by

:e#ie' of e-isting materials from rele#ant (DI initiati#es to capturego#ernance reuirements

Discussions 'it& selected sta!e&olders '&om &ad identified c&allenges in t&e

go#ernance realm typically t&roug& on4going initiati#es in t&e )*(DI space.

$3 UNSDI Guidin0 Principles

/doption of a +eospatial nterprise approac& as ad#ocated in t&e )*(DI

Compendium

&e )*(DI pro"ect 'ill implement t&e minimum necessary to reali


10/52

PART 2 - CONTEXT AND REQUIREMENTS

&is section of t&e document describes pertinent interrelated aspects of t&e reality in

'&ic& t&e )*(DI e-ists and '&ic& must be factored into )*(DI design. &e section

co#ers institutional and go#ernance conte-t data and information conte-t and t&e

tec&nology conte-t of t&e )*(DI.

$ Institutional and 0overnance conte.t

$# Scope and definitions

$#$# Governance

!Governance makes ecisions that e"ine e#pectations$ %rant power$ or veri"y

per"ormance. It consists either o" a separate process or o" a speci"ic part o"

mana%ement or leaershipprocesses.&'

+o#ernance aims to de#elop and manage consistent co&esi#e policies processes and

decision4rig&ts for a gi#en area of responsibility.

$#$ S/, 0overnance

/ narro'er scope of definition applied to net'or! ser#ices 'it&in a (er#ice Oriented

/rc&itecture =(O/> approac& suc& as t&ose en#isaged as a !ey enabler of t&e )*(DI

data access strategy is

!S() %overnance is abo*t mana%in% the +*ality$ consistency$ preictability$ chan%e

an interepenencies o" services.& =(tane! 26>

9i!ipedia also pro#ides a useful set of typical issues t&at are li!ely to emerge in

(O/

,ompliance to stanars or laws- IT systems re+*ire a*itin% to prove their

compliance to re%*lations like Sarbanes/(#ley0. In a S()$ service behavior

is o"ten *nknown

,han%e mana%ement- chan%in% a service o"ten has *n"oreseen conse+*ences

as the service cons*mers are *nknown to the service proviers. This makes an

impact analysis "or chan%in% a service more i""ic*lt than *s*al.

ns*rin% +*ality o" services- The "le#ibility o" S() to a new services

re+*ires e#tra attention "or the +*ality o" these services. This concerns boththe +*ality o" esi%n as the +*ality o" service. )s services o"ten call *pon other

services$ one mal"*nctionin% service can ca*se ama%e in many applications.

Some key activities that are o"ten mentione as bein% part o" S() %overnance are-

2ana%in% the port"olio o" services- plannin% evelopment o" new services an

*patin% c*rrent services

2ana%in% the service li"ecycle- meant to ens*re that *pates o" services o

not ist*rb c*rrent service cons*mers

2&ttp00en.'i!ipedia.org0'i!i0+o#ernance

http://en.wikipedia.org/wiki/Power_(sociology)http://en.wikipedia.org/wiki/Performance_(disambiguation)http://en.wikipedia.org/wiki/Managementhttp://en.wikipedia.org/wiki/Leadershiphttp://en.wikipedia.org/wiki/Power_(sociology)http://en.wikipedia.org/wiki/Performance_(disambiguation)http://en.wikipedia.org/wiki/Managementhttp://en.wikipedia.org/wiki/Leadership


11/52

Usin% policies to restrict behavio*r- r*les can be create that all services

nee to apply to$ to ens*re consistency o" services

2onitorin% per"ormance o" services- beca*se o" service composition$ the

conse+*ences o" service owntime or *nerper"ormance can be severe. 3y

monitorin% service per"ormance an availability$ action can be taken instantly

when a problem occ*rs.&

$#$ /perational4technical 0overnance and institutional 0overnance

It is of critical importance is ensure t&at t&ere is no gap bet'een t&e institutional

mec&anisms and t&e tec&nical implementation reuirements. &is &as pro#ed to be t&e

biggest single barrier to effecti#e interoperability in t&e past and is typified by lac! of

a publication and c&ange control process for common elements.

8or e-ample a typical scenario is '&ere t'o or more organi


12/52

o ensure t&at )*(DI capabilities are identified and addressed in order of priority

t&e business dri#ers for usage of s&ared resources 'ill need to be understood. &e

mapping of business needs to de#elopment of !ey capabilities 'ill ensure t&at t&e

essential business4dri#en capabilities are prioriti


13/52

$!& %e#0"$!" p%p#$0# $%e ';!i?$!" + "*e !ee& " .i"i;$"e "*e#e%i#< +$'"%#)

T*e #0"i! &e#i;! $""e.p"# " 5!& $pp%$'*e# " $&&%e## +$'"%##'* $# pe%$"i!; e!vi%!.e!" $!& '0"%e4 v$%i!; 0eve0# +

'..i".e!" $!& "*e '.p0e@4 +"e! p0i"i'i#e& !$"%e +%e0$"i!#*ip# /e"wee! $'"%# wi"*i! "*e UN)

Gey issues to be addressed in t&is conte-t are

ngagement 'it& and roles of I fol!s in )*(DI and (O/ go#ernance

ngagement 'it& management to 'in support for )*(DI and t&e paradigm

s&ifts t&at s&ared resources and (O/ imply

(timulating supporting c&anging 'or!ing practices mo#e from sto#epipes

to ser#ices

$6 Governance dimensions of an UNSDI

$6$# /verview

&e )*(DI go#ernance frame'or! needs to ta!e into account t&e multiple

sta!e&olders '&o 'ill be directly and indirectly affected by t&e establis&ment of

impro#ed information access and management.

&ese sta!e&olders are many and #aried and are best understood by e-ploring t&e

different AdimensionsB of t&e )*(DI. ac& of t&e aspects described belo' represent a

#alid 'ay of di#iding t&e scope of t&e )*(DI c&allenge and in total pro#ide a basis

to identify t&e simplest common approac&es t&at can be used to define componentbe&a#ior and &ence an implementation strategy.

Ob#iously t&ere may be natural correspondences bet'een sta!e&olders as identified

in different dimensions for e-ample national "urisdictions are natural data pro#iders

to global users and global programs =in particular art& Obser#ation> are data

pro#iders to national users.

$6$ 7ulti8domain

&e )nited *ations acti#ities co#er a broad range of domains and t&e operations of

single agencies typically reuire data spanning multiple domains. &e )*(DI must

enable t&e de#elopment of common applications t&at are able to utilise data fromdifferent sources. 8or effecti#e data integration across "urisdictions common

semantics and data models are reuired 'it&in eac& domain. @armonisation across

domains is also reuired to ensure t&e consistent treatment of ob"ects t&at are included

in a number of different domains. It is a desirable end goal to pro#ide seamless data

integration '&ere t&e end user does no need to be a'are of differences in data

management &o'e#er t&e more pragmatic goal is to enable a continual e#olution of

impro#ements in data integration.

&e need for t&e &armoni


14/52

use of standards and common approac&es to data modelling

modular models components t&at are interoperable and t&at can be reused

$6$ 7ulti'2urisdictional

)* operations co#er multiple "urisdictions. &e "urisdictions t&at fall 'it&in t&e

mandate of )* entities =programmes funds and agencies> also #aries from agency toagency.

o effecti#ely use information for decision ma!ing t&e )* needs to collate generate

and use data co#ering a number of "urisdictions. o be able to integrate data products

seamlessly across "urisdictions a mec&anism for supporting de#elopment and use of

common standards is reuired.

/lt&oug& national standards for data sets data products and ser#ices t&at enable

integration of data 'it&in a national (DI may e-ist t&ere is a need to &armoni


15/52

to optimi. In addition to t&e need to become more effecti#e

and efficient t&e report &ig&lig&ted t&e need for t&e )* to EH.increasin%ly serve as a

catalyst "or collective action$ both amon% its 2ember States an between them an

the vibrant constellation o" new non/state actors&. &e report also &ig&lig&ted t&at t&e

)nited *ations s&ould!harness the power o" technolo%y to improve the "ort*nes o"

evelopin% ,o*ntries&.

ot& statements &ig&lig&t !ey potential roles of t&e )*(DI in mediating bet'een

domains and "urisdictions to enable (DI interoperability and of assisting de#eloping

countries to de#elop (DI capabilities.

ore recently t&e )* (ecretary4+eneralFs @ig&4;e#el Panel made a series ofrecommendations to Aovercome the "ra%mentation o" the Unite Nations so that the

system can eliver as one& =)nited *ations 26>. &e report recommended

focusing on impro#ing )* efficiency and effecti#eness system4'ide co&erence and

management reform.

8rom t&e foregoing and as noted in t&e )*(DI compendium =@enric!sen 27> it

can be concluded t&at t&e )* system recognises a need to E move with the timesF in

order to deli#er on its mandate.

&e )*(DI is t&erefore li!ely to be implemented during a period of ma"or reform

'it&in t&e )*. &is represents a t&reat as 'ell as an opportunity. &e t&reat is t&at t&e



16/52

institutional conte-t of t&e )*(DI 'ill be e#ol#ing and structures staffing roles and

relations&ips bet'een )* sta!e&older organi


17/52

)*?;C recently completed t&e de#elopment of t&e first #ersion of a transport data model. &e

)*(DI4ransport focus 'as on semantics i.e. to ensure t&at '&ate#er database structure a

gi#en agency c&ose to implement it 'ould &a#e a common core set of attributes and #alue

domains on '&ic& to base data import0e-ports.

&e starting point for scoping semantic definitions 'as a compilation of t&e most common

practices in logistics data collection and data storage. Consultation 'it& logisticians 'ere used

to furt&er refine and clarify reuirements. &e result of t&e consultation 'as a list of ob"ects

definition 'it& attributes and #alue domains. &e ob"ect model 'as using (:Is +eodatabase

model%.

/lt&oug& t&e model 'as de#eloped by )*?;C based on reuirements of logistics users t&e

process 'as cognisant of t&e need to be compatible 'it& t&e e#ol#ing )*(DI as 'ell as ot&er

related modelling efforts. &e )*(DI4 team are no' e-ploring integration0&armoni and specific data modelling go#ernance c&allenges'ere identified by t&e team during t&e modelling process

+eneral 'N#D$ governance

9&o &as o'ners&ip of t&e #arious components of t&e )*(DIJ

/lt&oug& t&ere is a Enatural mandateF for certain agencies o#er specific parts of t&e

)*(DI s&ould t&is mandate0aut&ority be formalised if so &o'J

Data mo&elling

9&at is t&e mec&anism for updating sc&ema and &o' is consensus builtJ

Is t&ere to be a set timetable for updates and &o' can participation be effecti#ely

ac&ie#ed =i.e. &a#ing too many unstructured contributors becomes unmanageable>

:euirements =for data model> can come from t&e consumers in an ad &oc manner 4&o' can t&is input be impro#ed

*eed to ad#ocate for a culture of disaggregated indicators0attributes t&at can be

recombined as needed as t&e basis for a )*(DI.

*eed to determine structured and documented mec&anism for translation from e-ternal

data models to )*(DI and #ice #ersa =e.g. '&en integrating a national road data model

into )*(DI t&ere 'ill be some #alue mapping to be done. On '&at basis are

eui#alencies determinedJ>.

Box !T,e nee& for &ata mo&els - .FP #D$ proposal98P conducted an (DI needs assessment to de#elop a proposal for a 98P (DI as part of t&e

)*(DI effort =98P K I@/C/ 27>. &e assessment focused on t&e needs of 98P +I(user departments =OD/P OD/L and )*?;C>. One of t&e principle needs identified 'as to

define implement maintain and distribute common data sets for use across all geospatial data

departments. &e de#elopment of a data model 'as identified as being t&e critical first step to

ac&ie#ing t&e data reliability integrity standardi


18/52

I*(PI: data specifications are being de#eloped for !ey data sets. &ese data specifications

'ill be t&e result of a &armonisation process based on e-isting =national> data specifications

and '&ere a#ailable user reuirements and use cases pro#ided by I*(PI: sta!e&olders.

&ere are ongoing discussions regarding approac&es to &armonisation of data modelling

efforts for geoscience data in a global domain =+eo(ci;> and a "urisdictional conte-t

=I*(PI:>.

&e +eo(ci; International effort ta!es t&e position t&at it cannot become dependent on a

local or regional frame'or! especially one 'it& immature go#ernance and tec&nical

processes. It cannot t&erefore become based on an I*(PI: generic conceptual model.

&e mec&anisms a#ailable for resol#ing t&is include t&e de#elopment of a profiling

met&odology 'it&in t&e I*(PI: conceptual model to allo' adoption of t&e +eo(ci;

model. o ac&ie#e t&is bot& frame'or!s may need to agree on common profiling

mec&anisms so t&at on t&e one &and +eo(ci; can identify t&e target ob"ects for suc&

profiling in a 'ay t&at ma!es it easy and I*(PI: 'ould need to apply t&e profiling

mec&anism.

/n alternati#e option 'ould be for t&e I*(PI: +eneric Conceptual odel to be replaced by

an internationally recognised eui#alent suc& as a )* endorsed and e#entually I(O

standardised tool!it. It is li!ely t&at t&e profiling mec&anism 'ould still &o'e#er be reuired

to ac&ie#e implementation.

In any e#ent t&e fact t&at bot& modelling e-ercises dra' from a common I(O basis ma!es it

feasible to consider addressing t&e go#ernance issues and ac&ie#ing a common data model

bet'een I*(PI: and t&e international community of practice.

+eoscience data &armoni


19/52

&$& 1ustodianship and sources

/ priority tas! in t&e creation of any (DI is t&e determination of core common

geospatial data and t&e identification of custodian responsible for creation and

maintenance of t&e data set. ;ac! of clarity about aut&oritati#e sources of data leads

to

Duplication of effort to produce and maintain data sets

/dministrati#e o#er&ead to sync&roni. Issues raised include

Desirability of &a#ing a single aut&oritati#e source for data and does t&is mean a single

point of supply

Desirability of &a#ing multiple aut&oritati#e sources for data '&ere t&ere could be direct

competition confusion in t&e minds of users =customers> different sources based on scale

=duplication 'it&out generalisation> competition from pri#ate suppliers different

access0pricing arrangements

Desirability of &a#ing multiple points of supply. :aises issues of contemporaneity and

sync&roni are li!e most suc& concepts and terminology

sub"ect to a fair amount of self4ser#ing narro'ness of definition around particular

tec&nologies. &e core description from 9i!ipedia6 pro#ides a useful o#er#ie'.

Issues &ig&lig&ted in bol&are of critical importance to t&e )*(DI strategy.

!Relative to earlier attempts topromote software reusevia mo*larity o" "*nctions$

or by *se o" pree"ine %ro*ps o" "*nctions known as classes$ S()4s atomic level

ob5ects are 166 to 1$666 times lar%er$ an are associate by an application esi%ner

or en%ineer *sin% orchestration. In the process o" orchestration$ relatively lar%e

ch*nks o" so"tware "*nctionality 7services8 are associate in a non/hierarchical6&ttp00en.'i!ipedia.org0'i!i0(er#ice4orientedMarc&itecture

UNSDI Technical Governance Framework Proposal 1,Preliminary Report v1.1


20/52

arran%ement 7in contrast to a class4s hierarchies8 by a so"tware en%ineer$ or process

en%ineer$ *sin% a special so"tware tool which contains an e#ha*stive list o" all o" the

services$ their characteristics$ an a means to recor the esi%ner4s choices which the

esi%ner can mana%e an the so"tware system can cons*me an *se at r*n/time.

Underlying and enabling all of this is metadatawhich is s*""icient to escribe notonly the characteristics o" these services$ b*t also the ata that rives them. 92: has

been *se e#tensively in S() to create ata which is wrappe in a nearly e#ha*stive

escription container. )nalo%o*sly$ the services themselves are typically escribe by

;SD:$ an comm*nications protocols by S()P. Whether these description

languages are the best possible for the job, and whether they will remain the

favourites going forward, is at present an open question.;hat is certain is thatSO

is utterly dependent on data an services that are escribe *sin% some

implementation o" metaata which meets two criteria. !he metadata must be in a

form which software systems can consume to dynamically configure to maintain

coherence and integrity, and in a form which system designers can understand and

use to manage that metadata.

The %oal o" S() is to allow "airly lar%e ch*nks o" "*nctionality to be str*n% to%ether

to form ad"hoc applications which are built almost entirely from e#isting software

services. The lar%er the ch*nks$ the "ewer the inter"ace points re+*ire to implement

any %iven set o" "*nctionality< however$ very lar%e ch*nks o" "*nctionality may not be

%ran*lar eno*%h to be easily re*se. ach inter"ace brin%s with it some amo*nt o"

processin% overhea$ so there is a per"ormance consieration in choosin% the

%ran*larity o" services. The %reat promise o" S() is that the mar%inal cost o" creatin%

the n/th application is =ero$ as all o" the so"tware re+*ire alreay e#ists to satis"y the

re+*irements o" other applications. Only orchestration is required to produce a new

application.&

In t&e conte-t of t&e )*(DI t&e actual form of t&e ser#ices are not t&e critical issue

so muc& as t&e ability to encapsulate6 &escribe and re"use% (er#ices may be

net'or!4accessible or e#en CD4distribution but t&e implications for go#ernance

relate to t&e ability of ser#ice be&a#iors and metadata to be bro!en do'n into

standardi


21/52

ser#ices can significantly reduce information interoperability. 8or e-ample if one data

publis&er users a particular concept of time =e.g. a season indicated by t&e first day of

t&e season> for a ser#ice and second publis&er users a different time format as 'ell as

different semantics for start and end date for t&e temporal e-tent of a data set it is not

possible to searc& for and use data in a consistent manner across t'o ser#ices.

9it&in t&e broader I sector it &as been found t&at general standards suc& as t&e

93C 9eb (er#ices protocols are not sufficient to ac&ie#e interoperability by t&em

sel#es. / community 'ill generally need to agree on a common profileto ensure t&at

a compatible set of options are c&osen.

Box 7 Conformance Profiles

/fter many years of failure to ac&ie#e interoperability bet'een different #endor

systems implementing 93C 9eb (er#ices standards a ne' go#ernance body 'as formed

to publis& a set of common profiles t&e 9eb (er#ices Interoperability Organi Includes all ma"or #endors including t&ose instrumental in t&e 93C specifications

Creates Aconformance profilesB t&at can be used to actually test conformance as 'ell

as specify.

stablis&es an ongoing process for adding profiles as reuired.

9(4I &as establis&ed 3 'or!ing groups t&at address different aspects of t&e problem

#ample )pplications .orking +roup4 Illustrate best practices for implementations on

multiple #endor platforms

Testing Tools .orking +roup " De#elops self4administered tests to #ery conformance

'it& 9(4I profiles

3e8uirements +at,ering .orking +roup " Captures business reuirements to dri#e futureprofile selection

o ensure interoperability 'it&in a data access and distribution conte-t ser#ice

profiles t&at conte-tuali

use a community agreed #ocabulary in specific attributes =information

modeling>

Currently t&ere is no standard 'ay to describe profiles. @o'e#er some !ey

reuirements for profile &andling include

*eed for profiles to be mac&ine readable to enable e-ploitation of ser#ices

*eed to manage c&anging profiles

/bility to determine conflict '&en t&ere are multiple dependencies and

separately go#erned parts of a profile

*eed for profiles to be disco#erable =by t&e ser#ice de#elopers> to support

ser#ice instantiation

Box 9 #D$ #ervice Profiling re8uirements - an emerging pattern



22/52


23/52

&e )*(DI Compendium recogni sets out t&e OC@/ approac& to t&e

use of open source soft'are =O((>. It states t&at OC@/ 'ill attempt to @miti%ate

so"tware costs thro*%h increase *sa%e o" appropriate open so*rce %eo/spatial

so"twareAt&at complies 'it& Open+I( specifications. It furt&er states t&at OC@/ 'ill

in t&e longer term mo#e to'ards O(( soft'are pro#ide t&at it is inter aliaE"*lly

s*pporte %lobally an aopte as a stanar within the UN SecretariatA

In order to ma-imi in t&e

)*(DI and facilitate t&e important potential role of t&e 8O(( community t&e )*needs to determine an effecti#e engagement strategy.

Open (ource is free to use but not cost4free to build and maintain. &erefore a !ey

element of t&e engagement strategy s&ould be an in#estigation of &o' )*(DI can

support rele#ant 8O(( efforts.

*eed for )*(DI to set interoperability targets for commercial soft'are

de#elopers to meet

8or commercial soft'are particularly (:I =as currently represents a ma"or

proportion of t&e geospatial tec&nology used by t&e )*> need to de#elop a testbed so t&at commercial #endors can test interoperability of t&eir products against

targets establis&ed by t&e )*(DI

3$#$3 !e0istries

5.1.5.1 Overview

If a resource cannot be found it cannot be used. ?ust as importantly if t&e pro#enance

of a resource cannot be identified it is difficult to use in any real fas&ion. :egistries

are t&us a critical element of distributed data infrastructures. :egistries are t&e

mec&anisms by '&ic& artifacts related to agreements =e.g. a ser#ice specification> and

t&eir implementation =e.g. a ser#ice instance> can be publis&ed disco#ered and any

data resources can be made a#ailable for re4use. &e sets of resources a#ailable are

called registers =I(O 1,135>.

8rom a tec&nical perspecti#e an industry4standard Ameta4modelB for registries $ &as

been de#eloped '&ic& underpins suc& tec&nologies as )DDI and eb;

:egistry0:epository. &us t&e be&a#ior of registries and registers can be identified at

an abstract le#el e#en if t&e implementations are #aried.

&e go#ernance of registries is usefully described in I(O 1,135 AProcedures for

registration of +eograp&ic ItemsB =I(O 1,$$>. &is standard pro#ides a clear$=I(O0IC 1117, 1,,,>



24/52


25/52

! e 0 i s t e r / w n e r S u + m i t t i n 0 / r 0 a n i = a t i o n

1 o n t r o l - o d ! e 0 i s t e r 7 a n a 0 e r

! e 0 i s t e r ! e 0 i s t r

! e 0 i s t e r U s e r

1

1 . . ! u a l i f i e r

! u a l i f i e d " y

1

1 . .

a p p o i n t e r

a p p o i n t e d " y 1 . .

1

d e l e g a t e d " y

d e l e g a t o r 1

1 . .

o w n e r

r e g i s t e r

1

1 . .

r e c e i v e r

s u # m i t t e r

1 . .

1

m a n a g e d

m a n a g e r

1 . . 1c o n t e n t s t o r e d O n

1

1 . .

o p e r a t o r

s y s t e m

1

1

c o n t e n t $ o n t r o l l e r

c o n t r o l l e d

1 . .

1 . .

u s e d " y

u s e r

1 . .

1 . .

a c c e s s o r

a c c e s s e d " y

% a n a g e m e n t

& e v e l

' s e r & e v e l

( ) e c u t i v e

& e v e l

D e p l o y m e n t

& e v e l

! e 0 i s t r 7 a n a 0 e r

1 . . 1 . .

c o n t e n t % a n a g e r

s y s t e m % a n a g e r

1 . .

1d e c i s i o n * u t + o r i t y

d e c i s i o n R e ! u e s t e r

Figure 1 3ole of :rgani0ation in register management ;$#: 1


26/52


27/52

&e conceptual #ie' of ontologies can greatly inform t&e creation of go#ernance

mec&anisms to deal 'it& data modeling #ocabulary de#elopment and re4use.

&e ontology community classifies ontologies into t&ree main types )pper le#el used for broad disco#ery e-amples include #ocabularies 'it&in

t&e +lobal C&ange aster Directory =+CD>

Core le#el relating to common be&a#ior and business process

Domain le#el focusing on t&e data content and &o' its described

&is stratification of conceptual space into distinct le#els of abstraction pro#ides a

natural frame'or! for t&e go#ernance of semantic aspects of interoperability.

&e )*(DI 'ill notbe dri#en by t&e de#elopment of an ontological frame'or!.

@o'e#er an ontological viewcan be automatically e-tracted from a co&erent set ofreusable patterns supported by reusable resources. &is ontological #ie' 'ill en&ance

t&e disco#ery function and probably t&e ability to orc&estrate t&e use of multiple

ser#ices to access and process data.

It is beyond t&e scope of t&is document to discuss t&e roles t&eories and toolsets of

ontologies.

3$ >e0ac sstems and mi0ration

3$$# 1urrentl hetero0eneous sstems

&e )* system landscape is &eterogeneous and is a be&a#ioral artifact a function of

)* culture and organi


28/52

anagerial support and funding 'ill be reuired to ac&ie#e t&is ma"or conceptual

s&ift. /'areness raising education return on in#estment =:OI> studies 'ill all be

reuired to communicate t&e business case for mo#ing to a ser#ice model and to

generate sufficient political 'ill and organi approac&es using 'eb ser#ices &as been

identified as t&e tec&nology paradigm for )*(DI implementation. &e tec&nical

go#ernance c&allenges related to building and sustaining an (O/ are addressed by t&e

tec&nical go#ernance frame'or! as outlined in section 7.

@o'e#er t&ere are also significant organi


29/52

&ese reuirements s&ould accurately reflect sta!e&older consensus regarding t&e

critical business needs t&at t&e system must address

6$# 1urrent situation and need for chan0e

Currently in order to s&are resources pro#iders and users of resources negotiatebilateral arrangements. &ese are ad &oc costly =especially in time effort and s!ills

capacity> to negotiate and cannot be found and re4used by ot&ers. 8igure 2 belo'

illustrates t&is situation

Figure Current arrangements for s,aring resources

If t&is situation is #ie'ed across multiple agencies t&e situation rapidly becomes

un'or!able.

Figure ! 2ultiple bilateral agreements ;td 2%


1ount

Governments

1ivilian,0encies

State

Govts

Tri+al Govts

1it

Govts

Defence,0encies

1ommercial

Sector

>ocal UsersDoD

Users

Tri+al Users

StateUsers

?omelandSecurit

1ommercial

Users

1ivilianUsers

International Users

FederalUsers

Other standards-based portals

1urrent situation simplified

Documented validated

information


30/52

&e creation of a s&ared infrastructure is t&erefore necessary to rationalise and

impro#e access to resources. &is is ac&ie#ed by a pro#ider publis&ing resources

using t&e capabilities pro#ided by an infrastructure. &ese capabilities include

reusable resources and precedents from many similar acti#ities suc& as soft'are

tools data models access policies data uality procedures metadata descriptions

conformance testing tools disco#ery aids etc>. &e infrastructure t&en supportsmultiple users disco#ering and re4using t&ese resources. &is pattern is illustrated in

8igure % belo'.

Figure / T,e publis, an& re"use pattern

&e same publis& and re4use pattern can also be applied to sol#ing problems of

interoperability bet'een infrastructures i.e. t&e ability for users from one (DI to find

and re4use resources t&at &a#e been publis&ed 'it&in t&e operational conte-t of a

different (DI. &is is illustrated in 8igure 5 '&ic& s&o's t&e relations&ip bet'een t&e

)*(DI and an (DI t&at is a EmemberF of t&e )*(DI.

Figure 4 Publis, an& re"use pattern between #D$s

:esources in t&e conte-t of t&is discussion include agreements about &o' t&e

infrastructure be&a#es as 'ell as t&e data access ser#ices t&at e-pose data products

t&at are t&eraison Aetreof t&e infrastructure.

(ome e-amples of t&e type of agreements about infrastructure be&a#iour include

service specifications an& profiles4 agreements adopted by t&e community

about ser#ice specifications and conformance profiles to be used '&en building

and publis&ing ser#ices



31/52

&ata mo&els 4 de#eloped and adopted by t&e community and used 'it&in data

products

portraal rules4 for map products.

registers of governance actors tpes 4 lists of t&e actors in#ol#ed in

go#ernance of t&e infrastructure and t&e roles t&ey play so t&at sta!e&older can

find out '&o to contact regard a specific data model or a uery &o' to subscribe to

and publis& resources to t&e infrastructure.

&is need to de#elop and promote a #ariety of standards t&at enable s&aring of

resources &as been clearly articulated by )*(DI sta!e&olders =see Box 7>. &is

reuirement necessitates go#ernance mec&anisms and resources.

Box 7 ) clear nee& for stan&ar&s

&e y(DI1 initiati#e aimed at capturing geospatial information access and dissemination

e-pectations. 9it& regard to e-pectations of t&e )*(DI regarding standards t&e follo'ing

comments 'ere made

Promote use standards and common protocols and guidelines and recommended standards

for data s&aring =)*@C:>

ncourage proprietary systems to ad&ere to interoperability standards =)*OC@/ 8I(>

/d#ocating of standards by ob"ecti#e e-ternal body and promotion of simple standardised

data access policy templates =)*P>

Promotion of metadata standards and ensure support for future data and ser#ices

=)*O(/>

6$ General re9uirements

&e goal of t&e go#ernance frame'or! is to reduce organi is t&e go#ernance of

artifacts t&at describe or are an implementation of interoperability agreements =and

e-pectations> bet'een sta!e&olders 'it&in an (DI and bet'een (DIs.

&e entire go#ernance frame'or! must be scalable based on resource a#ailability and

commensurate 'it& t&e #olume of resources =data ser#ices and agreements> t&at are

being go#erned.

It is anticipated t&at t&e s&ort and longer4term go#ernance configurations 'ill be

different as t&e c&allenges and resourcing le#els 'ill c&ange as t&e infrastructuregro's. &e go#ernance approac& t&erefore must offer a means of creating common

t&reads bet'een s&ort and long term reuirements.

&e go#ernance frame'or! needs to be fle-ible and adapti#e and ensure t&at it is able

to easily go#ern and adapt itself =structure organi to meet

c&anging organi


32/52

disco#erability of agreements implies a go#ernance frame'or! t&at deals 'it& all

aspects of t&e agreement lifecycle

Identification

Creation

/doption

@armoni

odification and retirement

In addition management of t&e artifacts t&at describe t&e agreements 'ill also be

reuired so t&at t&ey can be disco#ered and used.

6$$ Intra'SDI 0overnance re9uirements

In addition to t&e go#ernance of agreements bet'een (DIs t&e )*(DI go#ernance

frame'or! 'ill also need to address t&e internal operational go#ernance c&allenges of

indi#idual (DIs comprising t&e )*(DI.

:at&er t&an duplicating effort to re4create agreements bet'een sta!e&olders 'it&in an

(DI it is proposed t&at agreements are in&erited from e-isting (DIs and adapted as

reuired.

It is anticipated t&at many of t&e agreements reuired to establis& a =)*>(DI instance

'ill be adopted from e-isting (DIs 'it& '&ic& t&e (DI 'is&es to align itself. &e

standards may need to be adapted to t&e conte-t of t&e (DI and t&e adapted

agreements 'ill need to be managed =publis&ed accessed and used> 'it&in t&e (DI to

ensure conformance.

6$ Governance of data model and harmoni=ation processes

Data model &armoni


33/52

I*(PI: recently de#eloped a draft Aet&odology for t&e De#elopment of Data

(pecificationsB '&ic& articulates a process for addressing data model &armoni.

o- $ I*(PI: met&odology for t&e de#elopment of data specifications

&e recently publis&ed I*(PI: draft met&odology for t&e de#elopment of dataspecifications outlines a process for data &armoni . &e steps of t&isprocess are

Capture user re8uirementsdescribed as use cases and application scenarios.

)nalsis of current situationcarried out in parallel to user reuirements to assist in

identifying t&e rele#ant data &armonisation aspects.

+ap analsisto identify user reuirements t&at cannot be met by t&e current data

offerings

8or eac& gap a data ,armonisation approac, is de#elopedand agreed.

)pplication sc,emade#eloped to document t&e approac& to filling gaps .

o (c&ema describes reuired spatial ob"ect types ='it& constraints properties>o Described in a conceptual sc&ema language );.

Development of &ata specification comprising

o /t least specification scope data product identification data content and

structure reference systems data uality data product deli#ery and

metadata.

o Optionally information on maintenance data capture portrayal

o /pplication sc&ema =abstract4le#el in );>

o 8eature catalogue

o +; application sc&ema =implementation4le#el in ;>

Testing data specifications tested 'it&in a pilot under real 'orld conditions.

2onitoring4 trac!ing costs0benefits of &armonisation efforts

6$& ,rchitectural 0overnance

&e arc&itecture of t&e )*(DI is t&e mec&anism to ensure t&at t&at eac& component

reuired is identified and t&at eac& component is properly designed to fulfill a certain

role. It also pro#ides for practical engineering and tec&nology c&oices to be made and

related bac! to t&at basic need. &e reality is t&at tec&nology c&anges data #olumes

gro' users c&ange o#er time and better ideas 'ill emerge.

&e )*(DI 'ill e#ol#e o#er time. Qet t&ere 'ill be an ongoing need to assess t&e

best 'ay to accommodate ne' c&allenges and opportunities as 'ell as communicate

to sta!e&olders t&e current recommended practices.

In particular a successful )*(DI 'ill engender creation and integration of many

related (DI implementations '&ic& 'ill continually test and refine t&e o#erall

arc&itecture. 8or e-ample an initial arc&itecture for t&e )*(DI and !ey cluster

acti#ities 'ill need to e#ol#e into one t&at supports and integrates national (DIs.

/dditional sub"ect domains 'ill bring different types of data and processing.

&e arc&itecture becomes a contractbet'een t&e implementers of systems and t&e

)*(DI t&at t&e systems can be built in a 'ay '&ic& 'ill 'or! 'it&in t&e broader



34/52

system. /nalysis of t&is 'it&in a single domain 'it&in a single "urisdiction &as

clearly identified t&e general nature of t&is problem.

&e )*(DI tec&nical go#ernance frame'or! s&ould t&erefore ensure t&at an agreed

notional arc&itecture can be de#eloped and maintained t&roug& effecti#e go#ernance

mec&anisms to ensure a s&ared arc&itectural #ie' of t&e )*(DI.

Box < T,e )ustralian :cean Portal #D$ " Nee& for a s,are& arc,itectural view

:eflections on t&e e-periences of de#eloping an /ustralian Oceans Portal =8inney 27>&ig&lig&ted t&e need to maintain a s&ared arc&itectural #ie' of t&e infrastructure. &is s&ared

#ie' is reuired to mitigate t&e ris! of loss of arc&itectural and tec&nical co&erence due to

c&anging system reuirements as t&e system and its users mature and t&e de#elopment and

di#ergence of sub4infrastructures based on competing standards.

It is crucial t&erefore t&at t&e arc&itecture itself includes maintenance functions for t&e

arc&itecture and t&at t&e functions are properly resourced 'it& bot& go#ernance

mec&anisms and a permanent capability t&at can be called upon to address needs ast&ey arise.

&ese needs 'ill occur across all t&e acti#ities in de#eloping t&e )*(DI but in

particular

De#elopment of data models

Design of core ser#ice types

/ddressing engineering aspects of scalability

#aluating role of ne' tec&nologies

Dri#ing impro#ements to tec&nologies

Design and go#ernance of content =#ocabularies>

Design of purpose4specific (DIs

Design of capability toolset for national (DIs

8or e-ample t&e integration of numerical models or decision support tools into t&e

)*(DI to meet a particular domain need 'ill propagate into an e-tension of t&e

arc&itecture so t&at t&ese capabilities can be broadly e-ploited. &is e-tension 'ill

t&en be a#ailable to en&ance national (DIs or more li!ely specific systems 'it&in t&e

national "urisdiction. (uc& a problem reuires a co&erent approac& for describing t&e

ser#ices data models etc as 'ell as ability to communicate t&e en&anced capability of

t&e )*(DI.

&e criticality of t&is tas! and t&e broad range of tec&nical s!ills reuired means t&at

a permanent capability needs to be establis&ed as a )*+I9+ standing tas! group for

e-ample 'it& specific responsibilities and resources allocated to be bot& proacti#e

and responsi#e to sta!e&older needs.

UNSDI Technical Governance Framework Proposal 3%Preliminary Report v1.1


35/52

PART 3 - PROPOSED SOLUTION

&e solution section of t&e document contains four sections. &e first section pro#ides

a conceptual o#er#ie' of t&e go#ernance frame'or!.

&e second section presents a proposed solution from a number of different

perspecti#es. &e section focuses on t&e identification and description of t&e critical

go#ernance functions t&at enable t&e creation of t&e )*(DI and an identification of

t&e !ey actors '&o e-ercise t&ese functions as 'ell as t&eir roles.

&e t&ird section describes a process of mapping registry management roles to

institutional entities. &is 'ill enable t&e tec&nical go#ernance tas!s to be assigned to

organi '&ic&

describe different aspects of t&e system suc& as business information and enables

readers to assess t&e solution from eac& of t&e different dimensions.

(ta!e&older re#ie' of t&e proposed solution and t&e reuirements pro#ides animportant opportunity to assess '&et&er t&e proposed solution addresses t&e

articulated reuirements.

:$ Governance framework ' conceptual overview

:$# Introduction

&is section &ig&lig&ts t&e !ey aspects of t&e go#ernance frame'or! elaborated in

more detail in t&e subseuent sections.

Conceptually t&e design of t&e go#ernance frame'or! is based upon t&e I(O 1,135conceptual model of registry management. &e frame'or! is presented as a series of

use cases based upon a conceptual (DI model =notional arc&itecture> t&at reflects t&e

underlying reuirements of t&e )*(DI informed by past (DI implementation

e-perience. It is proposed t&at t&is notional arc&itecture be de#eloped as a reference

implementation in its o'n rig&t fully elaborated and refined t&roug& (DI

implementation pro"ects as a priority 'or! plan item and publis&ed as a reusable

template.

@a#ing identified t&e go#ernance use cases actors =t&e E'&oF> and roles t&at t&ey

perform =t&e E'&atF> t&e details of &o' go#ernance is implemented can be elaborated.



36/52

Conceptually t&e )*(DI go#ernance frame'or! comprises t'o separate but

integrated tiers of go#ernance

4 inter"#D$ governance enabling interoperability bet'een (DIs t&roug& t&e

creation and management of registers of )*(DI resources

4 intra"#D$ governance dealing 'it& t&e tec&nical go#ernance of (DI

instances created 'it& t&e )*(DI

&e go#ernance frame'or! assumes t&at

4 &e )*(DI go#ernance institution 'ill rely &ea#ily on t&e delegation of

responsibility for creation and maintenance of (DI resources

4 Operational go#ernance of components s&ared across =)*> (DI instances 'ill

be delegated by t&e )*(DI

4 &e #ariety of roles necessary to operate registries and registers are li!ely to

need to be delegated

4 /n arc&itecture toget&er 'it& use cases =t&at also address go#ernance> can be

re4used as a template by agencies or community t&at 'is& to create (DIs

'it&in t&e )*(DI

:$ inter'SDI 0overnance

&is set of go#ernance capabilities aims to ensure interoperability bet'een (DI

instances and includes

Policies rules procedures processes and tools for t&e management of entire

lifecycle of artifacts t&at describe interoperability bet'een (DIs

/ go#erned common reference arc&itecture

:$ Intra'SDI 0overnance&e )*(DI is concei#ed as being a #irtual system comprising a constellation of

indi#idual (DIs. &ese (DIs 'ill be created indi#idually or collecti#ely by )*

agencies or business units to meet s&ared geospatial business needs. It is anticipated

t&at t&e )*(DI 'ill act as an enabler for *ational (DIs =*(DI> creation particularly

in de#eloping nations t&at 'ill also become part of t&e )*(DI constellation.

&e focus t&erefore of internal =intra4(DI> go#ernance is on t&e creation and operation

of s&ared resources =agreements ser#ices data> 'it&in an (DI. &e (DI notional

arc&itecture =illustrated by reference implementation=s>> is intended to act as a

template for (DI creation and 'ill include a modular re4usable template for internal

go#ernance of t&e (DI instance.

&e use of a common arc&itecture 'ill ensure t&at =)*>(DI instances t&at are created

interoperate 'it& eac& ot&er. In addition interoperability 'it& e-ternal (DI =beyond

t&e )*(DI boundaries> 'ill be ensured by t&e inter4(DI interoperability go#ernance

acti#ities.

*$ The UNSDI proposed solution

Gey components of t&e )*(DI =t&at address critical business needs of t&e sta!e&older

community> are presented in t&is section. /s noted earlier it is not possible to designa go#ernance frame'or! in isolation as ob#iously t&ere 'ould be not&ing to go#ernR



37/52

&erefore t&e solution proposes t&e de#elopment of t&e minimum reuired

capabilities namely a &ig&4le#el notional arc&itecture for t&e )*(DI toget&er 'it&

some of its !ey components.

&e proposed solution is described using elements of t&e Open Distributed Processing

:eference odel =:4ODP>11.T*e RM-ODP i# $! i!"e%!$"i!$0 #"$!&$%&+% $%'*i"e'"i!; pe!4 &i#"%i/"e& p%'e##i!; ##"e.# $!& p%vi&e# $'!'ep"$0 +%$.ew%< +% /i0&i!; &i#"%i/"e& ##"e.# i! $!i!'%e.e!"$0 .$!!e%)

T*e #e + "*e RM-ODP p%vi&e# $ w$ + "*i!Identifies possible tec&nical artefacts for engineering

mec&anisms computational structures information structures and enterprise

structures '&ilst being as independent of t&e ot&er four #ie'points as possible.

8urt&er refinement of t&e ec&nical +o#ernance 8rame'or! is reuired based on

elaborating t&e enterprise #ie'point t&roug& t&e de#elopment of A)se CasesB t&at

describe reuired go#ernance functions of t&e )*(DI.

@o'e#er to de#elop t&e use cases a notional arc&itecture =based on t&e arc&itecture

e-pressed in t&e )*(DI Compendium> &as been posited. Gey elements of t&enotional arc&itecture are described in t&e enterprise information tec&nology and

computation #ie'points.

&e 'or!4plan t&at is presented in section 1 describes a number of pro"ects t&at

build different dimensions of t&e )*(DI. ac& of t&e pro"ects addresses issues or

c&allenges described in t&e :4ODP #ie'points

*$# 5nterprise viewpoint

&e )*(DI go#ernance structures 'ill be establis&ed around a set of erms of

:eference for t&e /ctors identified in a set of publis&ed )se Cases.

11I(O0IC 17%



38/52

&is approac& allo's for management of t&ese roles and responsibilities t&at 'ill

ensure critical aspects are properly documented and effecti#ely assigned to

appropriate )* bodies.

&e set of actors and )se Cases 'ill be fully documented as a priority acti#ity infollo'4on acti#ities. @o'e#er it is clear from analysis of best practice t&at t&e general

nature of t&e arc&itecture and roles are common.

Identifying and placing under appropriate go#ernance t&e commonality of t&e

arc&itectures is one of t&e !ey acti#ities t&at establis&ment of a )*(DI 'ill underta!e

to enable more effecti#e (DI integration in future.

*$#$# Use cases

&e articulation of t&e !ey uses cases and actors is a critical step in t&e process of

elaboration of t&e go#ernance frame'or!. @a#ing identified t&e critical functionsnecessary to enable tec&nical go#ernance and t&e actors t&at e-ercise t&ese functions

it is possible to

Identify t&e agreements =and t&e artifacts t&at describe t&em> t&at need to be

go#erned

ap t&e actors and t&eir roles to institutional entities and0or specific agencies

and persons 'it&in t&e )*(DI pro"ect.

&e articulation of suc& )se Cases 'ill be a !ey component of t&e )*(DI

arc&itecture to be formali


39/52

complete reuirements but instead illustrate !ey representati#e aspects of t&e

go#ernance frame'or!. /dditional scenarios can be de#eloped at a later date to

#alidate t&e use cases and by inference t&e notional arc&itecture.

&e use cases focus on t&e go#ernance functions of t&e system as t&e end4user use

cases for (DI are pretty 'ell establis&ed. &e use cases co#er

Inter4(DI pac!age

Creation of @umanitarian (DI a )* (DI instance

Intra4(DI pac!age

Creation of a data product specification for transport data

(er#ice profile disco#ery and implementation

)se cases scenarios illustrate aspects of t&e )*(DI capability t&at t&e 'or!4plan

proposes to build. &e scenarios assume t&at certain capabilities of t&e )*(DI=primarily o#erarc&ing go#ernance )*(DI go#ernance frame'or!> are in place.

&ese o#erarc&ing mec&anisms are referred to in t&e scenarios in order to pro#ide

conte-t.

)se cases scenarios 'ill need to be more fully elaborated once t&e principles for

adopting t&is approac& &a#e been appro#ed by t&e )*(DI and t&e use case models

&a#e been more elaborated in more detail.

*$#$$# Scenario # ' 5sta+lishment of a humanitarian SDI

i% Backgroun& an& Context

OC@/ &as been tas!ed 'it& Cluster information management responsibilities at t&ecountry le#el. / significant dimension of t&is responsibility relates to geospatial data

management and pro#ision functions t&at need to be pro#ided.

In order to meet its geospatial data Cluster Information anagement obligations

OC@/ as 'ell as to pro#ide a s&ared platform for creation and management and

s&aring of geospatial data for emergencies OC@/ proposes to de#elop a &umanitarian

(DI =@)4)*(DI> under t&e umbrella of t&e )*(DI.

ii% $nitiation of t,e ?'2"'N#D$

8ollo'ing consultation 'it& !ey &umanitarian actors a proposal for t&e creation of a

@)4)*(DI is submitted to )*(DI oard by )*OC@/ on be&alf of t&esta!e&olders in t&e @)4)*(DI

&e )*(DI oard appro#es t&e creation of a @)4)*(DI. &e )*(DI anager

ad#ises t&e )*(DI registry administrator ='&o managers t&e !ey )*(DI registers

and registry> of t&e c&ange and a ne' (DI record is added to t&e register of (DIs

OC@/ de#elops a pro"ect proposal for t&e creation of t&e @)4)*(DI based upon

#ersion 2.5 of t&e )*(DI /rc&itecture t&at 'as do'nloaded from t&e rele#ant

register.



40/52

In accordance 'it& t&e go#ernance template contained in t&e arc&itecture a decision

is ta!en by t&e community to appoint a @)4)*(DI manager. OC@/ is duly

appointed to lead t&e @)4)*(DI initiati#e. In accordance 'it& t&e O: for t&is

role OC@/ establis&ed t&e follo'ing @)4)*(DI registers all of '&ic& 'ere

Eo'nedF by #irtue of its role as (DI coordinator

iii% ?um"'N#D$ 3egisters

:egister of @)4)*(DI participants and t&eir roles =i.e. t&ose agencies t&at

'ere signatories to t&e standard )*(DI O) and to t&e @)4)*(DI O).

and t&e roles t&at t&ey performed

:egister of data models being de#eloped

:egister of data modellers and initiati#es

:egister of community #ocabularies

:egister of ser#ice conformance profiles

:egister of ser#ices instances

iv% 3egister an& registr management

8ollo'ing community discussion and based on establis&ed )(DI go#ernance policies

it is decided t&at

&e management of E(DI participant registerF is delegated to t&e )*(DI

registry manager '&o manages t&e register of participants in ot&er (DI instances

as 'ell as participants in t&e )*(DI. &e register is t&erefore stored in t&e

primary )*(DI registry.

&e register of @)4)*(DI ser#ices =management of '&ic& &as been

delegated t&e )*(DI registry manager> is managed using t&e +eonet'or!

ser#ices registry. &is registry is used to manage t&e ser#ice registers of t&e ot&er

(DI instances establis&ed under t&e )* umbrella

a single registry 'ould be created to store t&e ot&er registers reuired by t&e

@)4)*(DI and t&at management of t&e registry 'ould be delegated to /gency

.

v% Control Boar&s an& #ubmitting organi0ations

Control oards and submitting organisations for t&e ne' registers are determined in

accordance 'it& t&e guidelines and go#ernance policy rules contained in t&e (DI

arc&itecture template.

8ollo'ing community discussion t&e follo'ing !ey (DI go#ernance roles 'ereassigned to specific agencies based on t&e template pro#ided in t&e )*(DI

arc&itecture L2.5

(tandards Coordinator Data =(CD> /gency /

(tandards coordinator (er#ices =(C(> 4 /gency

vi% ?'2"'N#D$ scoping

@a#ing establis&ed t&e go#ernance roles and associated mec&anism =registers and

registries> t&e @)4)*(DI pro"ect focuses on scoping t&e @)4)*(DI in terms of

data and functionality.

vii% Functional re8uirements

UNSDI Technical Governance Framework Proposal %Preliminary Report v1.1


41/52

)sing t&e )*(DI arc&itecture L2.5 t&e community identified !ey functional

reuirements and necessary components of t&e @)4)*(DI namely

/ portal to pro#ide

o access to registries 4 of ser#ice instance =for general users> and ot&er

registries =for specialised community users>

9eb4mapping functionality to #ie' sources of disco#ered datao to configure automatic updates for end users from capable data access

ser#ices

/ number of registers =outlined pre#iously>

/ number of 'eb ser#ices

o asic map portrayal ser#ices

o ransactional data access ser#ices to enable bi4directional

sync&ronisation of field and centralised copies of geospatial data =e.g.

ga

o Orc&estration ser#ices t&at integrate and process data from se#eral

sources to generate automatically updated situation reports

:eference implementations 'ere re#ie'ed to identify appropriate commercial and

O(( components to meet t&ese functional reuirements. &e reference

implementations also &ig&lig&ted t&e need for t&e de#elopment of specialised ser#ice

orc&estration functionality.

viii% Data re8uirements

In order to determine data reuirements for t&e @)4)*(DI a &umanitarian user

group 'as formed. &is group confirmed t&e recommendations of t&e OC@/ +I( and

+eospatial Data anagement Policy regarding t&e !ey data sets reuired for

&umanitarian response

T?3()D# :F T?( #T:3@ C:NT$N'(D

&e follo'ing scenario t&reads trace specific aspects of data and ser#ice design and

de#elopment process necessary to build t&e content and deli#ery elements of t&e

@)4)*(DI. &e scenario t&reads are intended to illustrate !ey dimensions of intra4

(DI go#ernance.

*$#$$ Scenario ' Data Product Specification ' Transport data modelin0

&e (tandards Coordinator for data =(CD> creates a number of t&ematic data teams

including one for transportation and appoints a team leader.

&e transportation data team leader first identifies rele#ant modeling initiati#es

models and modelers t&at e-ist 'it&in and outside of t&e )*(DI. (&e searc&es t&e

data model )*(DI participants register =to identify data modelers> #ocabulary

reference implementation registers using t&e searc& term EtransportationF

&e searc& re#eals

a transport data model =)*(DI4> de#eloped by 98P to support t&e

standardi


42/52

e-ternal transport modeling initiati#es including an I*(PI: transport data

specification de#elopment initiati#e

an draft I*(PI: transport data product specification

se#eral )* agencies 'or!ing on data modeling of ri#ers =part of t&e

conceptual transport data model>

(&e in#ites a number of data modelers to "oin t&e transport data modeling team.

&e )*(DI data modeling guidelines set by t&e (tandards coordinator are used to

de#elop t&e data model. &e guidelines 'ere based on t&e I*(PI: data product

specification met&odology

/n early draft of t&e I*(PI: transport data product specification toget&er 'it& t&e

)*(DI4 model are re#ie'ed as candidate standards.

/ re#ie' of t&e @)4)*(DI re#eals t&at it could not be adopted for t&e follo'ing

=indicati#e> reasons

(cope is too broad as it includes features t&at are included in ot&er )*(DIdata model pac!ages

(cope is too narro' in ot&er dimensions in t&at it does not address transport

realities in conte-ts outside of urope e.g. sub4(a&aran /frica

Data model structure and #ocabularies are too detailed for practical application

in emergency settings

&e team t&erefore decides to adapt t&e data model using t&e proscribed

met&odology> comprising t&e follo'ing steps

/rticulation of user reuirements t&roug& use cases and application scenarios

obtained from a broad range of domain e-perts and end user of bot& &e

information products and applications t&at produce t&em

+ap analysis to determine unmet reuirements and to meet t&em

odification of t&e data product specification

o odification of t&e conceptual data model using =in );> using a

standard profiling tec&niue informed by t&e )*(DI4 data model

o odification of t&e transport feature catalogue

o odification of t&e application sc&ema =e-pressed in +;>

o Creation of reference implementation in t&e form of +eodatabases for

users 'is&ing to adopt t&e data model as a storage model

est and refinement of t&e models

&e ransport data product specifications and its !ey facets =t&e conceptual model

application sc&ema features catalogue and reference implementations> are publis&ed

to t&e rele#ant registers.

*$#$$ Scenario & ' Service desi0n throu0h profilin0

&is scenario is intended to illustrate t&e process of de#eloping a ser#ice profile based

on specific user defined data needs. Gey steps in t&e scenario are

ased upon data product specifications pro#ided by (tandards Coordinator

Data =(CD> t&e (tandards Coordinator (er#ices =(C(> commences t&e

process of de#eloping a ser#ice specification to deli#er t&e data

UNSDI Technical Governance Framework Proposal %2Preliminary Report v1.1


43/52

(C( disco#ers e-isting ser#ice specifications used else'&ere in t&e )*(DI

using t&e register of registers and t&e ser#ice profile register

(C( assesses profiles and determines t&at specific constraints need to be

placed on t&e ser#ice metadata to ensure t&at a reuired application

=orc&estration ser#ice> is able to uery and filter data coming from a specific

ser#ice type &e (C( de#elops a profile and publis&es a draft in t&e register

/ ser#ices publis&er de#elops a test ser#ice based upon t&e profiles and

conformance tested using mac&ine readable profile obtained from t&e register

&e profile is refined to address semantic and tec&nical issues and tested again

8ollo'ing successful testing of t&e test ser#ice a production profile is

publis&ed to t&e register

*$#$$& Scenario 3 ' Service instantiation ' profile discover and implementation

&is scenario is intended to illustrate t&e process of disco#ery of ser#ice profiles by aser#ice pro#ider and t&e de#elopment and publication of an instantiation of t&e

ser#ice.

/ geospatial data manager in a )* agency 'is&es to publis& security incident

information to t&e recently establis&ed &umanitarian (DI.

&e geospatial manager using t&e register of registers registers of ser#ices profiles

and data models finds t&at t&ere is a ser#ice profile t&at meets &is need =a generic

9( profile for time4enabled point4based &umanitarian information>. &e manager

does not find a data model t&at could be used for security incident information. @e

t&erefore decides to utili


44/52

*$ 1omputational viewpoint

&e mec&anics of &o' components can be combined t&roug& interfaces is beyond t&e

scope of t&is frame'or!. In principle &o'e#er t&e frame'or! can and must be

capable of supporting an e#ol#ing suite of o#erlapping tec&nical solutions since

8unctional capabilities e-ist using disparate tec&nologies

Con#ergence on a smaller set of options 'ill ta!e time

Only in certain cases 'ill tec&nical solution be mandated

(ome tec&nology platforms are better suited for certain applications.

/ gi#en considering t&at multiple sta!e&olders 'ill be in#ol#ed is t&at net'or! based

data access is necessary and t&us a (er#ice Oriented /rc&itecture is reuired. It is not

considered feasible or desirable to create a common operating platform across

multiple agencies 'it& common infrastructure. &e cost of planning suc& a concept

'ould d'arf t&e implementation costs of a loosely coupled standards4based solution.

&e go#ernance of a multi4agency (O/ solution is &o'e#er an immature field of

endea#or.

It is e-pected t&at t&e O+C 9eb (er#ices specifications 'ill form a significant #endor

neutral platform for many ser#ices. &is is appropriate because t&e O+C pro#ides a

formal go#ernance process for t&ese standards. &e O+C standards t&emsel#es to an

increasing degree form a layer on top of baseline I8 and 93C standards.

*$& 5n0ineerin0 viewpoint

&ere 'ill be practical considerations regarding t&e distribution and deployment

arc&itecture of t&e )*(DI. Data 'are&ouse and distributed point4of4trut& &a#e

distinct ad#antages and disad#antages and it is e-pected t&at a &ybrid solution 'ill be

reuired. (ignificant furt&er effort is reuired to analy for

!ey actors 'ill need to be defined. One of t&e ma"or tas!s of go#ernance actors is t&e

UNSDI Technical Governance Framework Proposal %%Preliminary Report v1.1


45/52

management of registers. &e follo'ing section describes t&e process of mapping

roles in registry management to organi 'ill need to be determined as part of t&e go#ernance

frame'or! initiation.

@$ 7appin0 roles to or0ani=ations

:egisters are t&e !ey enabler to interoperability in a distributed en#ironment as t&ey

enable resources to be publis&ed disco#ered and used. / !ey responsibility of t&e

go#ernance actors 'ill be to manage t&e registers t&at list t&e artifacts =agreements

and t&eir implementations> t&at underpin information interoperability.

/s outlined in t&e I(O 1,135 conceptual model for registration of items of geograp&ic

information t&ere are a number of roles in managing registers. It is clear t&at in most

cases t&e Eo'nerF of a register 'ill be t&e actor fulfilling t&e go#ernance role beingenabled by t&e register. @o'e#er ot&er roles suc& as register and registry manger

=delegated by t&e register o'ner> submitting organi


46/52

community. &e pro"ects build different dimension of t&e )*(DI capability. &ese

discrete pro"ects also enable t&e step'ise creation and e#olution of t&e go#ernance

capabilities t&at 'ill be de#eloped in parallel. &is approac& reflects t&e resource

constraints and tests t&e concept of adapti#e go#ernance as t&e infrastructure gro's

Critical dependencies bet'een pro"ects 'ill need to be analy


47/52

#%$$ 1reation of UN SDI instances

&e aim of t&is pro"ect is to establis&ment of a number of representati#e =)*>(DI

instances to meet clearly articulated business needs of specific communities and

t&roug& t&eir implementation demonstrate interoperability bet'een t&e (DIs. In

addition to components of t&e o#erarc&ing )*(DI =e.g. aggregation ser#ices> t&at

may be reuired (DI instance test cases s&ould reflect t&e 'idely di#ergent needs ofdifferent communities 'it&in t&e )*. (uggested test cases s&ould include

;ocal emergency response (DI e.g. to &umanitarian (DI

+lobal monitoring (DI e.g. en#ironmental )*P

Capacity building e.g. e.g. t&e proposed Pa!istan Pro#incial ap

Proposed UNSDI Tech Gov Framework

Documents