Chapter 4 Case Summary
4.1 Case 1: GIS Integration
Since early 2001, the agency has established its GIS platform based on ESRI software products, including ArcSDE, ArcEditor, ArcReader, ArcIMS and etc. However, they are expensive software and only a small number of licenses have been purchased. The agency has a number of other core business application systems, including Land Register, Permissions and Bioweb, they are in-house and Microsoft based thin client applications. Land Register stores and maintains records of all government own land passed to the agency for administration. Permissions system is used for processing permits for all kinds of activities that happen on the land. Bioweb is a collection of applications for keeping records of species and observations around New Zealand. All these systems require integration with GIS with requirements including showing business data on the maps and running spatial queries on the maps using selection criteria applicable to the business systems.
The integration had been a long running and multi-phases project(s). In the earliest phase before 2003, the integration was established by simply importing business data into the central GIS database by using data import stored procedures. Users used the specialist desktop client application licensed from ESRI to work with all GIS and business data. There were limited sets of business data and they were disconnected from their business repository. The main issue of such approach was that the GIS database was getting bigger and bigger as duplicated data had been created. In a later phase between 2002 and 2003, a browser-based interface (DOCgis) was developed by customising an off-shelf ESRI map viewer; business data were linked to the central GIS database by using views through linked tables. DOCgis works on the combined sets of data, based on the core GIS database and other business data through views established in the GIS database. More and more business data could then be added to the data sets, which would allow the integration to include more and more applications. Apart from issues associated with duplicated data in the GIS databases, there are other issues such as the integration is strongly tied with the business systems through linked tables and views. There have been many incidences when changes in the business databases had caused errors for the GIS database and DOCgis.
In 2005, a new GIS integration strategy had been adopted for adopting the latest .Net and XML web service technologies to develop a new GIS integration solution. It works on the core GIS database through the ArcIMS map service and a set of web services for retrieving data from various business systems. The ArcIMS map service is responsible for providing map images generated from the core GIS database; all other business data are retrieved through dedicated web services. In addition, the new solution works on an XML configuration file; it also includes new functional
integration features such as hyperlinks between various parts of other business systems and the maps. So far the new integration (GIS Viewer) has been fully integrated with Permissions and Lang Register systems.
4.1.2 Consideration for Research Questions
GIS systems are becoming more and more popular with large organizations, especially with government agencies. In fact, the agency had a specialist GIS team responsible for coordinating and developing GIS application for the department. GIS applications are also becoming more and more feasible and affordable as the technology becomes more accessible. For example, the latest release of Microsoft SQL Server 2008 has all the basic GIS features included, traditionally expensive license fee for specialist GIS software may no longer be required.
The agency is responsible for the administration of about two third of the New Zealand land mass and most of the coastline and sea territory. Fully functional GIS systems are essential tools for the agency to carry out its missions. A successful GIS systems in the agency must be able to provide users with complete and accurate information, which may include not only just GIS data such as maps but must also include other business data such as those from Land Register, Permissions and Bioweb.
The challenges during the development of GIS integration would be common for large government agencies. The challenges were highly complex as they involved specialist software such as ESRI GIS package, a large number of business systems such as Permissions, and large amount of data from various sources. They are important and would have crucial impact on the department business, for which the specialist GIS team is tasked. By investigating into the GIS integration in the agency, it would
generate highly relevant results for common system integrations for the agency and other government agencies.
In the GIS integration development for the agency, XML has only been used in its later stage since 2005. The case study would be an excellent example for investigating and comparing different integration strategies (with and without XML). XML applications have been extensively used in the integration development since 2005. For example, XML was used in the configuration file, for the web service interface and GIS queries. The case study would certainly provide answers for the research question.
XML has been adopted since 2005 for the new GIS integration (GIS Viewer). The case study would investigate why and how decisions were made to choose XML, including business and technical rationalization. The investigation into the decision and selection process would provide inside processes of IT department of a government agency. The deliverables of GIS integration projects have become essential tools used by the department users. Since they have been used in a day-to-day base by such large user base, it would be important to find out how useful and successful the new XML-based solution is.
Since most of the GIS integration system has been developed in-house in the agency, the case study would have a rich source of business and technical knowledge of the system. There are a large number of documents, system design and even source code for the GIS integration system. All these knowledge would help the investigator to track down and identify reasons for the solution being successful or not.
4.1.3 Summary of Case Findings
(Please refer to the appendix section for detail of findings and preliminary analysis)
1) GIS integration would be regarded as a combination of data, function and interface integration. It combined data of GIS (Maps) and business (Permissions) data. It could generate reports across GIS database and multiple business systems. It also provides a central user interface for interacting with those systems.
2) GIS integrations are common and important for large government agencies such as the agency, as it was argued in the business case and requirements document. GIS
systems need to combine data from other business systems to provide rich information including maps and reports for business purposes. Integration requirements usually include spatial queries on multiple systems and linkages among them, such as those specified in the Permissions GIS integration requirements.
3) The project has been a long running one over many years including two main streams of DOCgis and GIS Viewer respectively. There were many management and technology factors affecting the development, including the arising of new business requirements, availability of tools and other development resource (developers). They were the main reasons for the different approaches of the two GIS integration projects.
4) The early attempts of DOCgis trying to import and link data entirely from the backend databases as it was indicated it the NEGIS architecture diagram. It was a ‘quick and easy’ approach for simple integration features by limiting the scope within the backend databases, but it had many drawbacks, such as redundant data and maintenance difficulties. Most problems were caused by such tight coupling approach within low-level database objects such as linked tables and views. Such approach would also only feasible for single platform database server; any cross platform databases would make it very difficult if it is not impossible at all. 5) There were other major issues of the old DOCgis such as the lack of spatial query
ability and functional integration ability. They were the main reasons for the development of the new GIS Viewer when such requirement had arisen from the business. The new integration functions were essential enhancement for the business systems as they were described in the documents, including the Permissions II requirements, and Permissions GIS requirements.
6) The new GIS integration development was designed for fulfilling a new comprehensive set of integration requirements. It had been through rigid development processes including software evaluation, proof of concept and prototyping. The new design focused on integration of multiple systems through purpose built interfaces such as XML web service, as it was indicated in its system architecture and verified in the source code. The new approach was successful one as the project was delivered on time and within budget. It has become one of the major systems for the agency, as the usage statistics of the web server had
is also flexible and easy to maintain as new business systems such as Land register had been integrated with it with minimum cost.
7) The new GIS integration development has taken advantages of XML applications in many areas. Component using XML are the core parts for the new GIS Viewer project, including the new user interface and the XML configuration for business system integrations. XML web services are used for data integration to achieve loose coupling and easy maintenance. XML was a critical factor for the overall success of the GIS Viewer project.
There are some special conditions or limitations in the GIS integration case. They are: 1) All sub systems are based on Microsoft SQL server databases, linkage among
databases are easy and without any restrictions. Without such database platform, the first integration DOCgis could not be able to link database objects through the backend server, or it will be much harder to achieve data integration only using database objects.
2) For the new integration of GIS Viewer, development team were allowed to choose technologies from all the latest and greatest ones including XML, which is not usually the case for system development in large organizations. As from discussion with the analyst who overseen the development of Permissions and Land Register, many of the department systems, including Permissions and Land Register, were developed under strict time frame with pre-defined architecture. XML might not be used at all for GIS Viewer if existing software has to be reused or other third party component was chosen.
Current status of GIS integration:
1) The old DOCgis is still in use as one of the GIS integration interfaces. Other GIS desktop software such as ArcReader and ArcEditor are also be used by a few GIS specialist in the agency. Problems with its database integration pop up from time to time which regarded by some as system ‘hiccups’, as those connection are hard to find and easy to break when the database are changed. GIS databases are the major payload on the database server, as it has many regular and intensive processes for transferring data from business systems.
2) The GIS viewer is now a major business system like Permissions and Land Register. It works well except when the GIS backend server has its ‘hiccups’, as
the GIS Viewer relies on the map service which depending on the backend GIS databases. GIS viewer has not replaced the DOCgis for a few reasons. As stated in the Permissions GIS integration design document, GIS Viewer was designed for enabling the new Permissions GIS integration, not replacing DOCgis, otherwise power conflict would have arisen and new GIS Viewer might not be allowed to go ahead. As it was indicated in the requirement document and discussions with people involved, the former GIS manager was very adamant in upholding the DOCgis as part of the NEGIS framework and only support a limited and specific GIS integration development for Permissions and Land Register systems.
3) There had been ambitious plans for re-develop the entire GIS database to
encompass entire sub-systems, such as Land Register; new business case had been created and documented. However, the new system requirements have never been clarified; and the proposal did not receive enough support. Since the CIO and GIS manager for the initial proposal have both left the agency, there is no plan or budget allocated for it at the moment. Would the project eventually happens, it would be a total different integration approach, most likely to be an ERP approach with GIS capability as the business case had suggested.