The long transaction and work management integration
A relatively small number of users charged with enforcing the business rules of the database can review each LT
change before posting it. These users can make changes as necessary, and assist the client community in
understanding the importance of following guidelines established for the system.
LTs also provide the opportunity for recording as-built changes before the data is posted. Changes captured in the
LT can be updated to reflect changes made to the design in construction. If in the example above the equipment
change was not implemented as designed, the changes made can be incorporated in the LT before it is posted to
production. This necessary function can also be accomplished in the process of completing normal business
functions such as job closing or reconciliation.
Requirements
Production GIS is a strenuous environment for LTs. It is normal for a large volume of LTs to exists at any given
time. These LTs are constantly moving through the GIS following business processes. They will be manipulated,
progress forward and backward through stages, deleted, and eventually posted to production. They must be readily
available for review by users and management. The production data underlying the LTs is subject to review and
manipulation. These LTs must be managed over periods ranging from a few minutes to years. It is important that
GIS users be aware of, and able to review changes pending, in areas subject to LTs without affecting the production
(or current) state of the data.
Robust
This is the most important requirement. In our company we process approximately 2500 LTs per month. The
design within each LT can represent anywhere from a half-hour to a month of designer work. LTs contain all of the
facilities information of pending designs. Any problems that develop in this process immediately affect our ability
to do business.
LTs must tolerate faults from software, hardware, communications, and users. The basic LT design must be simple
enough to allow recovery from unavoidable problems that will occur. When processing 30,000 LTs per year,
affecting millions of rows of data and tens of thousands of man-hours, the system must be very robust to avoid
losses.
Manageable
Users could loose control of he LT process if it is not well designed and business process driven. It should not be
necessary to divert users from normal business functions to manage the LT process. As described earlier, users
while performing their normal Iimctions should move the LTs through the process.
Tools need to be developed to review the progress of LTs in the system and identi~ LTs that may need attention.
These tools must watch for LTs that have deviated from the business process path or have developed data or schema
related problems. Considering the volume and value the LTs represents, management must be as simple as possible
and business driven.
Flexible enough to Conform to Business Processes
It is important that LTs are not allowed to drive business processes, but that business processes drive LTs. The
normal work performed by system users must be allowed to cause LT to progress through their required stages.
A designer navigating to an area on the GIS where work is to be designed and beginning to prepare a work print
should drive the creation of a LT. A LT should capture his work as the designer creates a design. When that
designer has completed the design, the act of notifying a supervisor should move the LT from one stage to another.
The act of completing the reconciliation process should move the LT to a final review stage. This should indicate to
the person responsible for posting the job to production that it is ready for final review and posting.
Support C)A/QCProcesses
Maintaining data integrity is an ongoing problem with any GIS. GISS implemented in the current environment of
competition and changing business conditions are even more susceptible to the pressure of limited time and
attention. The GIS investment in data tends to be very large and keeping this investment healthy is critical. All
process in a GISS LTs must support Quality Assurance and Quality Control.
The LT lends itself to this because the quality of the production data is not affected until the LT is completed.
Because of this the LT can be reviewed at any stage. These QA events can and should be driven by the normal
business process. The first QA opportunity can happen in the design approval process and opportunities continue to
occur as the LT moves through its stages. There are also opportunities for software based audits of the LT data and
it schema integrity.
