Systems Architecture and The Problem with GIS

Systems Architecture and The Problem with GIS

Lee Margaret Ayers
PlanGraphics Inc., 22230 NE31st St., Redmond, WA 98053
ph: 206-836-0937
Internet: lee@osisoft.com

Jon Blunt
InfolEd, 1329 Highland Ave, Needham, MA 029192
ph: 617-455-0065
Intemet: jblunt@infoed.com

Abstract
Cunently many AMNGIS's exist aslegacy systems within theco~oration. Notunlike many other corporate legacy systems, these systems are difficult to integrate and their impact within the organization is limited to a select group of users — the vision of desktop GIS still remaining a vision. Usually, by the time the technology is implemented (and data converted -- which represents the greatest investment), these systems tend to be outdated. The cost to initially implement these systems is so great “thatupgrading them cannot easily be justified. What are the characteristics that make these systems legacies to the corporation? How will you know the GIS you implement today does not fall into this category once new advances in technology are made? Are the newer or upgraded older AMIFIWGIS’s any different? How easily can your software link to other databases without additional programming? Where is your vendor’s commitment with regard to the changing desktop? The authors will discuss the component elements of AM/FIWGIS with regard to single, two and three tier architectures and a way to consider/design an AIWFIWGIS independent of limitations which may exist in the software.

Introduction
Corporations have two problems to address in creating a viable systems environment to support their business. First they have to find mechanisms to have their business vision incorporated in the design of their information systems. Second, the systems have to be constructed with enough integrity to deliver the benefits desired. The first issue is the domain of corporate Information Architecture. The second is the domain of system architecture. For a solution to be truly “enterprise-wide,” the selected system’s architecture should fit within the corporate information architecture. Without a corporate architecture, system selection becomes a challenge. It results in the current mishmash of systems we see in corporations today. These systems do not work well among one another, they are costly to integrate, and they are not easily accessed by the majority of the organization.

System Evolution
Technological advances in creating what is now referred to as the “Industrial Desktop” will allow engineers to completely reshape the way current analysis is performed. The Industrial Desktop is comprised of several things, but primarily it is built upon concepts of Three Tier Architecture; a single window view; a stable development environment for vendors and users which is centered around technology from Microsoft; and borrowed technology from the desktop. With regard to the desktop and the industrial desktop Kennedy states, “The similarities are important because the industrial desktop is too small and too specialized to generate its own applications and standards. We must “borrow” technology from the office environment or wherever it springs.” (1) Industrial desktop software might be an application which predicts equipment failure. This application will be comprised of different software applications which are interoperable among one another because they share common methods for making information available in a standard format. Development time for these applications will be reduced to a fraction of what they are today.

Compare this vision to a typical approach to selecting and implementing an Automated Mapping/ Facilities Management/ Geographic Information System (AIWFIWGIS) in the following scenario: (Each stage is approximately three to four years.)

Stage 1: Primarily, the AM/FM/GIS is brought in to replace manual drafting methods with automated drafting methods. By the time the system is implemented it is outdated because there is no access to information about the asset (which is needed by other departments). The number of manual systems for tracking information is growing. Transformers are in one database, switches in another, poles in another, etc. Theses ystems are hard to maintain manually, so as more information is needed about the asset, less and less information is available.

Stage 2: Eventually anupgrade isProcured. The new System Provides access to outside relational databases, but a database model has to be developed because every utility is unique and different (not true, but this is the current philosophy). It was a costly change since the attributes for each feature had to be captured. After conversion and the applications written, it turned out that some of the data were not accessible because of unperceived limitations in the data model and in the limitations in the software upgrade. Soon after that upgrade or fix is completed, it is outdated. The company needs to perform outage analysis but no electrical connectivity was built into the data model, because the AM/FM/GIS was installed as a mapping system. It had not been perceived that the AIWFIWGIS would support Outage Analysis, or Maintenance Management, or Engineering Analysis, or etc.

Stage 3: unfortunately too mUChmoney was spent populating the database during Stage 2 to recreate the information under a new structure, so a consultant had to be hired to develop a work-around. The consultant did the best they could under the circumstances. The overall performance of the system is so-SO.

The system is not very flexible to meet the changing needs of the organization. The system cannot be easily linked with the newer systems being implemented. Other than programmed applications, information about the asset is only available to specialists. New applications have to be contracted. Occasionally the existing applications go down. As it turns out, the developed model has several limitations and few people use the system.

Stage 4: The industry has changed so much integration with the corporation isnow entirely custom the vendor is no longer doing development on your version of the software and is now offering a different solution based on newer technologies. A translation application could be written to move the data from one model to the other, but even so, there are no applications in the newer environment. All of the existing applications will have to be rewritten. The whole system needs to be replaced, but management will not support this kind of expenditure to recapture information again. There are many variations to the above scenario. If the company had elected to procure rather than upgrade the old system, it is still likely they would have had to create their own data model and applications which would result in the same problems. Regardless of the nuances the project direction takes, it is not likely the planned system will outlive its envisioned functionality. The problem is further escalated as these systems are implemented based on an immediate and overdue need for technological change. Under these circumstances, there is not enough time allotted to “doing it right .“ Our focus on system selection is typically based on functionality, while the System Architecture is overlooked. Basing system selection on functionality can be deceiving. Another overlooked issues is the lack of a common framework upon which to implement systems -- which an Information Architecture addresses. Add to that an improvement-oriented rather than a business-oriented implementation to AM/FM/GIS and an immediate need to implement something and we achieve the tail-chasing scenario described above. We need an understanding of Systems Architecture and an additional set of logic, provided through Information Architecture, to help us to narrow systems selection and broaden our ideas for an acceptable implementation.

Systems Architecture
How well do most AM/FMGIS systems fit into our defined architecture? Since most AMIFIWGIS s are graphic driven models with links to data, rather than data-driven models with links to graphics, the answer is, “not very well.” Most AIWFIWGIS decisions have traditionally been made on evaluation of the application specific functionality. The fact that many AM/FM/GIS can be linked to databases lulls the user into thinking they are looking at an enterprise-wide solution. The methodology described above changes the relative value given in the decision process to features to integrating capability and manageability of the application. The system called for in this architecture has to be a good citizen sharing data with and providing services to other applications.

As this decision approach becomes more common it will accelerate the movement away from the isolated AM/FM/GIS systems we are familiar with, to systems that look much more like the new client-server business systems in which utilities are investing.

Single and Two Tier Architecture - Where we have been:
Today, most corporate information models represent two tier and single tier architectures. Single tier is reminiscent of monolithic systems with large applications on them and connected terminals. Later, applications were decoupled (to some degree) from the data into a client-server architecture, and then the data were distributed. Not all theses systems were true client-server. There may be some degree of shared data, but the proprietary graphic user interface is integrally linked with the application, and often, some of the data. Another GIS with its own graphic user interface could not access the data of another system without an interface. The interface will probably have some unique maintenance and management requirements that will have to be modified when the software on either side of the interface is upgraded. When we refer to the term ‘islands of automation’ we are describing two tier systems. These systems dominate the corporate environment today. A majority of the systems which are being implemented today are still two tier.

Three Tier Architecture -The
key to three tier computing is that the end user need not know how the data are organized in order to access and use the data. Simplicity is managed through system architecture and philosophy. Three tier architecture separates the system into presentation, application (or business rules or methods), and database (Figure 1.)

Figure 1. The layers within Three Tier Architecture
The presentation layer can be thought of as the common, graphic user inte~ace (GUI). Whether this is agreed upon or not, Microsoft has made a major step toward providing a standard graphic user interface to the industry at large. In the future, applications will come together in a single window environment, which shares a common presentation layer. The philosophy of three tier architecture is that business methods and rules are shared within the application layer, rather than programmed into each different application. An example of this is the number of redundant network models which exist throughout the corporation. To be a competitive entity, the corporation will have to find cost-effective business models where the margins of operation are well understood. With all the different models that currently exist this will be hard to do -- not to mention the hassles of integrating these systems. Today, the AM/FM/GIS has a network model, the Supervisory Control and Data Acquisition system (SCADA) or Distribution Management System has a model, the planning department has a model, there is likely a model for transformer load management, and the list goes on. In the future, a single network model will reside as a shared method in the application layer for all to use. Communication between the GUI and application layer occurs through Active X, AKA: Object Linking and Embedding (OLE). While following in the steps of Microsoft often feels like a forced march, vendors who agree to expose and share their business rules by providing access to their system via Active X, agree to making their system interoperable with many different applications – providing synergistic advantages to their users.

An example of what it was like without Active X follows: if one were working in Microsoft Word, one had to leave Word to perform a calculation in Excel. Today, with Active X, an Excel spreadsheet can be modified inside a Microsoft Word document. An example of how this would apply with more of a utility specific application follows:

If the utility network model was built with an AM/FM/GIS which was Active X compliant, then one could easily link real-time data (which is in a format that is Active X compliant) to the AM/FM/GIS network model. Calculations from Excel could be dropped into the graphic as well. The graphic might, in turn, be dropped into the Word document and emailed somewhere in the corporation. Provided that the receiving person had network access to the real-time data, the email would arrive as a small application, ready for viewing. The real-time link between AM/FM/GIS and SCADA is inherent in the design. The need to write integration software between two separate applications has been eliminated because vendors are adopting a common solution for communication between applications.

The cost savings in this functionality alone have not been grasped by the industry. Corporations will likely implement more than three tiers – especially with regard to the application layer. For instance, if the network resides on one layer, another layer may contain component applications which allow upstream or downstream tracing of the network. These component applications for tracing can be shared by Outage Analysis and Feeder Analysis -- without having to hard-wire the tracing component into each different application.

The data layer, within three tier architecture, is a data warehouse, or it can be multiple databases. One of the problems of integrating databases has been the proprietary nature of each of thes ystems. Vendor agreement on shared, common access has given rise to different standards. Open Database Connectivityy (ODBC) is one of the most agreed upon standards. Communication between the application layer and the data layer will occur through technology such as ODBC (or Active X). A major change in systems design will occur when vendors and developers take a data-centric view of information, rather than an application/project view. The former assumes the data will be used by a variety of applications rather than hard-coded into a specific design. AM/FM/GISs applications have generally been developed with a graphic-centric view, rather than with a data-centric view In the future, systems as we know them today will be thrown together, at will, by a variety of users (of different ability), into applications we could never have imagined, and in a fraction of the time it took them to be built the first time. It is very possible that the users who are currently familiar with the Windows environment could excel in application development over those who come out of a more traditional programming background. For the first time in history, market share has determined a stable platform for developers and users upon which to rely. Through these design concepts users will be enabled rather than stranded. But until then, the corporation will have all three tiers of systems with which to deal. (Please note: no references on Three Tier Technology have been provided, however, there is a wealth of literature available on the subject.)

The Evolution of AM/FM/GIS Technology
Over the years, we have moved from isolated monolithic systems to “islands of automation,” and from “islands of automation” to modular interconnected systems - with the later being the newest and least implemented of thes ystems. There are certain benefits to having such a wide choice ofs ystems: the ability to select best of breed, independence of particular vendors, scalability, and evolutionary change.

At the same time each company takes on the burden of managing the integration of unique solutions. Traditional AM/FM/GIS systems do not quite fit the three tier architecture. These older systems are monolithic and proprietary, or they are “islands of automation”; many of the newer systems are still two-tier, but great attempts are being made to break out of the limitations these solutions offer. (This is a reminder that the problems expressed here are not unique to AM/FM/GIS – take a look at SCADA - take a look at Customer Information Systems) Many AM/FM/GISs use specialized tools and unique database formats. The functionality provided is tied to unique user interfaces and other technical limitations that limit the universal distribution of geographical data and analyses throughout the organization. The systems which are customized installations leave little chance of upgrades when the underlying technology changes. In fact, the utility can be assured that the code will have to be rewritten with the next release. Figure 2. provides a general diagram of the components within an AM/FM/GIS. Following the diagram is a description of each of those components and where they are in their evolutionary stage.

Figure2. Ageneral view depicting thecomponent pieces of an AMIFIWGIS
Components of an AM/FM/GIS
Graphic User Interface (GUI): First generation PCs did not have the performance to manage very large graphical data sets and only recently have the machines had the power to drive the Windows bit mapped display at a speed that comes close to direct vector graphics. As a result GIS systems have developed their own user interface that often is embedded in their first generation version of Windows. Standards in this area are still evolving.

The next generation of user interface integration from Microsoft, OleDB, will allow users to build composite drawings and models created in different applications, while still allowing each component to be edited. This type of capability will drive AM/FMGIS vendors to full support of standard user interfaces. Buyers have to be careful when investigating new systems as not all “Windows compliant” offerings will support either ActiveX or OleDB. Tools/Commands: Most AM/FM/GISs are tool-boxes. Except for the vendors which focus solely on the AM/FM industry, few vendors offer turnkey solutions which do not require a degree of customization. In any case, it is often the tools or the commands which differentiate one product from another, Tools or command functionality consists of data import and export, raster-to-vector conversion, cartographic layout and design, spatial analysis, data and feature query, database links, etc. While base functionality is similar between systems, as tool-sets they are all unique and proprietary.

However, it is in their full functionality that systems have competitive advantage. Again, AM/FM/GISs are not unique in their proprietary offerings. Tool sets cannot be made available for operation on other databases or applications unless that tool’s methods can be shared through compliance to a mutual standards. If you are looking for a long-term solution, do not select on functionality alone. In the future, the tool sets will be shared as a common and adopted method in the application layer of the corporation. One AM/FM/GIS company is developing component-based tool sets. These tool sets act as large objects, which will in turn, interact with other objects. These component-based tool-sets will allow applications to be developed in a shorter period of time.

Language: The programming language used within the AM/FM/GIS is most often proprietary. Often, the vendor creates their own language because the standard languages do not provide adequate access to graphical features. These languages are usually far simpler than standard programming languages which make them easy to learn. However, before the languages can be learned, the developer must have a clear understanding of the underlying technology of AM/FM/GIS and what affect tools and commands have on the AM/FMfGIS database. In this regard, it is very difficult to bring in a programmer from elsewhere in the corporation without providing considerable training. Some vendors utilize languages which mimic more standard languages. In this case, the new user only need learn the underlying technology. Utilities tend to push the limits of GIS technology when building Ah4/FM/GIS systems. The utility operating environment requires a robust programming environment -- where production-quality systems can be built. Only a few vendors have taken a step toward this level of quality. But, to date, vendors have not been pushed to implement robustness in their code or debugging tools. Interoperabilit y (Active X) at the application level will reduce the issues of having to code interfaces between systems; it will also ensure a degree of quality – as earning the “WIN ’95” logo does not come easily.

Graphics: A detailed look into the design of a graphic feature yields a series of x-y coordinates (for vector-based systems). What becomes unique is the number of features (points, lines, polygons, complex features, etc.) the software contains and the way the vendor manages these features. Graphical features are managed uniquely between each system. These features may or may not have unique identifiers and attributes associated with them. In the future, graphical features will be shared objects between applications. And a single network model will reside as a shared method/component within the application layer. This will reduce the number of redundant models that currently exist.

Spatial coordinates: Not all AMIFIWGIS systems offer spatial capabilities. Besides access to real-time information (which is changing), the AM/FM/GIS differentiates itself from SCADA through its access to spatial information. The x-y coordinates associated with each feature are usually stored in proprietary records or files linked to the graphic through a unique identifier. Where it makes sense, some software allows the x-y coordinate to be pulled out and stored in an outside relational database. As a rule, vendors do not expose their formats. The final resting place for spatial information is within the data layer.

Unique kientijiers/Pointers: What gives GIS its power is the ability to uniquely identify and spatially reference features. This is all managed through a unique identifier. The unique identifier acts as a primary key for shared information. In the future this information will reside in the data layer.

Model: The models available on the market areas varied as there area number of vendors multiplied by the number of implementations they have. The dominant models include topological, hierarchical, object, and relational. Each model is then further made unique by the configuration of its features. For example, a device (e.g. a switch) could be modeled as a point or as an arc. Since no utility is the same (again a misnomer), each of the systems is put together uniquely (remember the GIS is a flexible toolbox).

The model can be comprised of a number of things, such as the graphic related to certain attributes might make the model. A topological model is created through relationships of features and unique identifiers. Hierarchical models are simply node connections to the next higher or lower level of the tree. Object models have qualities associated with features - this way information about a feature can be inherited rather than programmed over and over. Every model has pros and cons. A cautionary note about objects: the word “object” is used quite loosely with regard to models. Some object-based systems use only object language, while the internal workings remain relational and proprietary. If your company does not have object programming expertise, you may want to scrutinize the achievable benefits being offered. Some companies model features as objects and use standard Structured Query Language (SQL) or ODBC to access the data. Most systems have some SQL aspects if they link to outside databases. Whatever the selected model becomes, in the future, the network model will reside as a common method, while the data associated with the model will reside in the data layer.

Attributes: Except for some applications which still store attributes with the graphic, attributes are already being moved to the data layer within the organization. If they are locked in an application and there is no standard wrapper (ODBC) or gateway to a relational database, then the information is locked away and unusable for even the most simple user. While the previous breakdown of each component piece within an AM/FM/GIS may sound grim, these problems are being addressed through a number of innovations. These include component-based systems which adopt industry standards, and whose companies adhere to an adopted standards for qualit y control.

Another is through spatial data engine technology. Spatial engines take the evolution of the user interface to its logical conclusion that GIS server and client do not have to be developed jointly. We are seeing an inkling of this in the newer desktop applications for querying the AM/FM/GIS database. Spatial engines are still in their rudimentary stages of development, but the implementations have been successful thus far. In the future we will see client software, decide how to display or use the information returned from the spatial engine. We will also see innovations which utilize the Intemet and web browsers. Corporate network structures will provide immediate access to AMIFM/GIS users through the intemet as well as the “intranet.”

Information Architecture
With each technology evolving at different rates every organization has to decide where it wants to be on the learning curve, and how to balance technical and business risk. The ideal scenario is a stable, successful vendor, selling a well-designed, mature, modular product using industry standards, that is competitively priced. Unfortunately, changes in technology and market structure do not follow these nice easy patterns. Established vendors are best positioned to invest in new technologies, but they have to protect an installed base.

Information Architecture is a mechanism for making explicit these tradeoffs and giving the technical side of the house clear parameters within which to create successful systems. Where a Systems Architecture is a description of the components of the system, their interfaces, and behavior, Information Architecture is about providing a decision framework for the selection, design, and evolution of the systems. The assumption is that technical excellence is not enough. Rather, the system has to fit the organization that is going to be its owner.

Approaches to Information Architecture
There are three basic approaches to developing an Information Architecture: rational, declarative, and heuristics. (2) A rational approach assumes all the data is available to make the best decision. It emphasizes measurement, calculation, and optimization. When this model has been used by Information Systems (IS) for complex problems it has usually failed. Declarative is typical of traditional architecture where if Frank Lloyd Wright says the door will be on the right, on the right it will be. This is fine if the authoritative source is inerrant. It is disastrous when the authority is fallible. Of all the methods available, heuristics is the most powerful for managing complexity with limited information. Examples of heuristics from system architecting include:

The greatest leverage in system architecting is at the interfaces.
No complex system can be optimum to all parties concerned.
Regardless of what has gone before, the acceptance criteria determine what is actually built.

Heuristics attempt to capture best practices and relationships that are generally true. Heuristics always need an interpretation and are there to provide a starting point for the development of a rigorous understanding of the problem. For a better understanding of heuristics, please reference Systems Architecting: Creating& Building Complex Systems, by Eberhardt Rechtin. (3)

Applying Concepts to A Real-Life Scenario
The following is an example of where developing an Information Architecture and then a Systems Architecture set a framework for AM/FM/GIS decisions. The work was done for a public power utility by a small team of architects reporting to the director of the utility. The architects’ charge was to develop a systems plan for the utility that could be implemented by a utility systems or systems integration specialist. The responsibility of the architects was to identify an overall design approach that would best meet the needs of the utility. Some of the basic parameters set by management included:

Minimize development cost: the systems budget was limited.
Consider long-term cost of ownership: design to reduce the future costs after implementation.
Review management requirements: the utility did not have a large systems group.
Prepare for deregulation: systems had to be adaptable to an uncertain future -- where management would need access to operating and industry data to analyze operating scenarios and strategic options.

Step 1: Brainstorm
The first step was to develop a framework for design; what will work and what will not. This work required adding to the business goals an understanding of the current system and the capabilities of the organization at planning and analysis. At this organization it was easy to compile an inventory of systems since many processes were still manual. It was evident that the existing commercial systems would need to be replaced completely, and that the existing mix of desktop systems was of varying age and dubious ancestry. There was limited use of CAD and no AM/FM/GIS capability. Based upon this information the architects developed a set of heuristics, or pseudo principles, that articulated the design implications of the goals and the current state. The phrases chosen were short declarative such as:

Buy don’t build.
Use appropriate technology.
Don’ t mess with the code.

These were neither specific nor directly capable of being implemented, but they had the advantage of not needing any explanation.

Step 2. Synthesize
These pseudo principles were then refined into more extensive and formal principles for discussion and agreement by executive management. These principles captured the critical business decisions and formed the first level of design of the Systems Architecture. Examples:

Uses mainstream technology for which there is a local talent pool.
Only support one server operating system.
All mission critical data is stored on the server and subject to the organization’s business continuity policies.

All purchased applications provide the functionality required without custom programming. The concept of the industrial desktop was also invoked. Another principle required that each user be presented with information and tools within the context of the task. That is, they should not have to log into another application to collect information to complete an activity, the system should provide those navigation tools.

These were made as prospective statements; none of them were true at the start of the project. Stating them in the present heightens the tension between the current state and the need to change. Step 3: Technolon Architecture Developing these principles, and developing cogent rationales and implications for each, took considerable effort with a number of iterations and scenario testing of alternatives. But once there was agreement on these principles it was possible to decide the basic technology that was the target of the design.

For this size of utility, less than 200,000 customers, it was agreed the target platform architecture would be Windows NT and Windows 95 for all systems. This platform provided the easiest access to qualified technology professionals. And the expected debut, in mid ’95, of the Pentium Pro supporting quad processor servers, and then RISC-based architectures above that, meant that the platforms were truly scalable.

This architecture decision nipped in the bud a previous decision to move to Novell. The disadvantage for this organization of Novell was that it is an excellent file serve, but not a good choice as an application server. There would have to be a second server operating system alongside Novell, probably either NT or UNIX. The architecture review avoided this duplicated cost by positioning Windows NT as both the file and print, and the application server.

Step 4. Confirm viability
While this decision to base all applications on Windows client-server architecture looked good on paper, it was necessary to confirm that it was possible to acquire systems that conformed to the architecture. (Note that at this stage in the process the issue is feasibility; the search is not for the best system, just examples of applications that meet the minimum criteria.) The approach taken was to have an industry expert map out best practices in dividing the total space of systems up into application packages. The design emphasized four major packages: AM/FM/GIS, Customer Information System (CIS), Maintenance Management System (MMS), and Financial Management System (FMS). The proof of feasibility criteria was to find one example of each package that met the architecture criteria, and that could be integrated. The first criteria proved reasonably easy to meet. In each of the four areas, leading vendors of systems for utilities were porting their applications to Windows NT. There were questions about the stability of these systems since they were still in development. However the final decision was going to be made in a year by which time there would be more choice available.

Some technically excellent packages had to be discarded because they did not fit the architecture. Object oriented AM/FM/GIS packages were considered and then set aside as the investment in proprietary code would be too great. In two or three years we believe there will be off-the-shelf utility applications for object-based AM/FM/GIS-based solutions, but not now.

The integration criteria was more serious. Table 1. shows that there is considerable overlap between the functions provided by each package. Implemented naively it is easy to create a total system that is unmanageable. How for instance do you ensure that a service order created in the CIS system, is scheduled and prioritized within the AM/FM/GIS system, correctly triggers stock inventory transactions in the MMS, and is accounted for correctly in the financial system. Or, if the service call creates charges to the customer, how does that get back into the billing system? In the worst case, if one of the applications fails and corrupts its database, how do you set up the system so that it not only restores to a consistent state, but records in all the other systems are also consistent. Table 1. Shows the interaction needed between each defined area of work.

Table 1. Duplication of Functions within Applications

The architecture adopted excludes some standard approaches to dealing with this issue. It cannot be assumed that all applications operate within a single management framework such as Distributed Computing Environment, from Open System’s Foundation (OSF). Neither can there be extensive custom programming. Nor, because the aim is to use standard application packages, can it be assumed that it is possible to construct a single unified data base, or even a unified data model.

Identification of the characteristics of the AM/FM/GIS system became crucial to resolving this question. A GIS firm was hired to identify which AM/FM/GIS systems best fit the desired model. On their recommendations the decision was made to require the AM/FM/GIS system to store all the utility specific data in a relational database: that is to externalize attributes from the graphical representation into tables that could be accessed using industry standard SQL and ODBC tools. This supported a three-tier philosophy. It was identified that comprehensive utility AM~M/GIS applications exist in this form.

One technical principle had to be relaxed. It had been intended that only one enterprise relational database management system would be used. SQL server comes with Microsoft Back Office and is used by the System Management Server tool. However the database of choice for applications on NT is Oracle and the architecture now has to manage both. In practice, all mission applications will probably use Oracle so that there is a single environment for replication.

The integration solution adopted is that there will be a single record for each entity in the system. For example, all work orders will be stored in one of the systems even if they are created or edited in another. The creating application will be responsible for initiating the creation and maintenance of the record in the system of record. To make this easy, each of the major systems is required to have a defined mechanism for acting as a server for other applications. The preference is a published Applications Programmer’s Interface (API) that uses a standard mechanism, such as Active X automation, to handle the process. The architecture does not define the solution, it just identifies for the designer what their solution has to provide to be acceptable. The designer is then responsible for developing and implementing the solution.

Conclusions
The approach described here is intended to allow for evolutionary growth. New mechanisms for creating distributed systems are coming forward. The next generation of AM/FM/GIS systems will work with web servers and Active X to deliver unprecedented fi.mctionality to the desktop. The architecture adopted by our model utility does not directly address these possibilities. In practice many of the applications that will be purchased will be two tier rather than three tier client-server. This is a reality of the current marketplace. However, by developing an architecture that is data focused and treats AM/FM/GIS as a server for geographically referenced data and services, the groundwork has been laid for moving forward. Again, because in-house development has been limited it is expected that new releases and bug fixes for all the applications can be implemented easily. We also expect that in critical areas, AM/FM/GIS and CIS, the utility will have created upgrade paths to the next generation of technology as it evolves.

In many implementations, AM/FM/GIS systems have been considered hot house flowers of advanced technology that have to be chosen because of the technical performance in supporting draftsmen engineers and the rest of the technical community. This paper shows that a process driven by business values can lead to a different set of selection criteria. As distributed, integrated applications become more common, organizations need to develop an Information and Systems Architecture that elaborates which attributes of an AM/FM/GIS system are strategic to this enterprise, and evaluates solutions based on of their fit with the total systems portfolio.

For many reasons, the AM/FM/GIS (along with other corporate systems) has not been an “enterprise-wide” solution, but this is changing. With the advent of new technologies which focus on enabling users, the increase and availability of industry standards, and growing stability on the desktop -- workable solutions are around the corner. The evolution of AM/FM/GIS systems promises to give organizations more choice of technologies that are consistent with their enterprise Systems Architecture. Looking into the future we can expect to see AM/FM/GIS systems tightly integrated with the large business information systems such as SAP. But under current conditions, this fusion will not be easy -- rather like the mating of porcupines.

References

Kennedy, J.P., “Building An Industrial Desktop,” Chemical Engineering: Feature Report, January 1996.
Richtin, Eberhardt, Systems Architecting: Creating and Building Complex Systems, (Prentice Hall Inc., Englewood Cliffs New Jersey, 1991).
Ibid.