Architectural Issues for an Enterprise Wide GIS

Architectural Issues for an Enterprise Wide GIS

Bryan HallCIPS/GCM Chief System Architect2004 GeoBase Compass Conference

2

Scope of Briefing

Intro: What is meant by Enterprise GIS? Identified Mission Needs Data Security Data Aggregation Data Replication or Data Reference Business Logic Location Enterprise GIS Tiers Traditional GeoBase Architecture and Web

Enterprise Architecture Differences Summary

3

Intro: What is meant by ‘Enterprise GIS’?

The Term ‘Enterprise’

What does Enterprise mean to you?

Common answers: An enterprise is a very large organization

An enterprise is an organization in more than one location

4


The Term ‘Enterprise’A comprehensive definition by Enterprise Systems Journal:

“…an enterprise is a centrally-based… computing network that receives input from and interacts with every aspect of a company or institution – although not always on equal levels. This multi-tier network consists of multi-platform hardware and multi-vendor software that needs to be integrated with departmental level systems, with remote offices and mobile users.”

5


Enterprise + GISSo what does the Geo-spatial in GIS really add to Enterprise Information Systems?

Spatial-processing: spatial relationship answers, and enforcement of those relationships Spatial-visualization: “maps”

Existing 14" Duct

Existing 6" Inner-duct

NEW 8" Inner-duct1. A Valid Size

2. Contained within a duct

3. Overlaps other Inner-ducts!

-> Reject insert <-

6

Identified Mission Needs

Spatial infrastructure (data, processes, people) Garrison + Expeditionary (Warfighter) Use:

The right applications with the right information to the right person with the right levels of security to do the job right now on a (desktop, laptop, PDA / phone)

Digital, Referenced, SDSFIE formatted, Complete, Fresh, Qualified Data

24/7 Availability (reliability, recoverability, serviceability, and manageability)

Controlled access for on-net and data extraction: PKI global certificate directory for authentication Purpose controlled roles for authorization Support for multi-level data classification

7


Hands-off “Data-call” in support of: NORTHCOM Project Homeland Etc.

Global access (one source – i.e. GIG) End-to-end (not point to point) security Port 443 web protocols for firewall environment access Global catalog support Vendor-neutral web services: WMS, WFS, GML, XML, etc.

8


Quality Assurance for: Metadata: Searchable, parsed, rolled-up XML Chain-of-custody: Source lineage, timestamp: by row

Geographic and Projected data support: Multiple incoming sources and formats (state-plane grids

in feet or meters, UTM tiles, etc.) Output in whatever format is required (WGS84, UTM tiles,

state-plane grids, polar, etc.)

Design it to work with the Air Force Portal Provide a lower TCO than the Desktop GIS model No Silos of Data – GeoSpatial data must be shared

and reused: NSDI (Executive Order 1296)

9

Data Security

Data Security, Data Security, Data Security!

Data is the most costly asset within any organization Data is the GIS – without data, all you have are applications

“Cost - acquisition and life cycle (initial investment) Price - against risk and investment (return) Re-use - with metadata and characterization (leverage factor) Measurable consistency - from project to project (data integrity)

Evolving - quality decision data (KM or collaborative quality, use, and outcome)”

From From Data Management and the CMM/CMMI: Translating Capability Maturity Models to Organizational FunctionsData Management and the CMM/CMMI: Translating Capability Maturity Models to Organizational Functions Cynthia C. Hauer Cynthia C. Hauer

10

Data Security


Two spatial classes of data have been identified as critical infrastructure items and must be closely guarded:

CE Utilities Communications

When aggregating any data from installations into an Air Force Enterprise GIS, security is paramount

Desktop and Workgroup solutions may not meet Enterprise needs, especially in the arena of data security – choose the right tool for the job based on requirements

11

Data Security

How does one secure data, at an Enterprise level?

Leverage the existing Air Force LDAP (Active Directory) NOSC user-rights management investment

Leverage the Air Force PKI CAC-Card and certificate servers to ensure authorized users

Don’t try to re-invent user identity and rights management – reuse what is already there

12

Data Security

Use an Enterprise database and application server that is:

Federal Information Processing Standard (FIPS) 140-1 Certified at Level 2 (highest level for software)

ISO 15408 Common Criteria Certified at EAL4 – Mandatory Access Control (MAC) for multi-level data storage (i.e., classifications, tenant > installation > MAJCOM > DOD Dept.)

13

Data Security

What products fit those criteria?

Oracle Enterprise Database with Label Security Oracle Application Server

Select GIS components that can pass LDAP security credentials from the client to the database session context, providing end-to-end security:

I.E. eSpatial iSmart Server with Oracle Application Server

14

Data Security

Mitigate data aggregation issues by tagging each row of the database with GEOLOC, MAJCOM, and USAF codes so that data views can be limited to one location, MAJCOM, or USAF (for use within DISDI) – and enforced by Oracle label security

Provide data filtering at the attribute level by replacing sensitive data with NULL values

Support historical (temporal) views of data – don’t just overwrite data

15

Data Security

Transport all data across the network using encryption with non-repudiation (i.e. SSL with MD5)

KEY – If you leverage secure certified data products, applications can ask for data the user is not allowed to access. You are still secure because that request will be denied

16

Data Aggregation

Currently if you roll up installation spatial data you get 200+ silos of spatial data in various “projections” using multiple SDSFIE interpretations with differing amounts of attribution and additional attributes…

Installations

MAJCOM MAJCOM MAJCOM MAJCOM

USAF

17

Data Aggregation

Q: Using this present form of “data call” aggregation, how would AF Comm. determine how much lead-covered cable there is at each base, in feet?Open 200+ databases, re-project the data into a common format, and search each adding up the data and recalculating the results?Ouch!

Installations


USAF

18

Data Aggregation

Better idea: aggregate the spatial databases using the built-in functions of a spatial database to transform “projections”, standardize naming conventions, and filter attributes so you can achieve the goal of ONE spatial database to answer MAJCOM or AF-Wide questions Standard IT “stuff”


USAF

19

Data Aggregation

Back to the question: How would you determine how much lead-covered cable there is at each base, in feet?

Simple: Use standard SQL-based database report generation tools (that already exist) to query the cable sheath table looking for lead type sheaths, ask the database to report the length in feet, and sum by GEOLOC code One SQL statement!

KEY - Use the right existing tools for the job

20

Data Replication orData Reference

What is the difference?

Both are copies of the original data but:

Referenced copies assume that the data will “evaporate” once consumed or when the network connection is closed

Replication copies do not “evaporate”, but continue to exist until they are replaced or updated

21


For data that is required to operate (such as background CIP data for an MDS), the best approach is to replicate (or copy) the data.

Pros: Readily available local data source Scheduled WAN bandwidth use (during lower-use periods) Scheduled use of source data services (during low use periods) Available “stale” data even if a copy window is missed Data redundancy

Cons: Few – small overhead to add “last update” timestamp to all rows

of data

22


Clearly, the simplest and most optimistic way to use external data is to just reference it. This is the service model on the GeoBase “to-be” architecture stage. Data reference is the way to go for low-impact “additional information”.

Pros: One, original set of data Always “up-to-date”

Cons: Depends entirely on the availability of the data, from all sources,

all of the time. No added redundancy

23

Business Logic Location

Should it be in the application tier?

Should it be in the data resource tier?

If you want to integrate data with other IT systems, you MUST place some business logic at the data tier to ensure only valid data is accepted

If you want to have highly interactive GUI applications, you MUST place some business logic at the application tier

If you want to use occasionally disconnected applications for field use, the business logic MUST exist in the application

24

Business Logic Location

Should it be in the application tier?

Should it be in the data resource tier?

The answer is “YES” – put the logic where it is required.

The old adage, “measure twice, cut once” applies to data as well as lumber. It’s OK to check the data twice before accepting it!

If you chose a platform that can share common business logic libraries for both the application tier and data resource tier logic - they can both enforce business rules equally!

25

Enterprise GIS Tiers

N Tiers

An enterprise system is built crossing many tiers; each with its own function. These tiers when combined complete the path from data resources to client visualization.

Client – Visualization and interaction tier Presentation – Exposure to web services Application – Where the application and application

logic lives Data resource – Where data and data logic lives

26


Client Tier - ChoicesThere are basically three choices available: Fat (or thick) Thin Hybrid: Rich Internet Application (RIA)

None of the choices are inherently bad or good, but instead have their own strengths and weaknesses. Knowing what to use when is the key to a successful client experience.

27


Client Tier - FATPros:

Supports both connected and disconnected (off-network) use Rich interface Very flexible Local data caching Application performance depends mainly on local computer

speed and available network bandwidth (if data is not local)

Cons: Not centrally managed or configured Difficult to migrate environment between work centers or

computers Most expensive to license and maintain Usually tied to one specific operating system family making

customized extension portability difficult

28


Client Tier - ThinPros:

Good for including spatial data within IT web applications: Put a map in your IT App

Excellent flexibility on client choices due to web standards Centrally managed and configured Low network overhead Least expensive to license and maintain

Cons: Cannot be used in disconnected scenarios Data is not cached on the client Not very flexible Application performance depends entirely on web server speed,

server loading, and available network bandwidth Generally limited to a single source of data for data analysis

29


Client Tier - RIA (Rich Internet Application)Pros:

Good for including and editing spatial data for web applications Excellent flexibility on client choices due to web standards Centrally managed and configured Low network overhead Moderate costs to license and maintain Rich interface Local data caching Application performance depends mainly on local computer

speed, with minor application server use, and available network bandwidth

Cons: Maturity of software is not as great as the fat or thin clients

(newer architecture), although that is changing quickly

30


Presentation Tier

The web interface. This tier is the glue between the application logic in the application tier, and the client.

It abstracts the interface to the application server by leveraging the strength of load balancing, HA, etc. that are important to an enterprise application.

31


Application Tier

Where the application logic lives for thin clients

Handles requests from thin and RIA clients for data and interacts with the data resource store

Translates image XY coordinates back to real-world coordinates, creates images, and converts data from one format to another

32


Data Resource Tier (Database)

Where the data exists “lives”.

Use of spatial data objects allows enforcement of spatial data integrity for all applications.

33

Traditional GeoBase Architecture and Web Enterprise Architecture

Differences

Three uses of GIS technology within GeoBase:

Desktop GIS (editing) Thin-client GIS (web viewing) Mobile GIS (field)

34


Differences

Desktop – Editing

GeoBase: A Fat client application

Enterprise GIS: A RIA (Rich Internet Application)

Benefits: Centrally managed application No installation or local license required OS independent – runs in the web browser Use anywhere you have NIPRNET (or SIPRNET) access –

uses HTTPS for transport

35


Differences

Thin-Client GIS (web viewing)

GeoBase: A Thin client application – per installationEnterprise GIS: Thin client spatially enabled IT applications – AF

wide

Supported by the Enterprise GIS with the use of web services

Benefits: Centrally managed services that can be used by any number of

applications No installation or local license required Web based – DHTML, Images, JavaScript Use anywhere you have NIPRNET (or SIPRNET) access – uses

HTTPS for transport

36


Differences

Mobile GIS – Field Use

GeoBase: Usually an OS-specific “fat” client

Enterprise GIS: An offline version of the RIA Desktop Editor, whatever platform

Benefits: Code re-use (RIA and Offline editor) Simple installation – download, unzip, run OS independent – runs on almost any platform Extracts data from the Enterprise GIS service by ROI for offline

editing Easy re-synchronization of data when reconnected to NIPRNET

(or SIPRNET)

37

Summary

Key point – An Enterprise GIS must provide the right applications with the right information to the right person with the right levels of security to do the job right now… or it is of little use to anyone


Don’t reinvent IT tools under a spatial guise. Spatially enable them

38

Questions?

https://cipsaf.tinker.af.mil/38eigGIO/

Yes these digits do mean something – extra points for deciphering the text

Architectural Issues for an Enterprise Wide GIS

Technology

Transcript of Architectural Issues for an Enterprise Wide GIS