引言
这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是什么样子？如果系统需求继续复杂，如果真正要系统融入业务，大概又会是另一番景象。
问题之所在
分析一下问题，其实关键在于GIS平台的封闭性，垂直性。
所谓封闭，是指系统的数据格式、分析模块、显示系统只可以针对自己，不能互操作。
所谓垂直，是指GIS系统是一个一揽子方案，而不是其他的IS解决方案，数据库，业务模块及其运行环境，中间件，显示层，是由不同的软件提供商提供的，之间可以互操作，可以整合。
GIS的特殊性
上面其实回避了一个问题，就是我们所说的客户分布，离开了具体的地理空间和参考，是没有任何意义的，因此，我们还需要实际的地理底图。而在实际项目中，这个不属于系统核心的部分往往要付出不菲的财力和物力。这也就是个人为什么极力推崇Google Map API的一个原因，因为他这种模式，也许会有一天解决我们这个问题。
一些技术的对比和思考
SQL和ODBC
SQL作为关系数据库的标准，对于IT业，意义深远。那么，GIS行业会出现自己的类似的规范吗？我们不要那些不优雅不完全的SQL的扩展，而是一套可以完全描述空间数据的语言和规范。我们的学术界，是不是眼光远一点，也结合实际一点。
如果没有ODBC或者同时代的类似技术，今天的Access应用大概是用Access开发，Foxpro应用也用其开发，或者，我们要使用难用的、不可移植的不同平台的C风格的API。不幸的是，GIS行业在某种意义上正处于这样的阶段和环境。
因此，我越来越希望OGC的标准成为所有软件遵从的标准。也更希望有类似微软的软件厂商能制定和实现这样的一套有关数据的规范，缓慢和迟钝的委员会很难成为变革者。对于开发者或者真正的应用者，更迫切的是事实的标准。大概无法期待目前的一线GIS软件提供商做这样的事情。
和数据无关的空间分析模块
和数据无关是指空间分析和具体的数据格式无关。现在的空间分析模块都是平台绑定的，说实话，笔者学会了ESRI的MO下的各类空间检索的实现，换了MapX，还要学习和对比，换了SuperMap Object，还是要学。
有了数据的标准，分析模块可以互换和互操作；在没有事实的标准的情况下，是不是可以使用XML格式的GML，我相信，效率也不会太坏，市场也不会太坏。
空间数据的显示
表现层对于一般的IS，技术上可以很容易的切换为Web或者胖客户端，或者提供Web服务，供其他程序使用。GIS系统，这个层面的问题衍化出一个WebGIS，从最初仅提供地图的Web方式的发布，到现在的Web控件方式的开发，进步很多，但问题还是门槛很高，开发很复杂，问题很多。Google Map API告诉我们WebGIS的开发可以多简单，因此还是希望，平台开发商向这个方向看齐。
展望之白日梦
个人希望的GIS平台是分层和独立的，有数据存储的提供商，有分析模块的提供商，有显示层的提供商，其基础和核心是类似SQL的空间数据的标准。
从某种意义上讲，ESRI的SDE是与此方向最近的系统，如果ESRI可以开源或者免费SDE，使其向这个方向发展，那么可以有厂商开发此平台之上的分析模块，有厂商开发有关的显示层模块，等等，那么GIS行业或许会成为一个欣欣向荣的良性的生态系统，而不是现在这样。但从现实意义，这个“如果”没有任何可能性。
从长远来说，有关数据标准化和统一的研究应该意义非凡。这里的统一是指界面视图层次，非实现层次，类似关系数据库的样子。
一些经验和建议
本来是有2个例子的示例及其实现对比，然后打算做一些小的议论，但最终还是成了一篇没有太多意义的“空谈”。惭愧。
个人觉得，在GIS系统开发中，对于提高开发质量，保持一个可以接受的架构，有一些乱七八糟经验和建议，大概包括：
有关开发和设计
第一，Strategy模式是一个非常好的模式和思路，对于很多情况，应该尽量使用，例如涉及到分析计算有关的模块，通过Strategy来实现，可以保持一个一致的分析的接口，通过简单封装平台提供的分析功能，或者使用自己的算法实现自己的分析，可以实现类似功能；
第二，一个功能或者动作，可以封装为一个类，尽量都进行简单的封装，前面贴过一些例子，这里就略过。
这2条的核心在于，一定要注意OOA和OOP，以及设计模式的应用。个人从中获益良多。
管理相关
第三，数据的规范性，对于GIS项目的成败，这个应该是一个核心问题，一定要重视。对于自己，这个已经是不仅一个项目的切身体验了。
第四，一定要防止2种倾向，一种是只关心架构和设计，脱离实际细节，实际上任何脱离实际细节（包括平台、数据、需求）的设计和架构都是不现实的或者无法实现的；一种是只关心细节和实现，没有重视设计。而实际项目中，前期往往会流于前者，后期则倾向后者，自己也一样，因此需要注意克服。
第五，开发语言与平台。说白了，就是一个GIS平台，开发选择Java，.net平台及其还是Win32下的VB6或者其他语言，有一个准则，就是如果GIS平台提供商可以保证新的平台或语言下稳定和可靠，那么VB.net与VB6比较，就会有很多优势，会在设计中和开发中体现出来。但事实上是，一定要克制使用新平台的欲望，客户不会关心实现的语言和平台，而且一些技巧和方法的使用下，类似VB6也会有比较好的设计。
第六，好的规划、管理可以弥补很多其他方面的不足。
第七，实际可用的一个集成方式：把GIS数据仅仅作为图形数据使用，其属性信息可以保存在关系数据库，通过连接或者ID关联，这样，非图形的系统部分可以方便的使用GIS系统的属性数据。（也许很值得商榷！）
