A small utility company has three primary locations across its service area. At these locations, customers can pay bills, batch processing can be performed, and reports are generated. Customer service requests are also dispatched from the largest of these primary sites. In addition, there is a centralized maintenance shop in which all of the needed equipment and vehicles are stored. Finally, parts are maintained and inventoried in a distribution office. All total there are five sites, each of which has some connectivity needs.

Without the IDS, even a relatively small situation such as this would likely require a WAN, which could be cost-prohibitive. As a result, such a set-up would rely more on complex process engineering than on solutions that eliminate complexity. For example, if a customer walks into primary location #2 with a billing problem that results in a customer service call (i.e., the meter needs to be rechecked), then primary location #1 must be notified to page the maintenance shop to ready a driver and vehicle. When the repairman gets there, he finds a part is needed, so he must go to the distribution center to see if the part is available. If it is not, he must notify the paging location that the billing issue cannot be resolved until the new part is available. After all this, primary location #2 will still be unaware of the current status unless a call is made to one of the other sites or a batch update is performed among all the sites. This is a very complex "solution" that does not address many of the basic issues.

With the IDS, however, a number of solutions can be found that eliminate the complexity associated with wide-area database communication. The deciding factor among all of the possible solutions would be cost-effectiveness, with total cost being well-below anything remotely comparable. One solution would be to house all of the customer data at primary location #1 (formerly the paging site) - this site will be abbreviated PL1. PL1 would then establish an Internet or private intranet presence with an ISP, and would have the IDS running on the server with security turned on. PL2 and PL3 would have Internet connections established with the same ISP, but they would not need to establish domain names or permanent IP addresses. If finances allowed, the distribution center would have its own Internet connection (with a permanent IP), otherwise it would use the same type of connection as PL2 and PL3. The maintenance center would be in a similar circumstance to the distribution center, in that an optimal solution would be for it to have an Internet domain, but it may be more cost-effective to house its data on the central server and let it connect as needed.

For purposes of illustration, let's assume that the company in question decides to maintain only one permanent IP address - the one at PL1. Each of the other four locations has a two-band ISDN connection with the same ISP as PL1 (performance is typically improved by using the same ISP for all nodes, since a hop or two can be eliminated). The resulting setup might look like Figure 3.

FIGURE 3: Case Study - A small utility company has three primary locations across its service area. Now, the question becomes what has the IDS has gained the establishment in terms of enhanced functionality. First of all, the development team has the opportunity to develop in-house applications using the IDS client in virtually any development environment they choose. If they have written the legacy applications in an environment such as C++ or a RAD tool, converting the legacy applications to I*net applications will be a small task (relative to starting from scratch). All of the Btrieve calls stay primarily intact, with the addition of a few calls at the beginning and end of each application and an extra parameter per call (which can be stored in a variable for re-use). Most of the changes can be copied and pasted throughout the system's applications.

The applications developed with the IDS clients will then be able to read data from PL1 and process the data as if it had come from a server at the same site, regardless of where they are deployed. Once a connection is established, the location of the data is completely transparent to the user. Reports can be generated at any site using the entire system's data, and changes made at one location can be viewed immediately at another location.

While this enhanced functionality is in all probability worth the cost of change, the IDS offers new functionality as well. For instance, the utility company now has an Internet presence. If desired, the IDS Java class library may be used to provide customers with up-to-date account information via the web, or it may create and distribute applications for use with the IDS. (This is an instance where the benefits of Java might outweigh the costs, given the heterogeneity of the user base and the limited scope of the application.) In addition, workers in the field can have immediate access to all of the data at PL1 with only a phone connection and a portable computer (e.g., a Windows CE machine - cost: approximately $500). Parts, vehicle status, customer records - all could be viewed and modified as the field application deemed necessary. The field workers could even use the same applications developed for in-house use, without a recompile! (Windows CE applications would likely need a recompile and some rewriting, due to memory and OS considerations).

With the enhanced and added functionality, the process would become less dependent on consistently correct choices and would operate more as a single unit. In the example above, the process could theoretically be changed to the following:

The customer has a problem with the billing amount, so she goes to the web and leaves a request for a bill review, stating that she thinks the meter reader is misreading her billing. The data goes to PL1, where it is read as a service request by a scheduled reporting program at the maintenance site. The vehicle is dispatched, and the serviceman finds that the meter is indeed broken and begins the repair work. Needing a part, he uses a phone on-site to check the part's availability. The part is unavailable, so he tells the customer and changes the customer billing record to reflect the situation and avoid mistaken late charges, penalties, etc. PL1, PL2, and PL3 reflect this in any reports and inquiries made from the moment the entry is made in the field. When the part arrives, the part shop updates the inventory at PL1 (probably through a batch process); the update program changes the back-order work request to available and sets the record to be reported on in the morning by a process at the maintenance site. Maintenance runs the report and sees the part is available and the status of the work order. The service worker is dispatched and goes to pick up the part before going on site. At the site, the serviceman fixes the broken meter and updates the customer's record to reflect the change and the correct billing amount. The customer would then be able to view the billing changes on the web immediately after they had been entered by the field worker. She mails in her check and is satisfied with the result.

Thanks to the IDS, the entire process has become automated, eliminating unnecessary effort and human error. At no point in the process was the data from one application or site unable to see data entered by another application or from another site. As a result, applications can be developed based on the work that should be done, rather than based on the current point of process communication among the sites. The customer has saved a trip (and likely, frustration), and the workers have become more efficient and more accurate. All reports run at any location are up to the minute with respect to changes made at any other location.

Total cost in dollars? The cost of the IDS plus an on-site web presence. Total cost in development? Much less than any competing alternative, since the development environment was chosen by the development team, not dictated by the process. Because the IDS can be employed on a number of servers with minimal or no changes in properties or code (depending on how a given application is written), the entire configuration is scalable across multiple servers at multiple sites. New offices opening need only an Internet connection and they are equally connected to the full utility system. New applications can focus on the desired task and performance rather than connectivity. Finally, Btrieve was not needed on any system other then the machine running the IDS, which reduced configuration and installation issues. In short, the IDS is simply the best tool for writing applications that work, that work well, and that let people get to data.