The long transaction and work management integration
Kevin W. Miller
FristEnergy Corp, 253 White Pond Drive
Akron, Ohio 44230
The Long Transaction
PaperBackground
In this paper I will discuss the Long Transaction (LT) and its role in the Geographical Information System (GIS) -Work
Management System (wMS) integration. I will explain at a high level what a Long Transaction is, why they
are important in the GIS realm, and how they are applied. I will explain how the LT is affected by WMS / GIS
integration. Finally, I will provide a high level view of the FirstEnergy Corp WMS / GIS integration with GIS long
transactions.
Definition
A LT is an update to a database that takes longer than time required by hardware or software constraints. Business
processes determine the time required for the transaction. The duration of a LT can range from a few minutes to a
few years. The business need is based on the importance of storing information about a change in the system being
modeled until the change actually occurs in the system. The goal is to capture future updates to a database during
some process like planning or design.
Because the changes being captured have not occurred in the system being modeled, it is important that the changes
do not affect the production view of the data presented to the user. It is beneficial if the user can identify areas
where these changes are occurring and view them when needed.
For example, if a planned or designed change to the modeled system includes the installation of a piece of
equipment, system users might design changes using current production data for context. The change would be
captured in a LT and could be displayed within the data as a change and not as the production data which would
remain unchanged. When design changes were completed in the field and the equipment installed, the LT could be
completed updating the production view of the database. This process could take years and the LT functionality
must support this possibility.
To support business functions related to their normal life cycle, LTs are often designed to support a progression of
stages. The LT must pass through these stages before being posted to production. The way the LTs data is
presented or the functions that may preformed on the LT can be altered as the LT progresses through these stages.
For instance, a LT may be created in an initiation stage. Then it may be moved to a design stage where changes
required by the design are recorded and the data edited. The next stage could be a construction stage where the LT
may be write protected. Finally, the LT could be moved to an as-built or closeout stage where post construction
updates were recorded and the design is reconciled with the field construction. Business functions like material
reconciliation can also be captured in this process. The stages are not required by the LT process but are driven by
business requirements. This compliance with normal business functions adds value to LT functionality.
Several different schemes have been developed to achieve this goal. Most GIS products provide for the
implementation of one or more of these schemes. It is not within the scope of this paper to discuss these schemes or
their relative merit. I will discuss the scheme employed at FirstEnergy and some of the reasons it was chosen.
The long transaction in production GIS
Business Drivers
The business drivers for LT implementation fall into two categories. First is the maintenance of data. The care and
maintenance of a production GM database is an expensive necessity facing GIS managers even before conversion is
complete. If a process is not put into place that will maintain the data model, a very large investment can quickly
evaporate. After the conversion of model data, the need exists to show return on the investment and the continued
maintenance of the data model after conversion detracts from this return.
The LT offers managers the chance to capture data updates in the process of other normal and necessary business
functions. Instead of the pure expense of drafters recording data updates to the database after the changes are
completed in the field, designers can create their designs on the GIS in a LT. This process adds value to the
necessary task of updating the data model while assuring that the data will be maintained.
The LT also supports this change in another way. Because the task of maintaining the data is being shifted to users
whose primary job function is not drafting or data updating, a review process is necessary to assure data quality.
The LT can support this review by allowing for quality assurance fimctions. Once the changes in the LT are
completed in the field, the data can be reviewed for cartographic and schematic integrity before being posted into the
production view of the database.
