GEOG 468
GIS Analysis and Design

Geospatial System Architecture

PrintPrint

System Architecture. A system architecture is the conceptual design that defines the structure and/or behavior of a system. There is no universally agreed definition of which aspects constitute a system architecture, and various organizations define it in different ways. Systems architecture can best be thought of as a representation of an existing or a To Be Created system. The set of relations which an architecture describes may be expressed in hardware, software, or organizational management. It is a representation because it is used to convey the informational content of the elements comprising a system, the relationships among those elements, and the rules governing those relationships. It is also a process because a sequence of steps is prescribed to produce or change the architecture, and/or a design from that architecture, of a system within a set of constraints. It can also be a discipline because a body of knowledge is used to inform practitioners as to the most effective way to design the system within a set of constraints.

So, you can see that a geospatial architecture is a strategic blueprint that is developed, implemented, maintained, and used to explain and guide how geospatial technology and management elements work together to efficiently accomplish the mission. Broadly, geospatial architecture effort addresses the following views:

  • business processes,
  • system sstructures including data sets and information flows,
  • technical framework, and
  • product technologies.

Having an architecture with specific goals does not mean that a geospatial system must immediately change all of its parts. Part of the architecture is a plan that addresses how the organization will migrate to the new targets over time.

The best reasons for a geospatial architecture are the benefits it brings to the precipitating organization. Benefits include the improved ability to share and efficiently process information, the ability to respond faster to changes in technology and business needs, and reductions in costs because of economies of scale and resource sharing. An architecture promotes consistency across a geospatial community by guiding development towards using a common set of approaches and enables both efficient reuse of components and interoperability. The architecture itself is built out through the efforts of the geospatial community’s stakeholders who are responsible for their data, security, network, and hardware infrastructures

A Federal Enterprise Architecture (FEA) is promoted by the Office of Management and Budget as a methodology to assist in the consistent modeling, description, and execution of business practices in all agencies. The FEA is based on a common set of reference models in use by the public and private sector that collectively define the operations of an organization in support of its mission. The Federal government found the following challenges associated with geospatial information and services supporting government business activities:

  • Organizations are frequently limited in interoperability and their ability to share information and to collaborate with other government agencies or organizations particularly in times of emergencies or where rapid decisions are needed for business purposes
  • Providers and consumers of geospatial data and services do not share semantics and functional capabilities, limiting interoperability
  • Organizations often do not take advantage of information resources that are available through existing spatial data infrastructure services and networks, and therefore unknowingly create redundant capabilities
  • Organizations do not know what other geospatial information exists
  • Spatial data infrastructure services and networks may exist but are not adequately described for discovery or to permit the assessment of quality for re-use
  • Organizations often do not use the best geospatial information resource because data is in too many places, too many possible sources exist, source are of unknown “pedigree”, sources not properly documented, and sources not easily searched
  • Geospatial information and services are not planned, acquired, managed, and shared consistently within and across organizations
  • Geospatial data and services are not readily available to users and applications over the Web or via service-oriented architectures

In the Federal domain, a Geospatial Profile provides cross-government guidance intended to promote common, consistent enterprise architecture practice that results in improved business performance. Here’s an example of a Reference Architecture that was developed for the Pennsylvania Map (PAMAP).

An Analogy. Consider a community that maintains an infrastructure for a public service to homes and businesses. This infrastructure might include:

  • Electricity producers
  • Drinking water purification and distribution
  • Sewage treatment
  • Other waste disposal
  • Natural gas distribution
  • Public transport
  • Cable television and telephones
  • Roads and toll ways

Imagine trying to build just the community’s water system if there were no standard pipe sizes, no standard fittings etc. It would be nearly impossible. Imagine a world of plumbing standards that had some vague objective of "this working with that", with a conversation among water system designers taking place largely outside the context of other systems such as interconnecting water systems, sewage systems etc. This would not be a productive direction. Not only standards are needed but the community also needs some infrastructure concepts to inform the planners as to what components are required (hence what sort of interfaces need to be defined), and to provide a means or assigning priorities to those interface definitions. In this case, there is a balanced discussion of interoperability and infrastructure. A large geospatial system is a community with similar infrastructure requirements.

Views of a System Architecture. For any given information processing system, there are a number of user “roles” that have an interest in the system. Examples include the members of the enterprise who use the system, the system analysts, who specify it, the system designers, who implement it, and the system administrator, who install it. Each role is interested in the same system, but their relative views of the system are different, they see different issues, they have different requirements, and they use different vocabularies (or languages) when describing the system. RM-ODP attempts to recognize these different interests by defining different viewpoints. The ISO Reference Model of Open Distributed Processing (RM-ODP) defines the following five viewpoints. Together they provide the complete description of the system: enterprise viewpoint, information viewpoint, computational viewpoint, engineering viewpoint, and technology viewpoint. The concerns addressed in each of the viewpoints are briefly sketched below:

  1. Enterprise Viewpoint: It is directed to the needs of the users of an information system. It describes the (distributed) system in terms of answering what it is required to do for the enterprise or business. It is the most abstract of the framework of viewpoints stating high level enterprise requirements and policies.
  2. Information Viewpoint: It focuses on the information content of the enterprise.The information modelling activity involves identifying information elements of the system, manipulations that may be performed on information elements, and the information flows in the system.
  3. Computational Viewpoint: It deals with the logical partitioning of the distributed applications independent of any specific distributed environment on which they run. It hides from the application designer the details of the underlying machine (distributed platform) that supports the application.
  4. Engineering Viewpoint: It addresses the issues of system support (platform) for distributed applications. It identifies the functionality of the distributed platform required for the support of the computational model.
  5. Technology Viewpoint: The technology model identifies possible technical artifacts for the engineering mechanisms, computational structures, information structures, and enterprise structures.

The purpose of viewpoints is to position services relative to one another, to guide the selection of appropriate models of services, and to help in the placement of boundaries. Using the five viewpoints to examine system issues encourages a clear separation of concerns, which in turn leads to a better understanding of the problems being addressed.

Architecture Development. Program managers of geospatial projects should take a broader view than just networks and applications. The workflow for the geospatial architecture development is shown below.

Enter image and alt text here.
Enter caption here
Enter image credit here

It is not just about modeling the "big picture;" it is a definition of the structure and distribution of technical and business assets across the entire enterprise. Elements of the process, reading from left to right, are:

a. Defining Architecture Requirements. A geospatial architecture must reflect a set of requirements. The primary goal of the requirements is to enable the system to meet the community’s goals and objectives, not simply the objectives of a single stakeholder. Architecture in general is the "grey area" between what stakeholders aspire to and what can be specified and engineered as a solution. A geospatial architecture requirements are therefore invariably subject to drivers and constraints, many of which by their very nature are beyond the control of the program or a single stakeholder (changing technology, new legislation, etc.).

b. Defining a Candidate Architectures. A Candidate Architecture is an architecture that has not been fully detailed; in other words, it may be as nebulous as the statement "start exposing our applications to a wider audience of users, possibly via web services". The purpose is to evolve an architecture gradually so that we can successfully adopt a new infrastructure in a low-risk manner. The approach is to identify and then validate candidate architectures, which are the building blocks from which the geospatial enterprise architecture is built. An important next step is to show that the candidate architecture actually works and fits into the larger architecture of the organization’s enterprise.

c. Defining Enterprise Architecture. With a suitable candidate architecture in hand, the architects integrate it into an enterprise architecture model. The enterprise architecture model will follow accepted enterprise administration guidance, such as security and data standards and guidelines, which reflects the enterprise development guidance that the enterprise architects develop and support the geospatial activity

d. Defining Reference Architectures. A Reference Architecture is a working example designed and proven for use in by the participants; it serves as an example and provides the basis for creating an application architecture. The reference architectures helps application teams to craft application architecture that utilize the geospatial system. A proven architecture will greatly speed application development effort and minimize support costs because applications are architected in standard, proven ways.

e. Validating a Reference Architecture. A vital part of a reference architecture is testing and validation. A spatial system’s reference architectures is not a theoretical model of how things might work. It is a proven pattern of how things do work and the architects must work with project teams to help them succeed at adopting and following the enterprise architecture. They do this by helping them to apply reference architectures and to craft application architectures with enterprise needs in mind.