SDI Framework

Feb 2011 | No Comment

The work of building Spatial Data Infrastructure is in progress all over the world. There are many challenges: governance,organisational, technical, data sharing, transitional and more. We present here the fi rst part of the paper.

Warwick Jones


New Zealand

Micahel Ellyett

Enterprise Strategic

Transformation &

Optimization (ESTO)

Auckland, New Zealand

Ngo Duc Mau

General Department of

Land Administration


Hanoi, Vietnam

“The first man who, having fenced in a piece of land, said, ‘This is mine,’ and found people naïve enough to believe him, that man was the true founder of civil society.” (from Discours sur l’Origine et le Fondement de l’Inégalité Parmi les Hommes, 1754, – Jean-Jacques Rousseau)

The building of ‘Spatial Data Infrastructure’ (SDI) is being undertaken all over the world. This work involves coordinating the development of the infrastructure needed to support: the maintenance of spatial information, the utilisation of spatial information in decision making and collaboration between various parties based on spatial information. These endeavours include a wide range of challenges: regulatory, governance, policy, institutional arrangements and agreements, organisation structure and roles, skills and capabilities, technologies and technical standards, transitional and project phasing.

The opportunity to use world best practice in establishing SDI should be available to everyone. Best practice needs to encapsulate the insights, lessons and experience from other nations and organisations involved in creating effective, self-sustaining modern land administration.

A national SDI (NSDI) can be considered to consist of a set of SDI’s traditionally oriented at different constituencies and purposes. So a national SDI is a meta-system that sits across these and ensures their coherence and usefulness. AN NSDI needs to ensure that in line with the strategies and cultures of those countries and their agencies, organisations, enterprises, people and society benefit

State and private sector organisations share the mandate to establish an NSDI. The State necessarily plays a foundational role in the establishment of key building blocks of NSDI suited to land administration, as the SDI needs to tie intimately to management of land tenure. A key requirement in NSDI design is sustaining the capacity of the public and private sector entities. As an NSDI extends a framework is necessary that allows the roles of all the parties involved to be understood as a whole, for the entities to evolve themselves and for sum to be melded.

In implementing an NSDI one needs to ensure it can evolve. This allows it to be extended to address all the users’ needs, though initially may only be focused on a narrow set of users. This evolution will be encompass renovation and innovation and involve improvements in design and implementation of operational support systems. The evolution of systems requires that the underlying purpose for the design of the systems and organisations are understood i.e. their experience is institutionalised and retrograde enhancements can be avoided.

The paper seeks to outline a framework for: expressing the natural boundaries of responsibility within an SDI; undertaking work in SDI that allows recognised best practice and standardised reference models to be used; managing the knowledge of why the SDI exists as it is as a basis for future extensions.

This framework ensures semantic precision (a series of increasingly precise definitions for data elements in knowledge representations) and allows easy case by case instantiation (e.g. by country, by culture). It relates patterns, principles, standards, building blocks, reference models and maturity levels and allows the adoption, emphasis or abnegation of the elements in the framework in each specific implementation.

This allows the framework to be common while each implementation is different with a mapping between the common framework and the specific implementation.

1. Analysis of the NSDI meta problem

NSDIs are complicated systems that relate to complex organisational structures. They are typically networks of systems, distributed and loosely coupled, in federated or discrete organisations, serving a multitude of purposes and audiences, support transactional and archival functions. They have all the complexities of traditional IT systems with additional concepts, data types and technologies that are not traditionally dealt in commercial solutions. So the NSDIs systems and the approaches for the implementation have the challenge of traditional large IT projects and additional challenges.

Many specialists in the area look at the specific or unique, technical, social and regulatory challenges of SDI systems. They fail often to realise that not all best practice needs to be reinvented and by focusing on the details there is a risk of not seeing the forest for the trees.

To address the problems effectively we need to learn from other complex disciplines better and recognise that many of the best practice that applies to these other information infrastructures applies to NSDI.

Specifically we could start by looking at the generic problems associated with the implementation of complex IT systems (especially in government).

The Royal Academy of Engineering and The British Computer Society observed that

“A significant percentage of IT project failures, perhaps most, could have been avoided using techniques we already know how to apply. For shame, we can do better than this.”

They go on to say:

“It is alarming that significant numbers of complex software and IT projects still fail to deliver key benefits on time and to target cost and specification. Whilst complex IT project success rates may be improving, the challenges associated with such projects are also increasing rapidly. These are fuelled in large part by the growth … in the capability of hardware and communications technology, and the corresponding inflation in people’s expectations and ambition.”

They examine how complex IT projects differ from other engineering projects, with a view to identifying ways to augment the successful delivery of IT projects. Amongst their findings and recommendations are:

– “A striking proportion of project difficulties stem from people in both customer and supplier organisations failing to implement known best practice. This can be ascribed to the general absence of collective professionalism in the IT industry, as well as inadequacies in the education and training of customer and supplier staff at all levels”

– The significance of systems architecture is not appreciated.

– Further developments in methods and tools to support the design and delivery of such projects could also help to raise success rates. In particular, basic research into complexity is required to facilitate more effective management of the increasingly complex IT projects being undertaken.

– There is an urgent need to promote the adoption of best practice amongst IT practitioners and their customers.

They also identify some things that we think most people have known for some time e.g. the need for good project management and risk analysis. However both of these tasks are significantly impeded if the underlying knowledge required for analysis is not available.

1.1 What issues does an NSDI framework address

The NSDI is a means to assemble geographic data nationwide to serve a variety of users. The framework is a collaborative community based effort in which these commonly needed data themes are developed, maintained, and integrated by public and private organizations within a geographic area.

The NSDI will provide a base or structure of relationships among data producers and users that will facilitate data sharing. The increased ability to share data through common standards and networks will, in turn, serve as a stimulus for growth. Building an effective NSDI will require a well coordinated effort among government authorities and academic institutions, as well as a broad array of private sector geographic, statistical, demographic, and other business information providers and users. Only through this cooperation will the NSDI become a reality.

In our view then an NSDI framework must help address these issues:

– improving collective professionalism

– by providing all parties a way of undertaking analysis, design and planning in an effective and professional manner.

– education and training

– by providing an explicit relationships between the outcomes, the procedures and systems, the organisations and roles, and the skills required.

– architecture

– by provide a template for defining: sector or industry (NSDI) architect, the enterprise architectures and systems architectures

– strategies for dealing with complexity

– by providing methods and tools that support the analysis, design and delivery of NSDIs

– promote the adoption of best practice

– it is too easy to speak of adopting best practice, everyone does, but in order to do this we really need to define what the elements of best practice are, how this knowledge is manner and provide a strategy for its adoption. That is what our SDI frameworks seek to do.

1.2 What capabilities does an NSDI framework need provide

It needs to allow federated group (of public and private sector) participants to do a number of things. In all cases the greater the transparency the better the result. Transparency helps people understand what and why they agree or disagree on things in an objective and unemotional manner. Reaching consensus is therefore easier. The capabilities include the ability to:

– Capture drivers and requirements – these are the things that determine what an NSDI should do. Each and every elements of an NSDI solution (roles, skills, technologies etc.) must derive from these;

– Undertake analysis – a simple structured way to analysis is required. Analysis can be organised around simple set of canonical model (Goals, Facts, Beliefs and Recommendations). Where: goals are things you are trying to achieve, sometimes expressed as principles, issues (goals stated the reverse), visions, measures, objectives or KPIs; facts are not disputable and include laws, regulations, social factors and technical constraints; beliefs are based on facts and relate to goals and include causes, findings, implications; and recommendations are based on beliefs and achieve goals and strategies, plans etc. In addition we would want some grouping concepts (classification systems) for: terms, patterns, principles, technologies, standards etc. By support business or analysis with this paradigm we move for persuasive narrative to structured reasoning;


– Design and decide – Designs are assemblages of elements. So we need to be able to record these things (and relate to externalities e.g. technologies). Design and decision making is made based on analysis of alternatives. So we have the information on drivers and requirements and are able to undertake analysis we can make explain the basis of decisions and designs;

– Plan, Programme & Phase – these require us to understand sequencing, prerequisites and co-requisites. Intrinsic is the relationship between the requirements and the designs;

– Promulgate, educate, communicate and socialise – we need to be able to very selectively extract information for the framework that is suited to a particular audience, purpose or interest. We don’t then need to manually reconstruct communication artefacts for each different purpose;

– Estimate the effort, costs, risk and timeframes associated with people, technology, procedures – in practice costs can only be effectively estimated by examining the proposed implementation i.e. the designs. But decisions need to be made related to the requirements and outcomes therefore we need to understand how the elements of the implementation relate to the requirements (and the marginal economic impact of each requirement);

– Support the validation, assessment, quality assurance and review – by making the above relationships explicit and transparent we provide a mechanism for doing this.

1.3 What is best practice (what can we learn from)

We can learn from a number of standards and approaches that are applied elsewhere by examining some existing methods e.g. ValIT (Val IT – is framework addressing the governance of IT-enabled business investments), COBIT (Control Objectives for Information and related Technology), OSIMM (Open group SOA Integration Maturity Model), CMMI (Capability Maturity Model Integration), FEAF (Federal Enterprise Architecture Framework), DODAF (Department of Defense Architecture Framework), TOGAF (The Open Group Architectural Framework), Zachman Framework , ITIL (Information Technology Infrastructure Library), IFW (Information FrameWork), DSM (Design Structure Matrix), Pattern Language (i.e. Alexander’s seminal work). These are from many disciplines e.g. engineering, architecture, portfolio analysis, defense, IT, etc.

Our approach to an SDI framework is informed by these sources and others. We can also see that a number originated in Government (and have subsequently been adopted in the private sector). The effectiveness of these approaches has in the past significantly impacted in most cases by their means of implementation (usually many documents and consultants). We need an approach that minimises the need for both.

Space does not permit a full review of all of these but we believe that there is general consensus that following seem to make good sense:

– Business case and investment models- FEAF, ValIT

– Reference Models- FEAF, OSIMM

– Patterns – DODAF, Pattern Language, TOGAF

– Principles – Pattern Language, TOGAF,

– Standards – TOGAF, FEAF, ITIL, OSIMM

– Taxonomies – DODAF, Zachman,

– Maturity models – CMMI, OSIMM, TOGAF (implied)

– Compliance mechanism – Cobit, FEAF, OSIMM. CMMI

– Different levels (of detail, of technicality) – Zachman, Pattern Language

– Instantiation – almost all of these frameworks allow instantiated instances

1.4 Additional organisational and process challenges

Government is usually implemented via a set of federated agencies – global, regional, federal, state and local. A Model for data sharing through Government agreement is the one negotiated between the Victorian Government and local government (LG). [Gruen]

With an NSDI we are also able to deal with evolving roles of both public and private sector organisations, and both national and international players e.g. range from Google to United Nations.

In addition to the normal challenges we are usually dealing with federated and distributed organisations. That is to say that we have a network of organisations with different responsibilities goals and agenda and we need to under the basis on trade-offs are made. The Netherlands Gideon project offers excellent direction.[Gideon]

Further there is increasingly there is a demand for open government: citizen-centric services (giving people access to their data about their land); open and transparent government (being able to say what is known about land); innovation facilitation (facilitating innovation by all parties on knowledge about the NSDI) Reference the ‘The three pillars of open government stated by the Australian Federal Government’ [Senator Lundy]

– Citizen-centric services

– Open and transparent government

– Innovation facilitation

We also need to deal with archival and reference requirements; and transaction and functional requirements. This has a number of implications including that we need to use information engineering oriented techniques and process oriented techniques for understanding things.

In the ideal world the vast majority of data in an NSDI system is accretes as a natural by product of transactional activities i.e. few additional costs (non-transaction related costs) need to be incurred. In a similar fashion that data that populates an NSDI frameworks need to accrete as a by product of the work on NSDIs that is undertaken. In both cases frameworks and taxonomies are required to make this possible and small adjustments to day to day processes are required to enable to occur.

2. SDI framework based on multidiscipline best practice

2.1 What analysis is enabled by semantic precision of the framework

There are two types of analysis that we want to be able to do. We call them referential and inferential.

Referential analysis allows us to confirm that the relationships between element are correct this allows us to follow a path of relationships i.e. if this skill is unavailable what is affected, if this goal is to be achieved what is required, what elements are affected by this projects.

When we look at this:

It allows us to quickly see:

Inferential analysis is useful when we have compositions or when we have reference models – where we can relate our implementation to the reference models. It allows us to infer what relationships should exist i.e. are implied to exist but do not. It allows us a check on correctness.

Reference models would usually be instantiated e.g. for example a functional (F) reference models indicates a function is performed, our instantiation would indicate how we perform it. A data (D) reference model indicates the data we need and our instantiation would indicate how we manage it exactly.

Let us say F >> F1, F2, F3 (i.e. F decomposes into F1, F2, F3) and D >> D1, D2 (i.e. D decomposes into D1, D2).

If D relates to F

We can tell that one or more of F1, F2, F3 must relate to one or more of D1, D2 i.e. in the follow diagram one of the red relationships must exist.

We can also tell that if F3 relates to D3

We should expect to see F relating to D.

While this seems obvious in this example when the relationships above are all described textually e.g. in a document inconsistencies are not so easy to see.

Even when they are dealt with graphically when there are large amounts of information (or multiple level of decomposition) these inconsistencies are hard to see. In both cases best practice would be to have systems do these checks (rather than checking for them manually).

To be concluded in March 11

My Coordinates
Mark your calendar

«Previous 1 2View All| Next»

Pages: 1 2

1 Star2 Stars3 Stars4 Stars5 Stars (29 votes, average: 1.90 out of 5)

Leave your response!

You must be logged in to post a comment.