• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Architectural Issues for an Enterprise Wide GIS
 

Architectural Issues for an Enterprise Wide GIS

on

  • 701 views

 

Statistics

Views

Total Views
701
Views on SlideShare
701
Embed Views
0

Actions

Likes
0
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • RIA’s are somewhat of a hybrid of the fat and thin clients. The application software is not installed on the client; instead application components are downloaded from the application tier as required. The client application runs on both the client, and the application server, utilizing which ever is best suited for the task. Customization can be stored on either a database server, or as a local file used at runtime. Data can either be local, or on the network. The software license is shared with many other users on the application server(s). The RIA client provides a rich environment similar to the fat client and is only limited by what the RIA runtime engine (usually Java) supports. When accessing data over a network, this becomes a client / server type application, with the client typically connecting to the application server via a web service. The applications used are highly mobile, as anyone with a valid web browser, runtime engine, and security rights can gain access from anywhere on the network. Screen refreshes are resonably quick, due to possible use of a local data cache. For spatial applications, the RIA client is more than sufficient for editing, since application logic for data interaction can exist on the client as required.

Architectural Issues for an Enterprise Wide GIS Architectural Issues for an Enterprise Wide GIS Presentation Transcript

  • Architectural Issues for an Enterprise Wide GIS Bryan Hall CIPS/GCM Chief System Architect 2004 GeoBase Compass Conference FOR OFFICIAL USE ONLY
  • 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
  • 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
  • Intro: What is meant by ‘Enterprise GIS’?
    • 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.”
  • Intro: What is meant by ‘Enterprise GIS’?
    • Enterprise + GIS
    • So 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”
  • 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
  • Identified Mission Needs
    • 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.
  • Identified Mission Needs
    • 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)
  • 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 Data Management and the CMM/CMMI: Translating Capability Maturity Models to Organizational Functions Cynthia C. Hauer
  • Data Security
    • Data Security, Data Security, 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
  • 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
  • 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.)
  • 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
  • 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
  • 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
  • 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…
  • 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!
  • 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”
  • 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
  • Data Replication or Data 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
  • Data Replication or Data Reference
    • 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
  • Data Replication or Data Reference
    • 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
  • 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
  • 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!
  • 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
  • Enterprise GIS Tiers
    • Client Tier - Choices
    • There 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.
  • Enterprise GIS Tiers
    • Client Tier - FAT
    • Pros:
      • 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
  • Enterprise GIS Tiers
    • Client Tier - Thin
    • Pros:
      • 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
  • Enterprise GIS Tiers
    • 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
  • Enterprise GIS Tiers
    • 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.
  • Enterprise GIS Tiers
    • 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
  • Enterprise GIS Tiers
    • Data Resource Tier (Database)
    • Where the data exists “lives”.
    • Use of spatial data objects allows enforcement of spatial data integrity for all applications.
  • 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)
  • Traditional GeoBase Architecture and Web Enterprise Architecture 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
  • Traditional GeoBase Architecture and Web Enterprise Architecture Differences
    • Thin-Client GIS (web viewing)
    • GeoBase: A Thin client application – per installation
    • Enterprise 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
  • Traditional GeoBase Architecture and Web Enterprise Architecture 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)
  • 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
    • Data Security, Data Security, Data Security!
    • Don’t reinvent IT tools under a spatial guise. Spatially enable them
  • Questions? https://cipsaf.tinker.af.mil/38eigGIO/ Yes these digits do mean something – extra points for deciphering the text