Work Management/GIS Integration: The Next Generation
Solution
As previously stated, NEES’ business object model guided the GIS integration project. The
prerequisite for both the GIS and the next generation of WIN to accommodate business objects
greatly facilitated the integration. The object-oriented GIS enabled mappable associations to both
graphic and non-graphic compatible units, tasks, and instructions. This is important because the
WIN Picklist extends far beyond just compatible units. In addition to the material, each Picklist
item includes the activity, or action, to be performed on h. This design allows activity-based
accounting on a per-pick basis.
In other words, how materials (or tasks) are used affects accounting. On the map, a 40-foot, class
3 wood pole is represented by a graphic object with a defined symbology. In the Picklist, the
same 40-foot, class 3 wood pole may be represented in several different ways, as several
different objects. If the pole is used for distribution service, it has one accounting basis; if used to
support a streetlight or for transmission service, it has another. The field task of applying a
treatment to a pole is yet another association to the object on the map.
In the integrated WIN/GIS environment, work management controls the business workflow
process. Work management on the WIN scale is more granular than that of the GIS. The GIS
includes the engineering process of designing work plans, modifying the design based on as-built
conditions, and completing the process by making the design permanent on the map. Full-scale
work management, as embodied in WIN, includes the entire business process: taking customer
requests, initiating jobs, designing work plans, obtaining inspections, scheduling and assembling
materials and crews, performing the field work, posting time, entering field changes, and
“closing out” jobs for accounting. All stages are vital business processes that are part of the daily
workflow.
During the integration, each system was given the responsibility to control what it “knew best”.
Managing NEES’ business workflow (e.g., dictating what state a work plan was in) is the realm
of WIN. Managing NEES’ facilities and their geospatial relationships (e.g., there are x number of
service points in this town on y number of circuits) is the realm of the GIS. The applications
have to operate in a fully hi-directional manner, each devoted to, and each providing the user
with, functionality from its area of expertise. During the integration design process, it is
legitimate and helpful to diagram the complete system from the vantage point of either the GIS
or WIN (or, for that matter, any other major component). To do so provides the designers with
different valid perspectives of the integrated system, and helps to avoid gaps in the finished
product.
From a technical standpoint, the solution also depended on each system sticking to what it “knew
best”. The object orientation of both systems greatly facilitated the technical integration; for
example, it was decided to have both the GIS and WIN data in the same physical database. The
system is heavily data-driven; therefore sharing a single database greatly facilitates and
streamlines communication and flexibility between the two applications. The WIN application
uses distributed PowerBuilder for its development environment, with most of the core
functionality embodied within the predefine business objects that were identified during project
inception and analysis. This provides deployment capability within an n-tier environment, which
NEES may optionally implement following the conversion of all NEES districts to the integrated
WIN/GIS system.
An example that shows the combined business and technical division of responsibility is the
printing of sketches. Drawing a design and defining and producing the sketches is a GIS
function. However, WIN is responsible for sending the saved sketch file to a specific printer in
the field at the appropriate time, according to the location of the crew that will perform the work.
It is important to note that the WIN and GIS user interfaces were developed in two different
application environments. This was due to a variety of factors; most noteworthy is that the GIS is
an existing commercial system with a defined development environment. That environment was
not as appropriate for WIN, due both to the nature of the WIN application. Other factors included
the long-term maintainability of each system and an interest that each of the two systems should
maintain their “modular separation”, facilitated by developing them in different environments. (It
was a stated preference that the systems remain separate for several reasons, including the ability
to keep upgrades to future versions of the GIS manageable and maintainable).
One disadvantage of developing the two applications in different environments was that the
integration required extra communication components. A series of broker methods (intermediary
programs which allow one application to use services from another), public stored procedures, as
well as public database views, tables, and triggers were developed to permit WIN to invoke and
use appropriate parts of the GI S, and vice versa.
The prime example of this broker-based communication is the Picklist. The Picklist itself is a
WIN module; however it is called from, and returns data to, the GIS during engineering design.
When the GIS user takes action to insert a graphic feature or non-graphic activity, a broker
method call to WIN provides a context-sensitive list. The engineer selects the appropriate
materials and/or tasks, and is returned to the GIS to complete the drawing, association, and
electrical connectivity processes.
