The use of AM/FM systems to support the day to day operations of water utilities continues to expand throughout the industry. With many water utilities completing their AM/FM databases, the need for an AM/FM application designed to maintain and expand the use of that data throughout the utility is apparent. This paper will overview design considerations for the network model, attribute model, user interface and the integration of the AM/FM application into a utility's day to day business processes. It will also touch on the application development process, more specifically, experiences encountered using ArcInfo_ as the application engine.
When approaching the development of a GIS application, each component of the application development cycle must be carefully thought out. This paper concentrates on the major components of the application development cycle and strives to relate them to the development of a water utility specific GIS application modeled on the ArcInfo_ software structure. The main components discussed in this paper are:
The application requirements were based upon specifications and experiences collected from a variety of water utility and other GIS implementations. Many of these requirements are components of any thorough application design and are not water utility specific. The application requirements phase focused on all components of the application and for our purpose were probably more broad based than the requirements process of a specific utility.
Since our intention was to develop an application that could be used by various utilities we needed to consider a larger set of technology variables than a single utility implementation would entail. Nevertheless, many of the issues we addressed are relevant to, and have implications for the requirements process of your utility. Consider the following:
Database design:
In designing the database several issues needed to be addressed such
as:
APPLICATION DESIGN
The application's design is key to the acceptance and eventual success
of the GIS in a utility. Applications define what people will do with
the technology, and the design therefore, must facilitate the
acceptance of the application by the end user community. In the case
of our application, we felt that there were two key factors that would
affect its acceptance.
The problem with many application development projects, is that they often reflect the strengths of the team members who are most visible on the project. For example, a utility's project team may be lead by the engineering division. The potential in this situation is for the application design to emphasize the modeling aspects of the application whereas, if the information systems department leads the design phase, the emphasis may be towards the user interface and corporate information system standards.
The trick is to achieve a common ground in the application design without losing focus on the original goals. Some of the key factors relating to our design are discussed below:
Simplicity of Organization:
The design must include a user interface with a logical organization.
Primary functionality must be available during most processes in the
application and the user should also be guided through any process or
task within the application by a prompting system. The prompting
system reduces user apprehension of the application and GIS, and
provides instruction while explaining a process or task. Thus it
serves as a built-in instructional support both during and after formal
training. The menuing system must also incorporate a method of
progressive disclosure to logically provide opportunities to the user
to complete a task or process.
DATABASE DESIGN
The core of the application is the database design. The GIS' database
design should strive to incorporate the real-world characteristics of
the physical infrastructure inventory. Additionally the design should
support the primary corporate business, operational functions,
information storage and data manipulation requirements of the utility.
To meet the needs of the utility, the project team needs to
conceptualize the system, and design the application with functionality
employed on a utility wide utilization of the software. This process
will help ensure that an optimum physical database design is
considered. Merits of designs, application performance and meaningful
functionality are issues that were also considered during the design
and optimization process. In developing the database design for our
base application, we placed a significant level of importance on data
normalization, performance and an openness to use existing data.
Normalization:
The design employed standard levels of data normalization to reduce
data redundancy and simplify data maintenance and operations flow. We
targeted third normal form as the goal especially for CIS and other
event related features. Care should be taken to ensure the ability to
provide primary key attributes. Also, existing databases must be
reviewed to ensure identification of physical inventory data to provide
any non key attributes that access business and historical data.
Performance:
A major consideration in the design of any application is performance.
During the design process, special attention was given to ensure that
operations performed on the data occur as efficiently and thoroughly as
possible. However, as with many applications, the optimization of the
system is a consequence of the application requirements as well as the
architecture and environment of each utility's system. The application
is designed so that users may optimize performance by working with
minimal data sets or increasingly more complex levels of data.
ArcInfo_ database design considerations:
In developing the database design a variety of interrelated components
were addressed, first on an individual basis then as a total entity.
The design required flexibility to provide salient compatibility with
applications such as Customer Information Systems (CIS), Facilities
Management Systems (FMS), and Work Order Management Systems as well as
expandability of the current design. Below are the components that we
identified and the factors that needed to be considered during the
design phase:
Water features:
The feature set needed to represent as many "real world" features as
possible without burdening the user or system with seldom used
features. The system design also had to be flexible enough to accept
new features.
Water feature attributes:
As part of the data normalization process, the base attributes were
divided into levels depending upon frequency of access and the
probability that this information would be stored in a related
database. This design provides flexibility to utilities with varying
levels of automated systems.
Feature class designation:
Feature class designation benefitted from many years of experience in
building GIS infrastructure models, input from water industry
customers, and appropriate association of ArcInfo_ feature classes and
real world facilities.
Spirited discussions regarding the data model and feature class designation revolved around the implementation of applications and the requirements these application place on the model.
Features regularly queried:
The database design thought process ground to a brief halt as the
design team pondered the physical layout of the features. The primary
point of debate was the level of detail most utilities would want in
their GIS and the most efficient method of relating these features to
provide access to data during database queries.
Business data needs:
The business data requirements of the utility impact the structure of
the data model. The data model must provide the ability to link to
data stores which reflect the business status of a GIS feature, and
allow the GIS to initiate queries and calculate statistical data for
analysis and reporting, or provide data to an application.
Model functionality:
The model's functionality was designed to mirror the hydraulic
operations of a utility's distribution network.
Graphics:
Graphics serve to enhance the application's data maintenance
capabilities and provide a means for recognizing features without
querying the database. The database was designed to drive the graphic
representation based upon a physical characteristic stored as an
attribute in the database. For example, a cast iron main may be
represented as a dashed line while a ductile iron pipe may be
represented as a solid line.
Meta-data:
A series of tables provide a method for describing the GIS data as well
as application characteristics. These tables allow control and
modification of the application. They include a data dictionary for
such things as theme management, symbolization, and valid values for
GIS feature data. The meta data tables must also provide a source for
cataloging tools. It is important that they accept tables from sources
such as a spreadsheet application which make the maintenance of the
tables easier and more portable.
APPLICATION PROGRAMMING
The application programming phase is the culmination of successfully
defining the application requirements and organizing them into a
logical arrangement of functional modules. As is the case with most
application programming efforts, the nature of the GIS application and
the application engine posed some interesting challenges for the
development team. Challenges such as migrating the application from a
current release of ArcInfo_ to the latest release to take advantage of
new functionality, as well as providing an open, logically constructed
data model to link to other data sources and allow access by other
applications, tested the design scheme and the vision of the
development team. Some other experiences we encountered during the
programming phase are outlined below.
System architecture:
The system design required that a core set of functionality be utilized
by a variety of applications and their modules. This architecture
proved to eliminate redundancy of code and provide the application team
with a repository of tools to choose from during the implementation
process. Functionality specific to the requirements of a water utility
resides parallel to the application base programs. The result of
implementing such an application architecture is the ease of source
code management and application expansion.
The system monitors the application as it is called by the user through the module naming conventions employed in the coding standards and the environmental variables set in the UNIX shell files. Users are at a greater advantage to provide custom modules within the architecture when the rules for naming files are followed. Also the system architecture which is not complex was developed horizontally to accommodate ease of grouping application modules as desired.
Coding standards:
Coding standards have been implemented to allow users to add
functionality with module names similar to those of application module
names. Naming standards for programs and application variables enable
the user to addfunctionality to the application. The application had
to be smart enough to use the customized program rather than the base
application program if the program names were similar. The application
also must allow for explicate functional calls by users.Base
application modules and programs must be recognized by the name given
to the module to also provide the ability to logically group utility
programs modularly enabling a flexible "mix and match" presentation to
user requirementsand purchases.
SUMMARY
The application development cycle comprised of applications
requirements,applications design, database design, and applications
programming provides a framework for examining some of the issues
driving the design and development of a water utility GIS application
using ArcInfo_. While our requirements were necessarily more
broad-based than those of individual utilities, we invite you to
evaluate their relevance when applied to the needs and environment of
your utility. With our objective, an application design which
facilitates acceptance by the end user community, we focused on both
the modeling aspects of the design and the user interface. Development
of the database design for our base application placed significant
importance on data normalization, performance, and an openness to use
existing data.
Finally the paper concludes with a brief examination of some application programming challenges and experiences encountered during the programming phase.
Bart D. Koenig President of BaySys Technologies Inc.
Specific
Responsibilities
As President of BaySys Technologies, Inc., Mr. Koenig
is actively involved in the management of BaySys' projects and acts as
the primary interface between clients and the company. He has
instituted a project management perspective to successfully complete
BaySys' complex software development efforts. This approach, refined
from experience with many AM/FM/GIS projects, has also been
successfully integrated into BaySys' consulting services.
Past Experience
As Senior Project Manager with Geographic Systems
Corporation, Mr. Koenig was primarily responsible for sales,
management, and consultation.
As manager of GeoVision Systems, Inc.'s Green Bay office, he instituted a master workplan and resource strategy for scheduling and allocating project resources which directly resulted in increased product quality and client satisfaction.In other assignments, Mr. Koenig performed project management, consulting, and marketing activities for long-term utility and public sector AM/FM/GIS projects.
His consulting work has included cost justifications, requirements studies, and implementation strategies for multi-departmental projects. He was also responsible for comprehensive project control and reporting mechanisms to support project management services.
Educational Information
Bachelor of Science, Business Administration, University of
Wisconsin-Green Bay
Professional Memberships
AM/FM International
American Waterworks Association (AWWA)
Water Environment Federation (WEF)
James J. Kyles Vice President - Research and Development BaySys Technologies Inc.
Specific Responsibilities
As V.P. of Research and Development for BaySys Technologies, Mr. Kyles
has designed and managed the development of the BaySys Water Network
Management (WNM) application. His responsibilities include the design
and planning of BaySys' ArcInfo_ based water and wastewater utility
applications, implementation of programming standards for existing and
proposed software applications, and providing database design, support,
and enhancements for BaySys applications.
Mr. Kyles has participated in extensive reviews to determine specific client requirements and conducted feasibility studies for numerous water and wastewater utility and municipal projects. He has conducted on-site data conversion training, delivered end-user training, and presented application theory for a number of these projects.
Past Experience
While at Geographic Systems Corporation (GSC), Mr. Kyles was initially
a programmer/analyst and later became Public Works Product Manager. As
a programmer/analyst, he performed on-site requirements' studies and
identified and designed new products including interfaces to third
party analysis software. He also developed and implemented detailed
programming specifications and high-level system flow charts for water,
wastewater and gas industry applications.
As Public Works Product Manager, he developed and maintained industry specific programs, identified customer requirements and industry trends, and taught custom programming techniques to development staff for the purpose of creating and modifying existing and new applications.
Educational Information
Bachelor of Science Candidate, University of Wisconsin-Green Bay
Professional Memberships
AM/FM International
American Waterworks Association (AWWA)
Bart D. Koenig
President
BaySys Technologies Inc.
504 North Adams Street
Green Bay, WI, U.S.A. 54301
Telephone: (414) 432-1820
Fax: (414) 432-1817
James J. Kyles
Vice President - Research and Development
BaySys Technologies Inc.
504 North Adams Street
Green Bay, WI, U.S.A. 54301
Telephone: (414) 432-1820
Fax: (414) 432-1817