引言

这2年，时不时看到“GIS融入IT主流”的说法，其中至少可以反射出一个信息，GIS行业部分是与IT主流脱节的。这个脱节，有一环就是软件或者系统的架构问题。这里指的系统，是指应用于一个部门或者一个行业的所谓“企业软件”，或者我们平时说的管理系统，MIS；对于这类系统，从整体上说，已经有一整套的规范、设计、技术和行业惯例可以遵从，例如3层或多层的体系结构，基于服务的架构。

但很遗憾的看到，GIS系统很少可以做到这样清晰的架构，即使这样做了，很多方面也很勉强。这样的一个直接后果就是GIS系统往往是一个大的系统里最为独立的一块，仅仅是一个展示系统和面子工程，无法真正融入客户业务。

从2个例子的对比谈起

举2个最简单的例子，一个为一个简单的数据表，该表存储了企业所有的职工档案；另一个为一份地图，表示企业所有客户的地理分布。

一个简单应用

首先，我们看该项数据的存储、操作和显示。

对于职工档案，我们可以存储于一个文本文件，也可以存储于关系数据库，或者是XML文件，这里只谈数据库。而客户分布，最简单的位置信息，经纬度，可以存储于数据库；或者GIS平台的某个格式的点数据集。但如果有空间分布的概念，比如客户是一个范围，那么该数据大概只有绑定于某个GIS平台的某个格式了。这就是问题的起因，但不是结束，也不是死结。

对于操作，职工档案可以通过各种不同的技术（ADO，O/R Mapping，...），转换为可以实际使用的数据集（Dataset），或者是对象。然后一切操作都可以顺利进行了，获取了职工档案，可以发工资、安排任务、分配资源，… 。 但对于客户分布，我们已绑定到一个特定的平台和数据格式，只有使用其工具读取相应的数据，然后进行分析。如果要查询某个客户周边的其他客户，那么平台必须有该项空间分析的功能或者模块，其他平台的不算，否则只有自己开发。于是，需求和实现开始出现裂隙。

最后是显示，职工档案数据可以通过表格、列表等不同方式展示，也可以通过Web或者Form方式展示。只要有一个比较好的设计，这些应该很好做到和满足。但对于客户分布这样的空间数据，显示必须使用其GIS平台的相应技术，对于胖客户端方式，现在的主流平台都有组件，可以满足显示需要，对于Web方式，对不起，是另外的技术和平台，动辄数十万、几十万。

我想，如果HTML也要收费，那么，今天的世界绝对是另外一个世界。退一步，如果没有Perl、ASP、PHP以及这些技术的后续技术，那么现在的Web是什么样子？如果系统需求继续复杂，如果真正要系统融入业务，大概又会是另一番景象。