Stop your GIS project now!
Stop your GIS project now
Stopping the GIS project does not mean abandoning the groundwork..
Stopping the GIS project means this:
-
Stop thinking about a GIS as a thing - a system. - it's hard because GIS stands for
Geographic Information System. Our current GIS is a host based stand alone system.
While we can import and export information, the system is not architected to serve data
and functions to other non-GIS applications.
- Stop thinking about interfacing a GIS with other systems, like SCADA or work
management. The current method of integration is to extract data from one system and
import the data into another system. This is in contrast to having an application live
independently from any "system" but be able to access data and functionality from the
network.
- Begin to think of serving information to business process applications or customer
touchpoint applications from a spatially oriented service.
- Unbundle classic GIS fi.mctions from the spatial data. Today, in order to use GIS
functionality, the user must be in the "GIS environment", instead of in the users own
business environment.
- Continue to convert paper maps and records into digital form. - a "classic" GIS is not a
bad place to start storing the information. The groundwork must be maintained.
- Identify business needs outside of the "classic" GIS that could be enhanced by spatially
oriented information.
-
Simplify the data model. The current data model was designed to be managed by a
"classic" GIS. So it is structured around "classic" GIS data structures.
Services vs Silos
Historically, information technology solutions have addressed automation of manual functions.
Billing, engineering analysis, calculation of energy consumption and work scheduling are
examples of utility fhnctions that have been automated for many years. The implementation of
these functional applications is generally long, sometimes measured in years. As an example, the
first SCADA system at Boston Edison was specified in 1978 and came on-line in 1984. Further,
the system requirements needed to be specified in very minute detail. Once the systems were
implemented, changes in functionality were expensive, disruptive to the production system and
took a long time to make. If the systems were vendor supplied (as was the case with the original
SCADA system), changes to the system might even be impossible to make. In the case of
SCADA, the vendor went out of business.
Today, the business needs cannot be specified in detail for implementation 1 to 2 years in the
future. Often, the business need may change very quickly. Consider that the rules for Electric
Industry Restructuring (deregulation) were still being debated on the Massachusetts House Floor in
November of 1997, yet the implementation was scheduled for January of 1998 (later moved to
March of 1998). Modification to the billing and customer system was difficult because of the its
highly integrated and the lack of lead-time on the specific rules.
Historically IT systems have modeled functions. It is not surprising that when a company moves
from a functional organization to a process model, the existing IT applications do not fit well. The
one dominant feature of the process model is that the company is organized around a business
result, not a business function. The business result is often the consequence of a customer request
(touchpoint). The other feature is that the business or process unit does not have to own all or any
of the services that are required to meet the business result. For example, the process, such as New
Customer Connect is supported by services, such as Construction Services, Engineering Services,
Accounting Services, etc. Some of those services are owned by the company, some can be
purchased externally. Other processes are supported by many of the same services. In all cases,
the services have no business need in of themselves. They only exist to support the business
processes. In a functional organization, units tend to be autonomous, holding, creating and
controlling all data, creating projects, and then handing off intermediate results. Data and
information is often duplicated from one functional group to another.
Similarly IT systems that are modeled after functional groups tend to be autonomous, hold, create
and control all the data needed for the applications and often contain redundant and sometimes
inconsistent data.
A characteristic of a functionally organized IT architecture is that data handling and applications
tend to exist together.
In contrast, an IT architectural framework to support a process model would look like this:
-
IT applications drive toward the business result. For example, a business process might be the
development of an estimate of outage time.
-
There may be supporting services that are provided by other applications and data. Those
services might be database, scheduling, timing, real time services, or weather services. None
of the services need to be owned by the business process applications.
-
The services are provided to the network and are available to other non-related business
processes.
-
Data creation and maintenance does not have to be owned by the business process application.
Data about trouble calls may be part of a process called "Collect trouble call information."
Data about geography can be created from geographic services. One would not want to
manage geographic data within a trouble call information process, nor should trouble call
information be managed from within a geographic service.
-
Regardless of where the data is created, the data shall be available to all business process
applications. The concept of systems "talking to each other" is analogous to hand-offs in a
functional organization. Hand-offs are where most errors are made, where communication
fails, where efficiencies are lost and where customers get lost. Single results focused business
applications that dip into the network for data and services don't require hand-offs.
