Systems Architecture and The Problem with GIS
Lee Margaret Ayers
PlanGraphics Inc., 22230 NE31st St., Redmond, WA 98053
ph: 206-836-0937
Internet: lee@osisoft.com
Jon Blunt
InfolEd, 1329 Highland Ave, Needham, MA 029192
ph: 617-455-0065
Intemet: jblunt@infoed.com
Abstract
Cunently many AMNGIS's exist aslegacy systems within theco~oration. Notunlike many other
corporate legacy systems, these systems are difficult to integrate and their impact within the organization
is limited to a select group of users — the vision of desktop GIS still remaining a vision. Usually, by the
time the technology is implemented (and data converted -- which represents the greatest investment),
these systems tend to be outdated. The cost to initially implement these systems is so great “thatupgrading
them cannot easily be justified. What are the characteristics that make these systems legacies to the
corporation? How will you know the GIS you implement today does not fall into this category once new
advances in technology are made? Are the newer or upgraded older AMIFIWGIS’s any different? How
easily can your software link to other databases without additional programming? Where is your
vendor’s commitment with regard to the changing desktop? The authors will discuss the component
elements of AM/FIWGIS with regard to single, two and three tier architectures and a way to
consider/design an AIWFIWGIS independent of limitations which may exist in the software.
Introduction
Corporations have two problems to address in creating a viable systems environment to support their
business. First they have to find mechanisms to have their business vision incorporated in the design of
their information systems. Second, the systems have to be constructed with enough integrity to deliver
the benefits desired. The first issue is the domain of corporate Information Architecture. The second is
the domain of system architecture. For a solution to be truly “enterprise-wide,” the selected system’s
architecture should fit within the corporate information architecture. Without a corporate architecture,
system selection becomes a challenge. It results in the current mishmash of systems we see in
corporations today. These systems do not work well among one another, they are costly to integrate, and
they are not easily accessed by the majority of the organization.
System Evolution
Technological advances in creating what is now referred to as the “Industrial Desktop” will allow
engineers to completely reshape the way current analysis is performed. The Industrial Desktop is
comprised of several things, but primarily it is built upon concepts of Three Tier Architecture; a single
window view; a stable development environment for vendors and users which is centered around
technology from Microsoft; and borrowed technology from the desktop. With regard to the desktop and
the industrial desktop Kennedy states, “The similarities are important because the industrial desktop is
too small and too specialized to generate its own applications and standards. We must “borrow”
technology from the office environment or wherever it springs.” (1) Industrial desktop software might be
an application which predicts equipment failure. This application will be comprised of different software
applications which are interoperable among one another because they share common methods for making
information available in a standard format. Development time for these applications will be reduced to a
fraction of what they are today.
Compare this vision to a typical approach to selecting and implementing an Automated Mapping/
Facilities Management/ Geographic Information System (AIWFIWGIS) in the following scenario: (Each
stage is approximately three to four years.)
Stage 1: Primarily, the AM/FM/GIS is brought in to replace manual drafting methods with automated
drafting methods. By the time the system is implemented it is outdated because there is no access to
information about the asset (which is needed by other departments). The number of manual systems for
tracking information is growing. Transformers are in one database, switches in another, poles in another,
etc. Theses ystems are hard to maintain manually, so as more information is needed about the asset, less
and less information is available.
Stage 2: Eventually anupgrade isProcured. The new System Provides access to outside relational
databases, but a database model has to be developed because every utility is unique and different (not
true, but this is the current philosophy). It was a costly change since the attributes for each feature had to
be captured. After conversion and the applications written, it turned out that some of the data were not
accessible because of unperceived limitations in the data model and in the limitations in the software
upgrade. Soon after that upgrade or fix is completed, it is outdated. The company needs to perform
outage analysis but no electrical connectivity was built into the data model, because the AM/FM/GIS was
installed as a mapping system. It had not been perceived that the AIWFIWGIS would support Outage
Analysis, or Maintenance Management, or Engineering Analysis, or etc.
Stage 3: unfortunately too mUChmoney was spent populating the database during Stage 2 to recreate
the information under a new structure, so a consultant had to be hired to develop a work-around. The
consultant did the best they could under the circumstances. The overall performance of the system is so-SO.
The system is not very flexible to meet the changing needs of the organization. The system cannot
be easily linked with the newer systems being implemented. Other than programmed applications,
information about the asset is only available to specialists. New applications have to be contracted.
Occasionally the existing applications go down. As it turns out, the developed model has several
limitations and few people use the system.
Stage 4: The industry has changed so much integration with the corporation isnow entirely custom
the vendor is no longer doing development on your version of the software and is now offering a
different solution based on newer technologies. A translation application could be written to move the
data from one model to the other, but even so, there are no applications in the newer environment. All of
the existing applications will have to be rewritten. The whole system needs to be replaced, but
management will not support this kind of expenditure to recapture information again.
There are many variations to the above scenario. If the company had elected to procure rather than
upgrade the old system, it is still likely they would have had to create their own data model and
applications which would result in the same problems. Regardless of the nuances the project direction
takes, it is not likely the planned system will outlive its envisioned functionality.
The problem is further escalated as these systems are implemented based on an immediate and overdue
need for technological change. Under these circumstances, there is not enough time allotted to “doing it
right .“ Our focus on system selection is typically based on functionality, while the System Architecture is
overlooked. Basing system selection on functionality can be deceiving. Another overlooked issues is the
lack of a common framework upon which to implement systems -- which an Information Architecture
addresses. Add to that an improvement-oriented rather than a business-oriented implementation to
AM/FM/GIS and an immediate need to implement something and we achieve the tail-chasing scenario
described above. We need an understanding of Systems Architecture and an additional set of logic,
provided through Information Architecture, to help us to narrow systems selection and broaden our ideas
for an acceptable implementation.
