Application Reference Model


Definition/Description (What) – is a mission/business driven functional framework that provides guidance and evaluation practices used to identify, document, classify, discover, deliver, and share geospatial application and service (App/Svc) capabilities. It provides the basis for categorizing IT App/Svc investments across an organization’s enterprise geospatial architecture.

Purpose/Function (Why) – as an organization documents and catalogs their current and planned App/Svc investments, gaps and redundancies will become evident, which will aid in identifying opportunities for sharing, reuse, consolidation, redesign, renegotiating or developing new sources. Organizations and enterprise architectures will benefit from economies of scale by identifying and reusing the best solutions and technologies for applications that are developed, provided or subscribed to support their mission, business functions and target geospatial architecture.[1] This section provides a process to document and leverage IT investment assets from a shared services perspective by:

  • Establish a process for base lining and documenting geospatial applications and services.
  • Providing an understanding of design principles for shared services.
  • Provide guidance for complying with Federal shared services policy.
  • Provide [limited] references to resources for shared applications and services.

Stakeholder Performance Guide (Who & How) –Executive Leadership and Program Managers responsible for policy setting and compliance, strategic program direction, resource planning and approval (e.g., fiscal and human), and Solution Architects for identifying, documenting, and sharing technical solutions for applications and services.This model helps managers or architects understand the geospatial services delivered by their organization, and others;

and assess whether there is an opportunity to group like services and create opportunities for reuse or shared services.



[1]Segment Architecture Analysis of the Geospatial Platform, Version 1.0, December 21, 2010. Federal Geographic Data Committee, in support of the Federal Chief Information Officers Council. Available at

Application/Service Reference Model(s) Approach

Federal Agencies are expected to implement the Federal Information Technology Shared Services Strategy[1] and make “Shared-First” the default approach to IT service planning and delivery. Geospatial Apps/Svcs are becoming “commoditized” to a level where users, including the general public, have come to expect these services to be readily available to them anytime, anywhere, on any device, at no/low cost. These expectations are impacting the way in which Apps/Svcs are designed, developed, and delivered. Federal Agencies must also eliminate wasteful spending that result from implementing duplicative solutions for mission, support, and commodity IT functions.

A review of over 7,000 Federal Agency IT investments reported to OMB for Budget Year 2013 revealed many redundancies and billions of dollars in potential savings that could be achieved through consolidation and a shared approach to IT service delivery within and between agencies.[2] Along the same lines, in 2011 the U.S. Government Accountability Office (GAO) identified thirty-four (34) areas where Federal Agencies provide similar services to the same customer groups within and outside of government, with billions of dollars in potential savings if these services were reconciled, consolidated, and moved to a shared delivery model.

The App/Svc Reference Model will focus upon a practical approach to documenting the  geospatial App/Svc requirements and capabilities within and across and organization to meet mission/business requirements as well as provide guidance for description, cataloging, sharing and Federal policy compliance. The App/Svc Reference Model is not:

  • A “how to” manual for building and maintaining applications and services.

  • A taxonomy for cataloging applications and services.
  • A definitive list of available applications and services.


[1] Federal Information Technology Shared Services Strategy, OMB, May 2, 2012,

[2] Federal Information Technology Shared Services Strategy, OMB, May 2, 2012.

Geospatial Services Taxonomy Structures

There are differences of opinion across the geospatial community whether geospatial is a mission specific capability, or an enterprise-wise service offering, and now many expect it to simply be another commodity service offering. The cross-cutting nature of Geospatial Information Systems makes it difficult to neatly categorize the technology other that the widely held opinion that it needs to be a shared service.


An IT shared service is defined as: “An information technology function that is provided for consumption by multiple organizations within or between Federal Agencies.”[1] There are three general categories of IT shared services: commodity, support, and mission; which are delivered through cloud-based or legacy infrastructures, as is shown in Figure 1. Note that Geospatial is highlighted within the Mission IT Category as a Service Type.



Figure 1. IT Shared Services Concept Overview


However; when the three general categories of IT shared services are defined, the Shared Services Strategy also places Geographic Information Systems as an IT Support Service:

  • Commodity IT Services: A category of back-office IT services whose functionality applies to most, if not all, agencies (e.g., infrastructure and asset management, email, hardware and software acquisition, and help desks).
  • Mission IT Services: A category of enabling IT that support agency core business functions.

Support IT Services: A category of back-office IT services whose functionality applies to multiple agencies and is business focused (e.g., Geospatial Information Systems).

The purpose of the Federal Enterprise Architecture Framework’s Application Reference Model (ARM) is to provide the basis for categorizing applications and their components. It is expected that as agencies map their current and planned Information Systems to the ARM categories (as required by the OMB IT asset inventory annual reporting guidance), gaps and redundancies will become evident, which will aid in identifying opportunities for sharing, reuse, and consolidation or renegotiation of licenses.

As seen in Figure 2, the ARM consists of three levels: Systems, Application Components, and Interfaces. Note that Geospatial is highlighted within the Application Components category, as opposed to a [Mission IT] support system.



Figure 2. Federal Enterprise Architecture Framework (FEAF): Application Reference Model


The three levels: Systems, Application Components, and Interfaces are defined as:

  • Systems – are discrete sets of information technology, data, and related resources, organized for the collection, processing, maintenance, use, sharing, dissemination or disposition of information in support of a specific business The ARM Systems category does not include mission-specific systems.
  • Application Components – are self-contained software that can be aggregated or configured to support, or contribute to achieving, many different business objectives, processes, and multiple IT systems.
  • Interfaces – are protocols used to transfer information from system to system.

When the Geospatial Information Application Component is further expanded as shown in
Figure 3, the granular level of detail is limited to five categories.



Figure 3. FEAF Application Reference Model: Geospatial Information



The Geospatial Profile of the Federal Enterprise Architecture provides an Appendix that lists a set of some 68 geospatial service components that might apply within an agency’s services architecture. It is a business-driven, functional framework that describes how geospatial services can support mission/business and performance objectives. This list provides Program Managers and Solution Architects with a view of how geospatial fits within an organization operational requirements and can be used to educate mission/business owners about how geospatial can support their needs (Operational Requirements Documentation). Table 1 is an extract from the Geospatial Profile’s Appendix C: Geospatial Service Components that describes the business-driven geospatial services.


Table 1. Geospatial Profile V2.0: Geospatial Service Components (Extract)







(* = Multiple Entries)


Back Office Services Domain

Assets/ Materials Management

Facilities Management

Defines the set of capabilities that support the construction, management, and maintenance of facilities for an organization.

Facilities Management System

A GIS-based Facilities Management System

Back Office Services Domain

Assets/ Materials Management

Property/ Asset Management

Defines the set of capabilities that support the identification, planning, and allocation of an organization’s physical capital and resources.

Property/Asset Management System

A GIS-based Property

– Asset Management System

Back Office Services Domain

Data Management

Data Exchange

Support the interchange of information between multiple systems or applications; includes verification that transmitted data was received unaltered.

Geospatial Data Exchange and Translation Services

The ability to import/export, manipulate, and convert geospatial data through standard data exchange and trans- formation services. Services to transform geospatial data schemas between disparate systems.



The Segment Architecture Analysis of the Geospatial Platform[3] noted that a complex business component system such as a GIS does not fit neatly under the Federal Enterprise Architecture taxonomy. Geospatial cuts across many, if not all service types defined within the FEAF. To address this complexity, the Geospatial Platform analysis recognized the variation in taxonomies and provided an expanded categorization adaptation from several the geospatial service components to reflect the roles of geospatial across an enterprise. Figure 4 depicts the seven higher-level service categories or “Types” that are grouped into the areas of; access, analysis, services, and systems. Within these 7 types are the 23 dependent service “Components.” The figure represents two main layers of the Geospatial Services Framework:

  • Service Type – Provides a seven-layer categorization that defines the context of a specific set of service components.
  • Service Component – A self-contained business process or service with predetermined and well-defined functionality that may be exposed through a business or technology interface.




Figure 4. Geospatial Services Framework[4]

The seven services “Types” are described as:[5]

  • Mapping Services Descriptions – access vector and raster data and render them in the form of a map for display (combines access and portrayal). Independent of whether the underlying data are features (point, line, and polygon) or coverages (such as gridded digital terrain models or images), the mapping service produces data that can be directly viewed in a Web Data are labeled as one or more “layers,” each of which is available in one or more “styles.”
  • Imagery Access Descriptions – provides an image of a requested layer(s) in either the specified or default rendering style(s). Typical output formats include Portable Network Graphics (PNG) format, Graphics Interchange Format (GIF), Joint Photographic Expert Group (JPEG) format, and Tagged Image File Format (TIFF).
  • Geographic Feature Data Access Descriptions – for selecting, browsing, extracting, transforming, and updating of a geographic feature database.
  • Metadata and Catalog Services Descriptions – for browsing, entering, transforming, integrating, and updating metadata for geospatial resources, and optionally, updating of associated geospatial resource A geospatial catalog supports search against geographic feature and imagery data through metadata.
  • Geo-Coding and Gazetteer Services Descriptions – provides the ability to determine the geospatial coordinates for a place, given an address, place name, or This function accesses a database of geographic features and returns the location and other descriptive information.
  • Geographical Analysis Services Descriptions – is a Web service that computes a geographic function for a specified geographic input, including computational overlay functions of a GIS.
  • Image Processing System Services Descriptions – is an integrated system for collecting, storing, accessing, sharing, disseminating, integrating, manipulating, visualizing, analyzing, and otherwise exploiting geospatial imagery.

The 23 Service Components within the 7 Types are each defined within the Segment Architecture Analysis of the Geospatial Platform.



The Open Geospatial Consortium[6] (OGC®) notes that, “There exist multiple possible taxonomies for services, based on various classification dimensions … the purpose of defining a taxonomy … is to have one way of identifying geographic extensions to various existing service types. [This] is not intended to be the only taxonomy to be used in the context of geographic services.”

The OGC® Service Architecture Abstract Specification[7] applied ISO 19101[8] to define six classes of information technology services as the basis to categorize geographic services. ISO 19101 defines the Extended Open Systems Environment (EOSE) model for geographic information. The EOSE defines classes of services based on the semantic type of computation that they provide. EOSE provides the functional decomposition of the services for the geographic domain by extending the more general Open System Environment model [ISO/IEC TR 14252]. The IT Services use to categorize geographic services included:

  • Human interaction services – for management of user interfaces, graphics, multimedia, and for presentation of compound documents.
  • Model/Information management services – for management of the development, manipulation, and storage of metadata, conceptual schemas, and datasets.
  • Workflow/Task services – for support of specific tasks or work-related activities conducted by These services support use of resources and development of products involving a sequence of activities or steps that may be conducted by different persons.
  • Processing services – perform large-scale computations involving substantial amounts of Examples include services for providing the time of day, spelling checkers, and services that perform coordinate transformations (e.g., that accept a set of coordinates expressed using one reference system and converting them to a set of coordinates in a different reference system). A processing service does not include capabilities for providing persistent storage of data or transfer of data over networks.
  • Communication services – for encoding and transfer of data across communications networks.
  • System management services – for the management of system components, applications, and networks. These services also include management of user accounts and user access privileges.

The resulting Geographic Services Taxonomy, depicted in Table 2, uses the IT services and expands the processing services to include; spatial, thematic, temporal, and metadata.


Table 2. Geographic Services Taxonomy[9]



  • Geographic human interaction services
  • Geographic model/information management services
  • Geographic workflow/task management services
  • Geographic processing services
    • Geographic processing services –spatial
    • Geographic processing services –thematic
    • Geographic processing services –temporal
    • Geographic processing services –metadata
  • Geographic communication services
  • Geographic system management services


The OGC® Service Architecture Abstract Specification goes on to map its Geospatial Services Taxonomy to that of the ISO 19100 series standards as displayed in Table 3.

Table 3. OGC® Geospatial Services Taxonomy to ISO 19100 Series Standards



Geographic human interaction services

19117 Geographic information – Portrayal

19128* Geographic information – Web Map Server interface

Geographic model/information management services

19107# Geographic information – Spatial schema (See note)

19110 Geographic information – Methodology for feature cataloguing

19111+ Geographic information – Spatial referencing by coordinates

19112 Geographic information – Spatial referencing by geographic identifiers

19115# Geographic information – Metadata

19123 Geographic information – Schema for coverage geometry and functions

19125-1* Geographic information – Simple feature access – Part 1: Common architecture

19128* Geographic information – Web Map server interface

19136* Geographic information – Geography Markup Language

19142* Geographic Information – Web Feature Service Interface

19143* Geographic Information – Filter Encoding Interface

19156:2011* Geographic information — Observations and measurements

Geographic workflow/task management services

(no relevant ISO 19100 series standards)

Geographic processing service

19107# Geographic information – Spatial schema

19108 Geographic information – Temporal schema

19109 Geographic information – Rules for application schema

19111+ Geographic information – Spatial referencing by coordinates

19116 Geographic information – Positioning services

19123 Geographic information – Schema for coverage geometry and functions

19118 Geographic information – Encoding

Geographic communication services

19149* Geographic information — Rights expression language for geographic information – GeoREL

Geographic system management services

(no relevant ISO 19100 series standards)


 “*” An OGC standard that was submitted to ISO

 “#” An ISO standard approved as a topic volume of the OGC Abstract Specification

 “+” Jointly developed OGC and ISO standard



The SDI Cookbook identifies existing and emerging standards, open-source and commercial standards-based software solutions, supportive organizational strategies and policies, and best practices. “The SDI Cookbook wiki is intended as a “living document’ which provides information on standards and best practices for implementing a Spatial Data Infrastructure.”

The SDI Cookbook defines services as:

“… self-contained, self-describing, modular applications consisting of collections of operations, accessible through interfaces, which allow clients to evoke behaviors of value to the user. Clients can invoke services from across a network using standardized protocols independently of platform, language, or object model on which the services or the client were deployed.”

The OGC Service Framework groups geospatial services into five categories corresponding to the OGC services taxonomy top-level domains described in OGC’s Service Architecture Abstract Specification (also ISO 19119[11]). The SDI Cookbook provides a summary of these categories (below), and when available, includes implementation specifications for these services:


    • Catalogue Services – respond to requests for metadata in a Catalogue that comply with certain browse or search Geospatial data that are stored for use in local databases can often be used in external applications once they are published. In this section, the concepts and implementation of geospatial data catalogues are presented as a means to publish descriptions of your geospatial data holdings in a standard way to permit search across multiple servers.
      • Note: A Catalogue is a single collection of metadata entries that are managed together.


    • Geospatial Data Services – provide access to a wide range of collections of geospatial data stored in distributed repositories and Examples of data services include:
      • Sensor Collection Services: provide access, manipulation and collection of sensor Applicable implementation specification: OGC Sensor Collection Service (SCS;
      • Image Archive Services: provide access and management of large sets of digital images and related metadata


    • Data services also provide access to location-based data in the form of the following services (Applicable implementation specification: OGC Location Services (OLS;
      • Directory Services: provide access to online directories to find the locations of specific or nearest places, products or services
      • Geocoding Services: transform a description of a location (place name or street address) into a normalized description of the location
      • Navigation Services: determine travel routes and navigation between two points
      • Gateway Services: fetch the position of a known mobile terminal from the Network


    • Portrayal services – provide visualization of geospatial Given one or more inputs, portrayal services produce rendered outputs (maps, perspective views of terrain, annotated images, etc.). They can be tightly or loosely coupled with other services such as the Data and Processing services, and can transform, combine, or create portrayed outputs. Examples of such services include:
      • Map Portrayal Services
      • Mobile Presentation Services


    • Processing services – unlike data services, are not associated with specific Instead, they provide operations for processing or transforming data in a manner determined by user specified parameters. Processing services can be tightly or loosely coupled with other services such as the Data and Processing Services. The most common examples of processing services are:
      • Coordinate Transformation Services: convert geospatial coordinates from one reference system to Applicable implementation specification: Coordinate Transformation Services (CTS;


    • Image Manipulation Services – manipulate images (resizing, changing color and contrast values, applying various filters, manipulating image resolution, ) and are used for conducting mathematical analyses of image characteristics (computing image histograms, convolutions, etc.).


    • Image Exploitation Services – support the photogrammetric analysis of remotely sensed and scanned imagery and the generation of reports and other products based on the results of the


    • Image Synthesis Services – create or transform images using computer-based spatial models, perspective transformations, and manipulations of image characteristics to improve visibility, sharpen resolution, and/or reduce the effects of cloud cover or haze.


    • Geospatial Analysis Services: exploit information available in a Feature or Feature Collection to derive application-oriented quantitative results that are not available from the raw data


    • Gazetteers: provide access to geospatial data indexed by place name rather than by coordinate Applicable Gazetteer Service Application profile of the Web Feature Service Best Practice 1.0 (


  • Service Chaining – can be considered as a special case of processing services, enabling the combination or pipelining of results from different services in response to clients’ Efficient service chaining is critical to the ability to leverage and combine multiple information sources hosted by various service providers. Service chaining is required when a task needed by a client cannot be provided by a single service, but rather by combining or pipelining results from several complementary services. Most GIS applications will require the chaining of multiple geospatial and non-geospatial services.



The successful adoption and use of the geospatial Application/Service Reference Model will depend upon achieving consensus on a consistent, well-known and well-understood set of names and definitions for geospatial service components. Aligning agency capital investments to an agreed upon Apps/Svcs Reference Model leverages a common, standardized vocabulary, allowing interagency discovery, collaboration, and interoperability. Agencies and the Federal Government will benefit from economies of scale by identifying and reusing the best solutions and technologies for applications that are developed/provided or subscribed to support their business functions, mission, and target architecture.[13]

Several initiatives described above have attempted to refine a view of geospatial applications/services taxonomies. These examples will be useful to the geospatial stakeholders (e.g., Program Managers and Solution Architects) developing the geospatial services and how they expose them as shared services in places like Repositories and App Stores. However, there is no commonly agreed to, consensus-driven or policy-based geospatial applications and services taxonomy to uniformly categorize capabilities across the geospatial community. No one categorization [currently] will meet the user communities’ requirements in terms of mission/business function(s), understanding and ease of use.

When developing an organization’s IT Asset Inventory and corresponding Apps/Svcs categorization, the geospatial investment owners responsible for delivering the mission/business functionality across the enterprise must agree upon the name, definition of the service types and their components


[1] Office of Management and Budget, Federal Enterprise Architecture Framework, Version 2.0, January 13, 2013.

[2] Geospatial Profile of the Federal Enterprise Architecture (FEA), Version 2.0, March 06, 2009.

[3] Segment Architecture Analysis of the Geospatial Platform, Version 1.0, December 21, 2010. Federal Geographic Data Committee, in support of the Federal Chief Information Officers Council. Available at

[4] Service types taken from the Enterprise Architecture Segment Report (Draft Interim Instruction Guide for Quarter 4 FY2009). Service components taken from the Geospatial Profile of the Federal Enterprise Architecture, Version 2.0.

[5] Segment Architecture Analysis of the Geospatial Platform, Version 1.0, December 21, 2010. Federal Geographic Data Committee, in support of the Federal Chief Information Officers Council.

[6] Open Geospatial Consortium.

[7] OpenGIS Abstract Specification, Topic 12 “System Architecture,” OpenGIS Consortium, Version 4.2, October 2001. Available at Volume 12 is equivalent to ISO/DIS 19119, Geographic information – Services (2002). ISO 19119 was subsequently published in 2005. ISO 19119:2016 was published on 2016-01-18. See:

[8] ISO 19101:2002 Geographic information – Reference Model. INCITS subsequently approved ISO 19101:2002 as INCITS/ISO 19101-2002 (R2012), available for purchase at ISO 19101-1 rev. Geographic information – Reference model – Part 1: Fundamentals (Revision of ISO 19101:2002) was published on 2014-11-12.

[9] Based on OpenGIS Abstract Specification, Topic 12 “System Architecture,” OpenGIS Consortium, Version 4.3, October 2002, Available at

[10] The information in this section is taken directly from SDI Cookbook, Global Spatial Data Infrastructure, GSDIWiki, last updated 5 June 2014. Available at

[11] ISO 19119:2005 Geographic information – Services. “ISO 19119:2005 identifies and defines the architecture patterns for service interfaces used for geographic information, defines its relationship to the Open Systems Environment model, presents a geographic services taxonomy and a list of example geographic services placed in the services taxonomy. It also prescribes how to create a platform-neutral service specification, how to derive conformant platform-specific service specifications, and provides guidelines for the selection and specification of geographic services from both platform-neutral and platform-specific perspectives.”

INCITS approved ISO 19119:2005 as an American National Standard. Available for purchase at

[12] Office of Management and Budget, The Common Approach to Federal Enterprise Architecture, May 12, 2012.

[13] Office of Management and Budget, The Common Approach to Federal Enterprise Architecture, May 12, 2012.

Geospatial Baseline Assessment Matrix

As part of the Executive Steering Committee’s authority to initiate the enterprise-wide Geospatial Baseline Assessment, application and service requirements based upon mission/business functional needs from the Operational Requirements Document must also be identified. This business analysis should include a categorization of the general types of Apps/Svcs necessary to meet the functional needs of the organizations. Regardless of the final categorization used in defining the Apps/Svcs (Geospatial Services Taxonomy Structures), the Baseline Assessment will require a discussion with the user community to define requirements, especially mission/business owners not intending to create a geospatial capability of their own. One of the challenges with defining the geospatial application/services functional requirements with non-geospatial centric mission/business owners is that geospatial functionality is often merely one type of capability that is needed by the user or system. Often, geospatial is a secondary service capability that may be used to contribute to or integrate with other primary service requirements. An example of this is the requirement for a Common Operating Picture (COP), while having a geospatial visualization component, it is primarily a decision support system requiring such functionality as; document management, incident management tracking, reporting, alerts and notifications, email triage with automated ingest, request for information, and archival capabilities.


Table 4 and provides an example of the general functional categories of applications and services that do not necessarily correspond directly with the taxonomies in Geospatial Services Taxonomy Structures, but provide a starting point for which to develop more detailed or drill-down Apps/Svcs assessment.


Table 4. Geospatial Baseline Assessment Matrix: Functionality Categories



This initial categorization is expanded in Table 5, which provides a basis to perform an inventory of specific Apps/Svcs either currently existing, planned for development or acquisition. Table 5 provides an extract of the two-page Baseline Apps/Svcs Assessment Matrix that is contained in the Examples, Templates and Artifacts section.


Table 5. Geospatial Baseline Assessment Matrix: Applications And Services(Extract)

ARM 5-5


Table 4 and Table 5 are not intended to be a definitive list of geospatial Application/Services functional capabilities, but serve as a basis for the Executive Steering Committee to task the development of a comprehensive and mutually agreed upon taxonomy of Apps/Svcs among the organization’s geospatial practitioners (e.g., Program Managers and Solution Architects) and mission/business owners. This will in turn foster the discussion to determine operation requirements and the opportunity to share geospatial services across the enterprise. The inventory of these Applications/Services across the enterprise will also serve to meet the OMB reporting requirement of the Federal IT Shared Services Strategy[1] to submit an “Enterprise Roadmap” that includes a list of IT assets agency-wide to include all IT systems and services that support mission, administrative,

and commodity IT programs, using [or aligned to] the Federal Enterprise Architecture Reference Model taxonomies provided in the Common Approach.




[1] Office of Management and Budget, Federal IT Shared Services Strategy, May 2, 2012.

Geospatial Applications/Service Catalogs

Currently, Federal Agencies have limited information regarding the full spectrum of inter-agency IT shared service options that are available.[1] The OMB, working with the Federal CIO Council’s Shared Services Subcommittee established an online IT Services Catalog[2] to provide Federal Agencies with a list of available services and contract vehicles. The Federal Shared Services Catalog – Uncle Sam’s List (Figure 5) is intended to be a “prices paid portal,” that identifies candidate shared services in the areas of: Commodity IT, Support Services and Mission IT, which included Geospatial listed under Mission IT in Geospatial Services Taxonomy Structures; however, it does not, nor is it intended to, provide geospatial applications/services as described in this section.


Figure 5. Uncle Sam’s List

Although the OMB Enterprise Roadmap[3] will include an inventory of all of the agency’s IT applications, systems, and services, there are limited resources for geospatial applications/services catalogs available to the user community. The Segment Architecture Analysis of the Geospatial Platform,[4] as part of its Target Analysis states that in the [desired or To-Be] target state; “metadata is produced for both geospatial data and services, adheres to a common standard, is governed by coordinated agency policies, and supports catalogs dynamically.” The document further, highlights the “Enable Discovery” portion of the Process Flow section with three prescribed tasks:

  1. An agency stands up a catalog to enable metadata storage and Catalogs are deployed in the context of goals, objectives, and technical specifications to ensure they are open, flexible, and accessible to a broad audience. Catalogs are only implemented if no suitable existing catalog (internal or federal) exists to fit the agency’s goals.
  2. The agency implements harvesting or update services that automatically populate catalogs with new metadata on a set The catalogs to be updated as well as the schedule are set forth in agency policy.
  3. The agency implements alternate discovery mechanisms/service as Once deployed, the agency publishes use of the new mechanisms/service.

The following provides brief examples of Federal Applications/Services Catalogs and is intended to highlight the differences in approaches for the establishments of catalogs for the identification and delivery of services.


“The Geospatial Platform enables the sharing of data, services, and applications across the government on a shared cloud infrastructure. This aligns with the government‐wide shared services strategy, which is intended to improve return on investments, close productivity gaps, and increase communications with stakeholders.”[5] While predominantly regarded a data catalog service site, it also has additional services offerings. The Geospatial Platform offering is considered to be “the suite of geospatial assets delivered to customers, including geospatial data, services, applications, and infrastructure,”[6] as defined as:

  • Data: includes individual datasets, integrated data (such as base maps), or other products derived from multiple datasets. These assets include foundational geospatial data that can be trusted, used reliably and shared across Governments at all levels or, in some instances nongovernmental organizations, can provide data to the Geospatial Platform.
  • Services: provide a consistent, easily accessible way to access geospatial capabilities (e.g., access to data, geocoding, geoprocessing services, metadata management, etc.). The Geospatial Platform will offer access to services that can used by multiple agencies as stand‐alone capabilities or as building blocks to develop applications.
  • Applications: consist of a set of tools or capabilities that enable a user to exploit geospatial information through visualization, query, reporting, and spatial analysis to achieve their Applications may leverage one or more different services to conduct analysis and return results to the user. The Geospatial Platform will offer access to applications that can be downloaded, customized, and used to meet customer business needs.
  • Infrastructure: includes both physical and logical technology components that can be leveraged by multiple customers.
  • Geospatial Platform Marketplace: provides the “Marketplace” as a public facing listing of datasets that are planned for acquisition by one or more Federal agencies. Utilizing metadata records registered with the shared gov/Geospatial Platform data catalog, and tagged as both “geospatial” and “planned”, Federal agencies and non-federal partners use this listing to identify potential partnering opportunities for data purchase.


The Geospatial Platform is generally considered a dataset catalog and maintains a shared catalog between[7] through an open standards compliant Catalog Service for the Web (CSW) specification that defines common interfaces to discover, browse, and query metadata about data, services, and other potential resources.[8] The catalog provides access for both first-order and all metadata (including members of large collections) for harvested data, services, and applications. The first-order CSW endpoint provides collection level filtering of all metadata records. The all metadata CSW endpoint provides all levels of metadata at varying levels of granularity. Any client supporting CSW (desktop, GIS, web application, client library, etc.) can integrate the CSW endpoints.

The Geospatial Platform provides a Tutorial and Training resource with a link[9] to a “ CSW How To” that allows any client supporting CSW (desktop, GIS, web application, client library, etc.) the ability to integrate the CSW endpoints.

In terms of the Applications/Services offered by the Geospatial Platform, the site provides a Featured Applications page ( that has several user generated examples. The link to the “Maps and Apps” ( results in a page for “Add Your Application” (Figure 6) where future functionality is expected.



Figure 6. Geospatial Platform: Add Your Tool or Application



“The GEOINT App Store is an online platform that provides useful apps, widgets, and web services for members of the Intelligence Community (IC). These powerful yet intuitive software tools are simple to find and use for completing specific GEOINT tasks.”[10] The GEOINT App Store accepts contributions from across the Intelligence Community to include; apps, widgets, or web services through a submission, review, and approval process.

The GEOINT App Store[11] has a number of web applications and unclassified applications (more than 270 in late 2013[12]) for handheld devices. The GEOINT Applications Storefront assists Android and iOS users find National Geospatial Intelligence Agency and partner applications from their devices. Patterned off of commercial storefronts, it provides downloadable apps for smartphones and tablets in the three security domains—unclassified, secret, and top secret.

GEOINT App Store allows authorized users to search by keyword or category to download the application they need directly. Most apps are designed around simply bringing information to handheld devices, such as reports and maps, although some apps will allow users to create reports as well. Though not every application works on every device, the services are cross indexed by category, type as well as a smaller grouping by community as depicted in Table 6.

While the Apps are grouped in multiple locations, the cross-indexing allows the intended user communities to more rapidly search for services.

Table 6. GEOINT App Store Index













First Responder Apps






Mariner Apps






Aviator Apps






Wildfire Apps


Situational Awareness




Tropical Weather Apps




Mobile Web












Web Service












The overarching goal of the Office of the Director of National Intelligence (DNI) is to ensure that the elements of the Intelligence Community (IC) and Department of Defense (DoD) are working collaboratively to provide useful, timely, and accurate intelligence to support those who make and implement U.S. National Security policy, defend our Nation, and enforce our laws. A mission objective is to provide the intelligence community the ability to publish, manage, discover, retrieve, access and govern information about mission, business, and enterprise information technology (IT) resources throughout their lifecycle resulting in the effective management, sharing and integration of IT across the entire IC enterprise.

In response to increasing threats to national security and a growing need for better information sharing between IC elements, the DNI embarked on making significant enhancements across the community by creating a “Single Information Environment (SIE)” for the community and the establishment of a Common Software Repository and Service Registry. This service registry (Enterprise Registry and Repository (ER2) was first established on the Joint Worldwide Intelligence Communications System (JWICS) to support software and services reuse within the IC. The ER2 also has an instance on the Secret Internet Protocol Router Network (SIPRNet). The goals of ER2 are:

  • Support the DNI and community’s efforts in achieving an efficient IT environment.
  • Enable information sharing for IC business and IT data.
  • Adapt IT rapidly to changes in IC mission and business needs.
  • Enable IT discovery, retrieval, access, and reuse.
  • Lower the lifecycle costs of IT through sharing and reuse.
  • Help reduce unwarranted duplication of IT resources.

ER2 is part of the IC enterprise service delivery infrastructure featuring:

  • Publishing and Managing – Easy to populate and update data (supports bulk loads).
  • Discovery and Reuse – Search for and take advantage of available capabilities.
  • Enhanced Portfolio Management – Provides for better informed decision making, automated reporting, improved management and the leveraging of IT investments.
  • Governance and Oversight – Supports publishing, tracking, decision points, and lifecycle milestones.

The ER2 solution is based upon community-developed requirements and is aligned with existing IC element technical solutions including controlled vocabularies and taxonomies from commonly agreed to architecture reference models. ER2 allows IC elements to transition their internal software repositories into the service to enable discovery and sharing of available assets. IC elements have published thousands of shared assets such as widgets, services, Enterprise Standards Baseline and many other asset types. ER2 manages a variety of asset types, including services, software and applications. The different types of community IT assets include:

  • Web services
  • Applications
  • Software
  • Web Service Definition Language (WSDLs) and Schemas
  • Endpoints and Bindings
  • Providers and Points of Contact
  • IC Standard Citations
  • IC Profiles
  • Widgets

An important benefit to the IC is the ability to discover the relationships between the IC-wide shared IT assets and make a better informed decision on utilization, maintenance, and management of these assets. Organizations are employing the ER2 as a primary asset registry and repository and require the register and search of the ER2 for existing assets that can be reused or consumed. If an asset already exists that performs the functions required by the program, full development may be avoided, thus reducing the program’s overall costs while decreasing time- to-field.

The IC user community has benefited from the identification and collection of the applications and services registered within the ER2 in many areas, including:

  • Developers – find already-built components for the mission solution they are supporting.
  • Analysts – find tools and data sources that have information about the problem they are working.
  • Architects – find pre-built profiles that show standards and reference architecture to design a community-compatible information sharing capability.
  • Community Providers – find and edit metadata, add artifacts, and update the lifecycle of a community asset and advertise the availability of the services to the community for reuse.
  • Program Managers – reduce development costs and shorten delivery cycles by reusing existing community components.



[1] Office of Management and Budget, Federal IT Shared Services Strategy, May 2, 2012.

[2]Uncle Sam’s List, April 2013. Available to Federal employees through the OMB MAX at Public site available at

[3] Office of Management and Budget, The Common Approach to Federal Enterprise Architecture, May 12, 2012.

[4]Segment Architecture Analysis of the Geospatial Platform, Version 1.0, December 21, 2010. Federal Geographic Data Committee, in support of the Federal Chief Information Officers Council.


[6] Ibid.



[9] Ibid.

[10] National Geospatial-Intelligence Agency (NGA). GEOINT App Store.



[13] The information in this section is taken directly from the (Unclassified) Enterprise Registry and Repository entry from Intellipedia as redirected from

Use the online HTML cleaning tool to easily edit and convert the code for web pages!

Geospatial Shared Services Strategy

The Federal IT Shared Services Strategy requires agencies to default to a shared solution when opportunities for consolidation exist. Cloud-First and Shared-First concepts and policies are intended to work in tandem to continue to advance the Federal Government’s move toward cloud-based IT solutions that will serve as a catalyst for the broader adoption of IT shared services.

The Federal Shared Services Implementation Guide provides information and guidance on the provisioning and consumption of shared services in the U.S. Federal Government. The guide provides agencies with a high level process and key considerations for defining, establishing, and implementing interagency shared services to help achieve organizational goals, improve performance, increase return on investment, and promote innovation. It includes specific steps that should be considered for identifying shared services candidates, making the business case, examining potential funding models, using agency agreements, and discusses some of the key challenges that should be expected along the way.


The Federal Shared Services Implementation Guide provides a step-by-step assessment indicating tasks and activities, best practices, and risk areas with mitigations to consider and prepare for when implementing shared services.

The decision to move agency or department functions to a shared service is best served by a methodical approach that helps to ensure achievement of the desired outcomes and benefits (see Figure 7).



Figure 7. Shared Service Implementation Decision

This approach can be applied to evaluate the transition costs and demonstrate future savings. It is also needed to understand the capabilities that can be supported and changes in business processes that may be required to fit into an existing shared service. The Implementation Guide provides high-level guidance on the Steps and Tasks needed to determine whether to pursue implementation of a shared service.

Stakeholder Performance Guide

The Performance Guidance provides a summation of the key decision points necessary to determine the most effective and efficient design, development, and implementation of the geospatial system investment.

When developing their organization’s annual strategic plans and performance goals, Senior Leadership and Program Managers must evaluate the prior performance of their organization (Table 7).

This presents an opportunity to question and assess the following:[1]

  • What is the performance of existing processes and services?
  • What existing capabilities can be improved?
  • What is the cost structure of current capabilities?
  • How efficient is service delivery?
  • What new capabilities are needed and funded by the organization?

When considering each of these questions, the leadership team should consider the availability of existing capabilities that may potentially be provided by a shared service provider and to leverage these capabilities prior to buying or building a new capability.


Table 7. Stakeholder Performance Guide: Applications/Services







Executive Leadership

• Authorize the Application and Service inventory using the Baseline Assessment and catalog App/Svc capabilities across the enterprise using a common taxonomy.

• As part of the Investment Technology Acquisition Review (ITAR) framework, require all new applications and services be compared against the App/Svc Catalog to determine shared first requirement.

• Apply the Shared Services Implementation Step-wise Process to geospatial investment.

• Work with other Executives to acknowledge the need to reduce data costs by leveraging investment and performing the Baseline Assessment based upon mission/business needs.

• Establish review board with CIO/CFO representation and consider policy to ensure participation and commitment.

• During annual budget review/planning cycle or with proposed new investments review against process.

• Signatory with defined responsibility and stated measurable results (e.g., IT Asset Inventory for OMB Open Data Policy reporting and a quantifiable App/Svc resource inventory).

• Promotes interoperability, reduces redundant investments, and allows for cost share.

• Reduce cost for App/Svc development/acquisition alignment to Share-First policy.

Program Manager

• Coordinate across other internal Department/Agency investment PMs to establish Geospatial Taxonomy Working Group and Geospatial App/Svc Catalog.

• Staff and perform inventory and of existing/proposed App/Svc investment.

• Staff and perform Shared Services Implementation Step- wise Process to assess geospatial investments.

• Initiate the Taxonomy development and perform App/Svc inventory for documenting App/Svc and creating a catalog.

• Perform Baseline Assessment: Apps/Svcs across enterprise and populate catalog.

• Develop repetitive process for evaluating investment to share services.

• Shared awareness of investment and value of geospatial capabilities across the organization. Basis for shared service capabilities.

• Provides baseline for shared service investment and leveraged capability

• Catalog meets Share First policy and forms basis for reduced investment.

Solution Architect

• SME and reach back for Taxonomy Working Group participation.

• Perform technical evaluation of App/Svc investments to determine commonality and alignment.

• Develop baseline assessment and perform inventory of App/Svcs.

• Technical review of services for alignment to TRM and Infrastructure compatibility (Geospatial Baseline Assessment Matrix).

• Cross enterprise collaboration for technical exchange and comparison.

• Ensure broadest possible technical review, adoption and acceptance.



[1] Ibid.

Updated on February 4, 2020