Technology Migration and Production Systems
Some Suggestions and Examples
Between the hope and hype associated with new AM/FM/GIS technology, there are great
benefits to be gained from its implementation, even where existing systems are providing
users with some benefits. The following suggestions are intended to give the user of a
production-ready AM/FM/GIS some ideas for taking immediate steps get ready for the
brave new world. Although the author is most familiar with one particular brand of base
GIS technology, the suggestions contained here are not dependent on a vendor or brand.
Make a Mimation Plan
Any reasonable approach to managing technology today must include a migration plan,
and this constitutes the first, and likely the most important suggestion. The basis for the
plan does not have to be fancy, nor need it contain a lot of descriptive detail regarding
existing systems and plans. But it should contain the following minimum information:
- A description of any existing or desired corporate standards in operating systems,
hardware platforms, and databases.
- An inventory of AM/FM/GIS applications, their platforms, environments and
databases.
- A description of the strengths and weaknesses of each application and its
components, based on the list compiled above.
- A list of intended or desired functions that are not now implemented because of
technological limitations.
A target environment and platform for each application, in consideration of the
integration and other requirements, and the capabilities of new AM/FMIGIS and
other computer technology available.
This simple outline assumes a fair bit of knowledge on the part of the writers of and
contributors to the plan, and one might be tempted to argue that it is too tall an order. But
consider the effort to be an evolutionary one, and make a start, realizing that the plan will
develop over time.
Here are a few hints to help in the establishment of standards, and the assessment of
target platforms and environments.
- Learn as much as possible about direction of technology, through conference
attendance, and reading trade journals and technical publications.
- Evaluate the players in the AM/FM/GIS and related computer fields. Look for the
coolest or hottest technology, but don’t overlook technological leadership,
longevity and financial stability.
- Make a graphic depiction of the migration strategy. Often a road map showing
how inter-related applications or systems will move to new environments will
illuminate any dependencies or time-sensitive elements. At the very least, a
picture will help to clarify the plan. Pick any flow chart or bubble diagram format
that seems to work.
- Start now, and adjust later. It may seem like there are too many unknowns to
make a valid plan. But by starting, at least a framework can be developed, the
details of which can be painted in as more information is gained.
Implement New Technology on a New Application First
This suggestion is an extension of the notion of Incremental migration. The idea is to
select a fimction or application that has a sound business basis but is not currently
implemented, and use a new technology as the basis for it. Rather than replacing an
existing fimction or set of fi.mctions with new technology, the concept is to add value to
the existing system while testing the new platforms or environment.
This approach has a couple of distinct advantages for mitigating risk as a part of a
migration strategy. First, it enables the project team to produce an application without
the tremendous pressure of disrupting an existing production schedule. Second, it should
be easier to set and manage expectations for a new set of functions, rather than having to
compete with existing fictions that have a familiar look and feel. Third, the overhead of
duplicate systems can be avoided while the implementation team works out the kinks of
new technology.
A good example of this technique was recently tested by an electric and gas utility.
While using a UNIX-based AM/FM/GIS for basic mapping and database fimctions, they
implemented a simple desktop tool for viewing and analyzing trouble tickets. This value-151.added application was warmly received, and gave the AM/FM/GIS team an opportunity
to test several components of previously untried technology with very limited risk.
Plan to Remove Data Dependencies from ADDlication Code
Many mature AM/FM/GIS applications are built using interpretive, scripting or macro
languages. Based on the common techniques of these programming tools, data-dependencies
can often creep into applications code. In addition to the maintenance
headaches that are suggested by this practice, it makes migrating individual applications
or entire systems to new programming environments very difficult.
But there a few steps that can be taken in advance of the actual migration that can help to
ease the pain. One of the most effective of these is to plan ahead for removing as many
data dependencies as possible from existing applications code. A good place to start this
practice is with the business rules that are embodied in the data creation and maintenance
environment of the AM/FM/GIS. Business rules are the methods or behaviors that
describe how entities in the database relate to each other. For example, a check which
ensures that the material type of sleeve is compatible with that of a gas main is a business
rule.
By tabulating business rules, an overview can be developed that will assist in determining
whether some or all of them are ‘hard-wired’ into the applications code, and if they can
be removed from the program and stored in a data dictionary. The more rules that can be
stored in tables rather than encoded, the simpler the task of migrating the editing
application to a new programming environment. This effort can be accomplished
incrementally if necessary, to avoid long disruptions in production. A number of CASE
(Computer Aided Software Engineering) tools are available to assist in the definition of
business rules.
Provide Trainirw in Industrv-Standard Promm-minz Tools for Your AM/FM/GIS Staff
The internal programming and support staff of a mature AM/FM/GIS is usually well-steeped
in the programming tools and techniques of the existing technology. This
knowledge has been put to good use, but may have been learned at the expense of staying
current with non-proprietary or industry-standard programming languages, and new
database skills. This lack of participation can cause a programming team to feel isolated,
and can contribute to the fear of implementing a new system.
One straightforward way of dealing with this problem is to invest in training for the
AM/FM/GIS programming team. The objective of this exercise need not be to create
expertise in a particular language or technique, but instead to gain exposure to new
technology that will help close the knowledge gap, and can be put to use in future
migration strategy. An internal training series on an advanced programming language
like C++, or a visual development environment like Visual Basic or Delphi, can be
delivered for a relatively low cost, and is a straightforward alternative to provide value for
existing staff.
In Summary
Like it or not, new technology will have an impact on the production AM/FM/GIS. Wise
managers, developers and users will look upon the new world of ever-improving
hardware, software and databases as an opportunity to learn more and do more.
Responding to change can take many forms, but the author suggests that, at least in the
technology context, there are three basic models for the corporate behavior of
AM/FM/GIS users. A welcoming stance, coupled with a healthy dose of caution, can
provide an environment where new technology can be applied incrementally. Finally
four basic suggestions are offered, each with the intent of starting the technology
migration process. The ideas presented are obviously not exhaustive. Each manager,
developer and user of AM/FM/GIS can (and should) look for other ways to make new
technology work for them.
