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:
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:
In the Federal domain, a Geospatial Profile [1]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) [2].
An Analogy. Consider a community that maintains an infrastructure for a public service to homes and businesses. This infrastructure might include:
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) [3] 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:
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.
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.
Links
[1] https://www.e-education.psu.edu/geog468/sites/www.e-education.psu.edu.geog468/files/FEA_Geospatial_Profile_v1-1.pdf
[2] https://www.e-education.psu.edu/geog468/sites/www.e-education.psu.edu.geog468/files/PAMAP_Ref_Arch_vol-1_Summary_20070630.pdf
[3] https://www.e-education.psu.edu/geog468/sites/www.e-education.psu.edu.geog468/files/RM-ODP2.pdf