Want to build A GIS? The proof is in the prototype
At this critical stage in the project, short and long term goals must be balanced. If the eventual
goal is to build a GIS to support the entire organization, two things must be considered. First,
the system must be able to support your immediate departmental needs, and quickly. Second, the
system (or at least the data model) must be designed to support multiple finctions in the
organization, longer term. Essential to success with this approach is to use the correct
technology. It is best to avoid tools that are too specialized or software platforms that were
designed originally to support narrow fimctions.
The best way to achieve long term success is to adopt a platform that has an object-oriented
language built-in and some kind of case tool to better enable data modeling. It should be based
on a strongly integrated, open architecture approach. Most importantly, the system must support
rapid application development. Obvious bias aside, it is also best to utilize a consulting
organization that has had experience implementing applications on the platform and can quickly
develop andlor customize software modules.
To achieve the short term success necessary, it may even make sense to build a throw away data
model and application to start, while developing the longer term solution in parallel. Also, it is
critical that the application chosen can fmction with the available data sources. Applications
cannot function without the necessary database to support them. Fortunately, in most
organizations today, it is usually easy to identi~ existing digital data formats (from a legacy
CAD or GIS) that can be fairly quickly translated into the system. If no such sources exist, it
will be necessary to construct a pilot database from maps or even field inventory efforts. These
efforts, however, have also become much faster and inexpensive.
Step 2. Gather Basic Requirements of the Initial Atmlication
The first essential phase in a development project is to gather the requirements of the application.
This could be done in as little as a week. The key elements here are: the availability of a
knowledgeable and insightful subject matter expert (SME); that the design team remains
disciplined enough to keep the focus of the application sufficiently narrow while still achieving
significant benefit; and that the requirements are documented clearly and concisely. The result of
this phase should be a basic, first cut, functional design. The design will naturally evolve as the
prototyping begins and both the SME’S and the developers become more educated. The
fictional design document should be a working document.
Step 3. Build a Basic Data Model but with Awareness
The first cut of the data model should be as simple as possible while still supporting the
necessary fmctionality. If existing data resides in a CAD or legacy GIS that must be converted,
considerations must be made in the data model to enable straight forward translation and use of
this data. The critical factor is that all of the essential elements of the network are captured and
that a connective, topological model is defined. It should be maintainable by an operator with
minimal software customization and application complexity required.
Mapping requirements may dictate additional complexity to support graphics at a variety of map
scales. This type of complexity is best avoided at the beginning. If mapping is required, as it
usually is, focus should be put on one product, usually the underground location map (electric),
gas distribution map, or strand map (telephone). This is mainly because of the relevance to
designers who are accustomed to these map views.
The data modeling step is one of the most critical steps, but decisions made at this stage are not
irreversible. It is very important to stay disciplined during this phase. Problems can be fixed
later, even after data has been translated or converted into the system (provided that the platform
chosen easily supports model changes on live data). Once again, keeping both discipline and
balance is important. Perfection of the data model is absolutely impossible, especially at this
stage. Once the first cut of the data model is complete, it is possible to move onto the next
stage. Making repeated changes during the data modeling stage before full prototyping will not
save any time nor avoid inevitable changes in the model. Further tweaks can occur throughout
the process, but do not necessarily provide immediate benefit and will hamper data
conversionkmslation efforts. It will be necessary to defer major data model changes until after
a working prototype has been completed and implemented.
Step 4. Prototwirw and DesiminR on the Fly
With the advances in graphical user interface (GUI) tools and object orientation in recent years,
designing a system while developing iterative prototypes has become more feasible than ever.
Furthermore, with object orientation, it is realistic and, indeed preferable, to utilize existing
software modules in the development. This will greatly speed up development, provided that the
software modules developed or used follow all of the rules of object orientation and are not too
closely linked to a specific data model. It is important that the development team have
experience with object-orientation.
Another key to building a successful prototype, which will also be essential in the later stages of
the project is to involve the SME’s early in the process and frequently throughout the
development. The SME’S will be able to provide significant input, especially once they have
had an opportunity to become familiar with the software platform and its capabilities. They will
most likely take ownership of the software and will become champions for the project across the
organization within a short time. The only caution here, again, is that the team remain
disciplined. The system does not have to be perfect at this stage. As new requirements surface
during the prototyping (as they inevitably do), they should only be incorporated if they bring
significant pay back for the system and do not derail the schedule or budget. The system should
be made to be easy to use, but “bells and whistles” should be avoided.
All through the prototyping phase, the functional requirements can be fiuther refined and a
complete system design created. This system design will become the basis for the full system,
and should encompass many aspects of the prototype and its functionality.
Also, while the prototyping phase continues, the system’s network infrastructure can be set up
and the base software platform installed. Preliminary “work in progress” versions of the
prototype can be installed at designated user sites and fimther SME involvement and feedback
solicited.
It is also important at this stage that a system administrator (or systems support group in larger
organizations) be identified to develop and support the computer network. It is preferable that
this fi.mction be integrated to the project team as opposed to being a part time fi.mction from
someone elsewhere in the organization. Additional training on the software platform and its
tools can also be undertaken. This will enable the support group to be well positioned to support
the working prototype while the fill system is under development.
Step 5. Imulementin~ the Imperfect Solution
Once the prototype has been reasonably system tested and is completed sufficiently to a “version
1.0”, it should be straightforward to implement the system, initially with a set of “seed” users.
The system implementation will proceed more smoothly if the infrastructure has already set up,
during the prototyping phase. Adequate training and understanding of the system by its
intended users are essential. The SME’s should be trained first, even prior to application
development. When the application is ready to roll out, the SME’S should be able to play an
active role in, if not teach, the training. They should also be heavily involved in, if not develop,
much of the user documentation.
Once the prototype has been installed, and is in actual use, there is likely to be significant
feedback (if not, then something is wrong and the system is not being used). This feedback is
crucial to the long term development and needs to be incorporated into the design and
communicated to the development team immediately. Ideally, even after first implementation,
the prototyping should be allowed to continue and incremental deliveries of more advanced
functionality scheduled regularly. In many cases, the development and implementation can
happen concurrently with each providing input to the other.
Step 6. Taking the Show on the Road while Imtmoving or Redevelopiruz it
Once a working prototype GIS application has been installed, there might be a temptation to call
the system complete. After all, if the original charter has been met, even at the most basic level
for the specific department that it was intended for, it may not be critical that the system be
enhanced further and extended to fbnction throughout the organization. Realistically, from the
project manager’s perspective, it might be the right time to move on and turn the system over to
support.
If the vision, however, is to extend the technology throughout the organization, and not only
automate but introduce the real efficiencies of integration, there has to be corporate buy-in.
Furthermore, this was only a working prototype, which was developed in a relatively “quick and
dirty” fashion. To get the additional fhnding needed, however, it will be necessary to
demonstrate the immediate benefits that were achieved through implementation of the prototype.
The best way to achieve this is through marketing of the system and the vision throughout the
organization. There is often a significant sales effort necessary to get a GIS project started in the
first place. The selling will become much easier once a working example can be demonstrated to
high level management across the organization. This is the best way to secure the additional
funding that will be necessary to extend the prototype into a fully developed system.
