|
|
|
Enterprise Modeling of Business Objects in the realm of Geographical Information System Development
Srikrishna Pothukuchi
Navionics Technologies Pvt Ltd
Road No 3, Banjara Hills, Hyderabad 500034, India
Tel: +91-40-661 8251 (Off) +91-40-714 3599 (Res)
Email : srikrishna@bcs.org.uk
Introduction
Application of geographics to business systems is emerging rapidly as the quest for predicting future businesses over well-known spatial phenomenon intensifies. Matured spatial systems escalate such need in leveraging spatial information in formulating business strategies. May it be a risk evaluation for the insurance aspirants or identification of outlets for the retail chain, the usage of geographics is well established. However in some cases, the GIS is limited to producing reports that enable the decision maker, but might fail often in occupying prominent place in the enterprise information system architecture.
Business systems those exhibit predominantly spatial characteristics are often proprietary and closed, whereas systems that are compatible to open standards have well defined interfaces but very much limited in exhibiting the spatial characteristics throughout the lifecycle. Former systems are built carefully to satisfy the requirements at the time of definition and tend to become legacy systems. We have plenty of examples in this area, where the developer often builds his own component libraries and use, or better still reuse third party mapping components like ActiveX controls or Java Beans while developing the enterprise system. Latter systems have their main information system intact and a popular third party GIS Viewer or Analysis software tool supplements; one example being ERP as a candidate system, with third party GIS Tools supplementing it.
Organizations from the non-professional GIS segment that join bandwagon of spatially enabled services lack commitment to the usage of spatial information. Such failures cannot only be attributed to the lack of awareness on GIS on behalf of executives, but it should also be equally attributed to the systems architect, who had delivered the spatial solution loosely coupled to the core information system. Higher the degree of coupling does not necessarily mean moving towards proprietary systems, as long as interfaces provided comply with the open standards.
Current Scenario
Developments in relational database technologies and distributed component services caused many enterprises to exploit these technologies to develop their information systems accordingly. Contribution of the ISO TC-211 and the Open GIS Consortium are to be acknowledged duly in this regard. Keeping meticulous details aside, the most popular and simple way of spatially enabling a business solution is to attach business attributes to the spatial primitive. If there are more tiers for the system in entirety, at the data tier it is the spatial table that holds these extra attribute columns, and at the business logic tier, a compound object or a GML document that holds the corresponding schema. The presentation layer, usually being a map browser, parses the GML dataset and presents the information. Architect is still having the choice of building better system, as he is having access to the objects in the GML document.
At the database level, spatial objects are stored in relational tables often with huge binary large object types. With the advent of SQL MM specification, abstract data types were introduced for storing spatial data. Irrespective of the storage mechanism, the spatial record can be accessed by its unique identification number. This record represents either a primitive spatial element or a derived element. Again it’s the same record that is going to be presented by the application visually, and along with its graphical depiction a standard identification tool fetches attribute details about this element, thus serving the base functionality. Analytical operations on this element are to be limited only to the attributes predefined. If the user has more information processing requirements than assumed earlier, either he has to change the definitions of his datasets by adding or removing more attribute columns in the database. This situation is really pitiful on behalf of the spatial objects, because the requirements for change are often applicable only to the business objects, i.e. information represented by aspatial columns or simply the attributes.
A workaround solution could be produced, if the GIS Client software provides a macro language of its own. One typical example is writing a macro program that temporarily brings data from aspatial tables linked by the unique ID of spatial tables and creating a theme for further analysis operations on the temporary dataset.
While the later approach is immediately appealing (as it were today), still the information processing needs are not addressed completely. Information processing involves not only the spatial data, rather it involves usage of business data extensively. There are enterprise systems where GIS is merely a part, making the system spatially enabled partially. But the term spatially enabled system implies that the business system is partly complying to bring forth the usage of spatial data, whereas the amount of spatial enabling is not quantified at large. Good example in this case is of a popular ERP package was referred by this term, when the ERP package made by one vendor has plug-in to a popular GIS tool made by another vendor sold as a total solution; data interchange between these two systems were maintained at a sub-system level.
Another option left to the architect is to build an information processing system either by using off-the-shelf map components or by developing his own. Whatever choice he make, the system evolved would remain as proprietary, despite of the flexibility it offers.
|
|
|