Web - Based GIS: Front ends for enterprise - wide management systems
Omar A. Dickenson Technical Manager GeoData Solutions, Inc. odickenson@GeoDataSolutions.com Integrating enterprise-wide systems into a consistent graphical user interface deployed over the Web provides significant advantages to electric utility and telecommunications companies. This paper first discusses technology used to deploy GIS Web systems. Next, specific implementation issues are addressed covering the design, development, and deployment of the graphical user interface and the component modules. The advantages and disadvantages of this system are then contrasted Finally, the paper presents examples of Web modules and their associated specifications. GIS Web Technology The most important concepts necessary for creating front ends for enterprise-wide management systems are ActiveX, Discrete Data Access Modules, and container 136 applications. At the first level of the GIS Web technology diagram, Figure 1, is the operating system. The operating system for this example is Windows NT. Distributed Component Object Model (DCOM) is a software development specification that defines how reusable components should communicate with each other regardless of whether they are on the same machine. ActiveX is a protocol used for creating discrete, event-driven, and distributable components. Developers create ActiveX controls that can be combined in an HTML or Visual Basic container to create more complex applications. ActiveX controls have a graphic user interface and expose a portion of their data and methods. Exposing only some of their internals makes ActiveX controls reusable and modular. ActiveX controls can contain other ActiveX controls, a process called “encapsulation.” Discrete Data Access Modules (DDAMs) are ActiveX modules with connections to databases, a graphical interface, and facilities for communication with other GIS DDAM modules. DDAM interaction specifications are developed by the customer to satisfy business processes and to integrate into container applications. DDAMs are the building blocks for creating applications that link data from enterprise-wide systems. DDAM can easily be created to access many commercial databases, GIS packages, or ODBCcompliant databases. DDAM can also access documents stored in any of the Microsoft suite of products. The most important interface consideration for Web GIS is that DDAMs can access enterprise-wide systems such as customer care, network management, billing, marketing, engineering, and inventory management. DDAMs can be constructed to access data stored in each of these systems’ database or by querying the system for the specified information. DDAM integrates with existing data; data does not need to be copied to a new format—it simply is accessed in place. This greatly simplifies the programming and allows companies in transition times to build working systems quickly. Container applications contain one or more DDAM and handle the interaction and user interface. Container applications can be developed from existing ActiveX controls. Using existing ActiveX controls facilitates creating a DDAM system quickly. Containers are written in a combination of HTML, Visual Basic, and VB Script. The most important aspect of the container applications is that they provide a usable and consistent graphical user intetface. Properly constructed containers are capable of utilizing a plugand- play methodology. This methodology allows different DDAM to be combined in various manners to satisfy differing user requirements. Finally, container applications are distributed over the Web. Changes to DDAM or container application versions can be made at a central site and then distributed to any local or remote user automatically. ![]() Figure 1. WebGIS Technology. The foundation layer is the Windows NT operating system. Distributed Component Object Model (DCOM) is the protocol that supports ActiveX. Discrete Data Access Modules (DDAMs) are created that access enterprise - wide systems. DDA Mare combined to form container applications. Each container application is usable with in the Web GIS application. The Web GIS application consists of a MS Access - type interface with multiple panels. Implementation Design, development and deployment are the key phases in a Web GIS implementation. The design of a graphical front end that will satisfy user requirements necessitates adequate requirements determination. Design of the DDAMs and their associated business rules needs to be coordinated with the design of the graphical front end. The DDAMs work within the graphical front end and access data according to the business processes developed in the requirements definition. The design of a graphical front-end of a container application consists of providing versatility, expandability, and functionality. Versatility is the ability to utilize DDAM from different corporate-wide systems. The container application needs to handle messages from each DDAM, modify its user interface to accommodate each DDAM, and respond to each DDAM event. Expandability is the container application’s ability to model business rules and incorporate them into the user interface. Functionality is generated by examining the detailed requirements of all DDAM and incorporating them into the finished system. DDAMs are designed to have configurable business rules and a graphical interface. These business rules describe how the DDAM interacts with other DDAMs. A portion of the container application consists of handling the interaction of DDAMs. The graphical interface consists of text or graphic display depending on the specifications of the DDAM. The most generic and adaptable solution is to create a container application in Visual Basic as an ActiveX control. This container application is then embedded within an HTML page and then deployed on the Web. There are commercially available ActiveX controls that have MS Access-like interfaces, Figure 2. Using one of these controls accelerates the development process and provides a high-quality user interface. The different container applications within this interface are composed of DDAMs. The DDAMs are reusable so that multiple container applications can use the same DDAM and associated business rules. ![]() Figure 2. Web GIS container application. The application consists of a data section, menubar, and toolbar. The toolbar contains icons of different container applications. The output of the selected container application is the data section. By selecting different container applications, the user accesses data for different tasks. The container application and DDAM system is flexible enough to allow configures to create powerful and complex applications. Once each DDAM is designed, developed, and tested, it can be incorporated into container applications. Changes to the DDAM, bug fixes, or enhancements are distributed automatically using the ActiveX distribution framework. Modularity of the system is one of its major advantages. Discrete modules can easily be combined to create more complex applications. The inputs and output of each DDAM are specified by parameters, but the internals can change. DDAMs communicate with other DDAMs through messages handled by the container application. Figure 3. The actual details of how DDAMs are written and work is left up to the developer. ![]() Figure 3. Interaction of GIS DDA Mand customer care DDAM. The GIS DDAM sends messages A , B, and C. The container application responds to message A. The customer care DDAM responds to message B. Message C has no receivers. An Internet deployment scheme leverages the features of DDAM ActiveX lineage . Each DDAM is digitally-signed and assigned a version number. When a new version of the DDAM is available, it is automatically downloaded and installed on the client machine. This simplifies software installation and upkeep. A user simply has to point to the correct location and open an HTML page in MS Internet Explorer or Netscape Navigator. All details of the software installation are handled by the ActiveX protocol. The building block nature allows quite complex applications to be built using DDAMs from different organizational systems. Advantages of DDAM Technology The advantages of implementing a Web container application composed of DDAMs include providing data across traditional hierarchical and departmental boundaries and reducing training through a consistent graphical front end. Departmental boundaries are boundaries based on the type of work each group is tasked to accomplish. Hierarchical boundaries are organizational boundaries defined by tasks required within a department. Benefits of providing data across departmental boundaries include facilitating interdepartmental communication, applying better costing to operations, improving provisioning timing, providing geographic billing history, and comprehensive marketing analysis. Inter-departmental communication is enhanced because users in each department have access to data from other departments and a better understanding of the work done by all departments. Better costing results from incorporating information from accounting, inventory, and billing into design and engineering plans. Improved provisioning timing is a direct result of presenting marketing and sales with up to data capacities and potential capacities. In addition, customer care has more information about timing of network builds, service interruptions, and scheduled outages. Geographic billing history is the integration of the AM/FM data with billing history. Geographic marketing analysis is better defined by combining information from GIS, engineering, billing, and network operations. Benefits of crossing hierarchical boundaries include greater independence at the user level, streamlining of business processes, and generating rule sets. Independence at the user level stems from access to better and more current information. This results in less managerial interaction. Better information presented to users allows them to make quicker decisions, streamlining the pertinent business processes. Configurable rulesets built into DDAM allow flexibility in changing parameters of different processes without additional software development. A graphical front end results in a decrease in training time, an intuitive graphical user interface, and ease of customization. An application deployed on the Web requires little training as compared to multiple enterprise-wide applications. A user using a Webbased application has only to get acquainted with one user interface instead of the separate user intetface for each enterprise-wide system. This cuts the required training significantly and allows users to be productive more quickly. Intuitive graphical user interfaces are paramount for getting users to actually utilize a system. A system may have great features and provide significant improvements to a company’s business processes, but if users are unwilling to use it, benefits will not be realized. The plug-andplay aspect of the DDAM framework greatly eases customization. Configuration of container applications can satisfy changing business requirements. Example This example includes functional descriptions of DDAM for GIS, customer care, billing, network management, network operations, and marketing. These DDAMs are geared toward providing comprehensive integrated service for telecommunications companies. The GIS DDAM includes geographic displays of landbase, outside plant, inside plant, and network infrastructure. Each object displayed in the DDAM has attributes that may be stored in the GIS database or obtained from an external database. Objects are displayed at different viewscales depending on how the user zooms in and out. Navigation features allow the user to quickly navigate using directional buttons and zoom in/out features. On object or region selection, a message is broadcast to all other DDAMs with the object’s parameters. The customer care DDAM displays information about a specific customer. It receives messages updating the current customer and sends messages telling other DDAMs to update themselves depending on the type of query selected. For example, a goto address button sends a message telling other DDAMs to display a map of the address location. Information displayed about each customer includes address, services, and contact numbers. The customer DDAM may access data from external databases and displays information in a tabular form. The billing DDAM is similar to the customer care DDAM in that it obtains information from the GIS DDAM and displays tabular data. This module can also be configured to generate summary information for a specific region. This way trends can be observed in different geographic regions. Amount, timing, and timeliness of payment can be displayed with a geographic correlation. Network management displays information about current network elements. Pertinent information includes capacity, utilization, and alarm information. The network information can be grouped according to geographic areas and ties closely with the GIS module. Selection of a network element can trigger display of it in the GIS DDAM. In addition, the customers served by these network elements and associated circuits can be displayed. Network operations show information about the status of plant builds and the temporal availability of service. Service in an area can be displayed, showing timing and availability of network elements. As-built data and data in different states can be examined to determine the current status of the physical network. Marketing shows the potential customer base in an area and can generate estimates of potential revenue with a geographic basis. Information can be generated for different geographic groupings. Customers and potential customers can be segregated by building, block, zip code, city or geographic region. This can give a better understanding of the potential customer base and help target marketing. Data in a telecommunications business is inherently geographic in nature, Figure 4. One useful DDAM is navigation to the customer location. Customer location can be determined from street address, phone number, or name. The more sophisticated the system, the more accurately the customer can be located. ![]() Figure 4. Samplecontainerapplicationshighlightingdifferentuses of the DiscreteDataAccess Modules(DDAMs). Geographicmarketanalysisintegratesinformationfromthe GIS, marketing, customercare, and billing.Circuitassignmentis drivenby customercare and incorporatesthe geographiclocationof the customerfromthat accessnode in the provisioningprocess. The average networkequipmentcost can be used to determineif specificbuildingsor areasare profitable. Engineeringdesignreviewallowsan engineerto examineas-built informationto determineif proper configurationhas been followed. Other DDAMs are triggered by the customer message and can display information about the selected customer or customers. Another message is to display information about all customers located within a geographic region. Yet another option is to display customers affected by a specific network element or network device. Conclusion Integrating information from GIS—customer care, billing, network management, network operations, and marketing together into a discrete, modular, and maintainable system— makes sense for the following reasons. First, training costs are reduced. Users adapt to an HTML application easily and navigate using intuitive interfaces with point-and-click operations. Second, users are able to share information among departments without knowing the details of each department’s system. Next, a modular system reduces the cost of development of each module and reduces interdependencies of each module. Also, leveraging the modularity of DDAM systems allows a company to implement a working system much more rapidly than developing an entire system. This system can be implemented using a plug-and-play methodology, building as you go. Finally, this system provides data from enterprise-wide systems to users at all levels of an organization with little training and facilitates more efficient and quicker decision making. | ||
|
|