1.引言

    “信息孤岛”是一个名声狼藉的词汇，虽曾有学者论证过其并非一无是处，且它的出现是一个单位或企业信息化过程中的必然过程【2】【3】，但它毕竟是所有信息化建设者在建设过程中竭力避免出现的，气象部门的信息化建设也是如此。以气象观探测数据加工处理并最终生成气象服务信息产品为特征的气象业务系统，与其它信息系统一样，天然地排斥信息封闭。纵观气象部门的业务布局和流程，相关业务系统之间的信息互通是基本形态，信息孤岛难觅其踪。取而代之的，是散布在气象海洋中星罗棋布的由各个气象业务系统为主体所构成的 “气象信息岛网”.

    与信息孤岛所不同的是，信息岛网中的各个业务系统，除独自拥有包括信息资源在内的所有IT基础资源外，还完成了对彼此相关的业务系统在一定程度的信息互联互通，这种信息互通犹如在各相邻海岛之间架设了通信的桥梁，使这些由孤岛组成的信息群岛因彼此实现信息互通而连接起来，形成信息岛网。

    “气象信息岛网”是事实存在的，而且在逐年扩大。随着气象事业的发展，新的业务领域在不断开拓，新的业务功能在不断增加，新的业务系统在不断的建成，与之相对应的，由传统建设和运行模式（即所谓：功能产生于特定的系统，系统运行于特定的设备）所必然导致的结果：专用于支持新业务系统的新的数据资源和IT基础资源，在不断的购进、装配和运行，“岛网”中新的“岛屿”在陆续出现。

    笔者试图通过本文，对气象信息岛网产生的原因，以及其所造成的负面影响进行分析，并进而提出适时整合气象业务系统的必要性和实施步骤。

    2.气象部门的“信息岛网”

    2.1“信息岛网”的特征

    由“引言”可知，信息岛网的特征：一是存在众多信息系统，这些系统彼此独立，内部构成相对完整，并拥有各自独占的信息资源和IT基础资源；二是相关系统之间实现了必要的信息互通。

    信息岛网是普遍存在的。以一个企业或单位而言，由于内部各业务或职能部门的工作领域彼此不同，支持这些部门日常运行的信息系统势必存在功能、作用范围以及信息资源内容上的差异，如：人事部门、财务部门以及业务生产部门，其相应的信息系统（如：人事管理系统、财会系统、生产信息调度系统等）彼此间存在着天然地差异。而如果这些系统彼此间缺乏信息通道，则这些业务系统便成为信息孤岛。众所周知，信息孤岛的长期存在，势必对企业（或单位）内部信息的正常流转形成障碍，影响整体业务和工作效率的进一步提高。因此由信息孤岛演变成信息岛网，实现各业务系统间信息的互通，是该企业（或单位）信息化建设进步的表现。

    2.2 气象部门蔚为壮观的“信息岛网”

    用“蔚为壮观”来形容气象部门的“信息岛网”并非夸张。在2012年上半年笔者参与的业务系统情况调研统计工作的结果看，仅中国气象局直属各业务单位内部，称得上独立的业务系统有近50套之多。这些作为典型信息系统的气象业务系统，无一例外地拥有各自独立的专用于支持本业务系统运行的专用数据库以及所有必需的IT基础资源，且这些系统均分别与相关的别的系统实现了基于业务流程的信息互通，因此由这些信息系统构成的国家级业务系统，从整体上看，是一张名副其实的巨大的“气象信息岛网”.这张信息岛网是如此的复杂，以至于无法用A4纸以二维平面图形式清晰绘制出该岛网的全貌；其大致信息流程结构见图1.

    图1 国家级业务单位间信息流程示意图

    2.3 “气象信息岛网”的固有特点

    （1）信息管理系统同构、同质现象十分突出

    统计结果显示，国家级的这近50套信息系统所各自拥有的专用数据库中，就所采用的技术架构而言，80%以上采用Oracle商用数据库系统架构，显示出惊人的同构特征。就所存储的信息内容而言，重复存储现象十分普遍，一些数据在不同单位之间乃至同一单位的内部被多重复制甚至被多级复制；如：有19个系统各自独立存储管理气象服务产品资料，地面观测资料则至少由13个系统各自独立存储管理，等等（参见图2），同质现象十分突出。

    图2 各类气象资料在国家级业务单位中重复存储分数统计

    在各省局内部的信息岛网中，同构现象彼此程度不尽相同，但同质现象与国家级岛网类似，十分普遍。

[page]    （2）信息来源较为单一

    就国家级各业务系统所需要的信息来源而言，除气象卫星资料由国家气象卫星中心统一提供外，其它所有气象观探测以及加工产品资料全部由国家气象信息中心统一汇集并提供给各业务系统，流程上呈树状结构。而各省级业务系统的资料来源，也基本上由该省局气象信息中心所负责管理的通信系统、信息管理系统等在完成省内及邻省观探测资料汇集后，向各省级业务系统提供数据服务的。信息来源较为单一。

    （3）“三自系统”十分普遍

    所谓“三自系统”,就是业务单位根据自己业务运行和发展需求，自己提出新的信息系统项目建设内容，并且该系统是由业务单位自行设计、自行建设，系统建成后自己维护的。

    在近50个国家级业务系统中，除有限的几个系统外，有40多个业务系统属于“三自系统”.虽然这些业务系统无一例外地属于信息系统，但同级的专业信息部门却基本无缘参与设计和建设过程，仅在建成之际被要求为这些新建系统提供信息通道以及信息资源等服务。

    3 气象 “信息岛网”存在的问题以及产生的原因

    3.1 存在的问题

    从“信息群岛”到“信息岛网”无疑是一种进步，然而在进步的光环背后，至少存在着以下问题：

    （1）系统数量众多导致信息流程复杂，信息同步更新困难

    一套数据的多重复制，甚至于多级复制，是存在一定风险的；当原始数据发生变化而需要更新时，其所有复制品能否同步更新，在IT界是一个具有挑战性的话题。虽然当代IT技术已基本解决数据同步更新问题，但同步时效和效果的不同，所采用的技术复杂度以及因之付出的代价也随之大不相同。

    问题在于，除个别系统之外，信息岛网中的各业务系统，均未认真考虑原始数据的同步更新问题，而是以气象通信系统常规的观探测资料收集频率和规律来制定原始数据的获取频率；即：定时从上游获取自上一次获取后新增加的观探测资料。国家级系统如此，省级系统也大抵如此。而对于已获取的资料，如果上游发生更新，则这些下游系统因设计功能不包含此功能而无法实现数据的同步更新（甚至于无法更新）。

    （2）系统同构和同质导致投资浪费

    气象资料种类相对有限，两套业务系统虽然业务领域彼此差异，但所用原始资料却基本类似，这在气象业务领域中屡见不鲜。作为岛网中的岛屿，几乎每个业务系统都配有专属于本系统，服务于本系统的专用数据库。这些专用数据库无论在架构上，还是在所存资料的种类上，相似者甚众。常有两个分属于不同业务部门或领域的业务系统，其各自的专用数据库基本相似的情况出现。将其中一个专用数据库稍作改造，便可实现由该数据库同时支持两个甚至两个以上业务系统的可能。然而现实的情况却是，由于业务系统的领域及隶属关系等问题，不得不分别由各自的专用数据库来实现本业务系统的数据支持。

    这在投资方面无疑是一种浪费。

    （3）“三自系统”造成运行负担沉重

    自行设计、建设和维护的业务系统，由于立足点的局限，往往难以顾及全局的整体协调性、可扩展性和可变更性。因此以“三自系统”为主形成的业务格局，一般其信息流程和数据流程的效率皆不高，且难以在不予改造的前提下进行优化调整。

    业务系统的自行维护，给系统所属单位带来人力资源方面的负担。依照有关规定，在汛期预警期间，业务系统必须按时报告运行状态，预警级别越高，报告频率越高。因此派专人看守并维护业务系统，在高级别预警期间是普遍的现象；系统越多，派去看守的人员便越多。因人手紧张而导致有关人员不得不连续加班的情况时常发生，导致系统所属单位宝贵的人力资源被阶段性占用，在此时段内难以在人力资源方面形成合力，解决突发问题或关键问题。而随着“三自系统”的逐年增多，汛期因系统维护而被占用的人力资源也逐年增多。

    所以，“三自系统”导致整体业务流程和信息流程效率的低下，以及系统所属单位人力资源的长期紧张。运行负担沉重。

    3.2 产生问题的原因

    （1）项目建设的有限目标性是内在动力

    本世纪最初的十二年是气象业务大发展的年代，新的业务功能、方法伴随着新业务系统的建立而被充实到业务一线，大幅提高了各级单位的业务能力和水平。气象部门的系统建设多依托于国家下达给气象部门的重大专题项目，如：“灾害性天气监测预警项目”、“气候变化应对工程”.由于这些重大建设项目目标和内容明确，针对性鲜明，因此多由与之相对应的具体业务单位承担具体实施的职责；而这些业务单位则往往根据业务发展的实际需要以及单位内部业务分工布局，将项目分解成若干分项目以及子项目，由下属的专业业务部门承担分项目、子项目的建设工作，单位则负责分项目的集成--这是“工作分解结构”（WBS,Work Breakdown Structure）的常用做法。

    任务有限、经费有限、时间有限，在没有整体IT架构规划的情况下，承担建设工作的业务部门无规可循，只能以最终完成任务为首要目标。做为以加工处理观探测资料及数值模式产品最终生成业务产品为基本特征的业务系统，原始数据的保障和支持是确保其正常运行的最起码条件；在环顾四周，没有一个现成数据管理系统可提供本业务系统所特有的数据内容及服务方式支持，提出的数据服务需求又得不到及时有效响应的情况下，自己建立一个专属于本系统的数据库，以专门支持本系统业务运行，便成为项目承担者的自然选择。

[page]    （2）公用数据存储管理系统长期“原地踏步”是外部土壤

    事实上，自上世纪九十年代中期起，国家气象中心便已建成面向业务服务的数据库系统。国家气象信息中心（NMIC）成立后，也先后建立了国家级气象资料存储检索系统（MDSS系统）和科学数据共享系统（CDC系统）等专用于存储管理所有气象资料，并对外提供数据服务的数据库系统。以MDSS系统为例，承建单位在设计之初对各业务单位进行了较为全面的需求调研，并有针对性地设计了相关的服务功能，然而在投入使用后效果却并不理想；一方面各业务单位业务和科研工作蓬勃发展，一些单位和业务逐渐消失，而新的单位新的业务陆续出现，导致新的数据和服务需求不断提出；需求始终处在变化之中。另一方面，MDSS系统原本先天就存在结构和功能上的缺陷，靠自身原有功能无法满足时刻处于变化中的业务需求。更为可悲的是，该系统长期得不到升级改造机会，原有缺陷无法弥补，新的服务功能无法增加，最多在原有系统上做些缝补性的微小改良，系统整体能力始终在原地踏步。虽然该系统的责任单位一直着力推进向各业务系统提供直接数据服务，然而往往由于用户的几个关键功能需求无法即刻满足，导致用户宁可自行建立专用数据库（虽然专用数据库在数据内容上仅为MDSS的子集，功能上与MDSS也相差不大）。随着时间推移，专用数据库随着新业务系统而纷纷出现，MDSS则始终保持原态，默默地为各专用数据库提供其所需的各种数据。

    笔者在《再论业务系统的持续改进》一文中曾论述，气象业务系统可以永远被改进【4】，长期处于原地踏步的系统，只能是逐步萎缩，越来越无法适应需求变化，并终将被淘汰的系统。以这样的系统向业务单位、业务系统提供数据支持，其无力、无能和无奈的窘态便越来越成为新建业务系统自建数据库以求自保的肥沃土壤。

    （3）总体规划的长期空白是自然环境

    自2012年12月以前，气象部门在整体IT架构规划方面事实上是处于空白状态的，而整体规划的缺失必然导致系统建设状态的无序。

    气象业务系统是典型的信息系统，气象业务流程在业务架构确定后是基本明确的，信息流程是业务流程的具体实现。但这并不意味着信息流程也随着业务流程的确定而固定和一成不变。事实上，信息流程的优劣直接影响到业务流程效率的高低，而信息流程的优化是整体IT架构规划的重要组成部分之一。该规划的缺失，使得各自独立建设的业务系统在原始信息获取和产品发送方面无章可循。于是从原始数据最可靠的源头处获取原始数据，向产品使用者直接发送产品，便当然成为系统最方便的设计选择--信息流程的无序和复杂由此产生。

    在没有明确业务系统职责分工的情况下，面对虽已存在，但却无法满足自身数据服务需求的公用数据库系统（如：MDSS），因业务职责所限，项目建设者没有向这些公用数据库的维护单位提出改进公用数据库的义务和责任，更没有权力将本项目用于自建数据库的经费拿出来做为公用数据库的改造经费。于是，一方面公用数据库虽无法满足新增业务需求，但却没有改进和改造的机会和经费；另一方面新建业务系统必须专款专用，自建数据库的经费只能用于自建专用数据库，不能转而提供给公用数据库以用于其改进和升级改造。

    4.信息岛网的整合及流程的优化

    4.1 整合的必要性

    “信息岛网”并非一无是处，由于其建设过程中所考虑和涉及面相对有限，因此系统设计和建设的复杂度相对较低，能够在有限的时间内快速实现业务功能。同时，由于与相关业务系统实现了基于业务流程的信息互通，规避了信息孤岛及相关负面作用的产生，因此其在业务能力方面的贡献是正面的。

    然而也正因为它在设计过程中的视野和关注面较窄，不考虑整体信息流程的合理性和简洁性，因此它的出现势必给原已较为复杂的业务流程和信息流程增加了新的复杂度，而它的不断出现和持续存在导致单位整体的业务环境和流程的复杂度持续增加，整体的效率、可靠性等逐渐下降，进而导致单位整体的业务运行负担和成本的逐渐增加，运行和发展的羁绊逐渐增多。

    从上面的分析可知，在现有工作模式不做彻底变革--即：IT整体规划未予制订并落实、业务系统持续改进未予制度化、项目建设和管理仍延续目前运作模式--的前提下，“信息岛网”无法在气象部门完全杜绝。而我们同样明白：“信息岛网”决不可永存，因为它所造成的系统复杂度的成倍增长以及因之而带来的人力、物力运行成本的不断攀升，不断加重着气象业务的运行负担，迟滞了气象业务的发展。从单位整体业务健康运行和发展等战略层面考虑，必须适时对“信息岛网”进行整合，使业务系统整体简洁化，信息流程最优化；化解负担，轻装前行。

    变革现有工作模式是长期而困难的，而气象业务的发展始终热火朝天，因此“信息岛网”的出现是经常性的。而之所以强调对信息岛网整合的“适时性”,是因为系统整合工作的牵扯面之广、需考虑的问题之多之深、所采用的技术之复杂，远远超出单一系统建设自身。因此整合工作只可能是阶段性的，且目标相对有限。信息岛网的经常性出现和阶段性整合，二者相生相伴。

    需要注意的是，整合的“适时性”并非延宕、拖延以致使整合工作遥遥无期的借口。事实上，目前气象信息系统（特别是由各类数据库组成的庞大数据库群）在整体上表现出来的效率和效能的低下，就是因为阶段性整合的长期缺失，造成系统整体复杂度成倍增加所导致的结果。

    4.2 整合的路线图

    整合已达成共识，但整合的方案却多种多样，简而述之，主要有以下两种：基于企业服务总线（ESB）的信息系统服务能力整合方案（简称“ESB方案”），以及基于数据库（数据管理系统）本体整合的数据资源和服务能力的整合方案（下简称“数据库整合方案”）。下面予以概要分析：

    （1）“ESB整合方案”

    该方案的核心，是在承认现有各业务系统所各自拥有的数据库现实存在，并不做归并整合的前提下，采用企业服务总线的理念和方法，将各数据库的服务功能标准化、服务化，并封装起来，由统一的服务接口对外提供统一的数据服务（限于篇幅，详细内容不予展开）。

    采用SOA以及基于其上的ESB等理念和方法，整合企业（单位）内部的服务功能，是近年来IT界公认的较为有效的途径。然而一般地说，企业服务总线（ESB）适用于数据基础各异，业务功能彼此独立，不能也无必要进行整合的业务系统（如：人力资源系统、财务系统以及生产系统等），针对这些系统进行功能和服务整合的。即：将不同系统所提供的不同的服务规范化并整合起来，组成内容更为丰富的服务群，对外统一提供更为丰富的、同时符合标准的服务。然而这同时意味着：如果被整合的对象在服务内容和方式等方面基本类似或差异不大，则采用ESB方式的整合便失去了意义。--而彼此同构和同质，恰恰是气象信息岛网内诸岛各专用数据库的特点之一；同构数据库所能提供的服务方式基本类似，而同质又使得各数据库所能提供服务的数据在内容上大致相同。

    因此，在一个存储管理气象观测资料和服务产品的全集的数据环境（MDSS系统和即将上线的CIMISS系统）已经存在的背景下，对于那些以彼此内容基本重复的专用数据库为支撑的气象业务系统，采用企业服务总线方式实现彼此数据服务能力的整合，似有舍简求繁之疑。

    此外，该方案的基本点之一是承认并维持现有各业务系统专用数据库的存在，整合后各专用数据库在数量和从属关系上并未发生变化，原本因其存在而产生的各种负面作用（如：所属单位运行负担过重，维护工作占用过多人力资源等）并未根除甚至消减--问题依然存在。

[page]    （2）“数据库整合方案”分析

    气象信息岛网产生并形成规模的主要原因，是这些业务系统在建设之时，没有一个可充分满足其数据服务需求的数据库系统作为其信息来源和生成产品管理服务的基础支撑平台。换言之，如果存在这样一个数据库平台，其所管理的资料完备、可提供服务的功能丰富、且性能良好，可同时充分满足各业务系统对数据服务的各种需求；或虽有部分需求一时无法满足，但该数据库可通过及时的升级改造补充相关功能，以迅速满足需求；则岛网中的各业务系统所配置的专用数据库便失去了存在的必要--对于气象信息岛网更是如此；因为岛网中各业务系统所配专用数据库具有较高的同构性和同质性，理论上应当可以通过整合实现由有限的数个（甚至一个）数据完备、功能齐全、性能良好的数据库系统承担对所有业务系统的数据支持；并且这种整合在技术上不存在不可克服的技术障碍。

    数据库的整合，实际上是数据资源、计算资源、存储资源和服务功能的整合；通过集中管理调度，提高这些资源的使用效率和效能，从而提高系统建设的整体效益，同时由于整合后的数据库数量有限，可集中技术力量对其进行高水平的专业化维护，因而可较为有效和成本相对较低地实现数据的安全管理。这是目前业界较为推崇的有效做法。

    所以，在国家级和省局分别搭建国家级和省级数据环境，通过一段时间的努力，逐步将各业务系统专用数据库整合到当地的数据环境中来，最终实现由当地数据环境（国家级或省级）向所有当地业务系统提供充分满足其需求的数据服务（见图3）；并通过制订相关法规，实现数据环境的持续改进，以在未来运行过程中能及时满足各种新增的业务需求。这是“数据库整合方案”的核心内容，也是目前有关人员所接收并确认的整合方案。

    该方案已写入《全国气象信息网络系统总体设计（2012年版）》，并将在未来数年内予以贯彻实施。

    图3 国家级数据库整合前后信息流程示意图

    4.3 业务系统的归并和数据流程的优化调整

    通过归并整合业务系统专用数据库，实现将“气象信息岛网”逐步整合成“气象信息大陆”,实现数据、计算、存储等资源和数据服务能力的整合和集约化管理，这是业务系统整合过程中最初也是最为关键的第一步。在此基础上，搭建由计算资源池、存储资源池为主的具有一定弹性计算能力且规模易于扩展的公用IT资源平台，将各业务系统逐步移植到该平台上来，并由IT部门专业团队对其进行高水平专业化维护，大幅提升业务系统运行平台的资源使用效率，降低运行成本，并使各业务单位摆脱业务系统日常运行维护的沉重负担，集中精力，专心致力于本专业的相关工作；这是系统整合的第二步，也是渐显整合效益的一步。

    第三步，在数据大集中的基础上，调整业务流程中一些不尽合理的旁路和分支，将那些尚处旁路状态的已定型并基本实现自动化运行的业务系统整合到数据环境中来，使之成为数据环境诸多业务功能之一。以此提高这些业务系统的运行效率，减少不必要的中间环节，优化业务流程；这是整合工作大见成效的阶段。以ATOVC资料生成业务为例，此业务原始资料由位于国家气象信息中心的国际通信系统获取，并原由位于国家卫星气象中心的业务系统加工处理而成；后卫星中心将此业务并入信息中心数据加工处理业务流程中，从而减少了中间环节，资料服务时效提高10分钟以上（见图4-1、4-2）。

    图4-1 调整前ATOVC业务流程示意图

    图4-2 调整后ATOVC业务流程示意图

    综上所述，在国家级和省局建立数据环境，通过归并整合各业务系统专用数据库，实现数据资源和计算、存储资源的整合，优化信息流程。在此基础上搭建公共IT资源平台，将当地各业务系统逐步整合到该平台上，结束业务系统分散运行、独自维护的困境，实现人力资源的专业化分工合作，以及IT资源的集约化管理和高效利用，优化资源使用效率。同时，调整业务流程，归并成熟的业务系统，减少无效的流程环节，使业务流程更为顺畅和健康。

[page]    5.系统整合的云计算意义

    5.1 面临的问题

    从信息网络分散建设向资源整合利用转变，从信息系统独立运行向互联互通和资源共享转变，这是当前气象信息化建设所必须重视的二个问题。而推进基础设施的资源整合与共建共用，运用IT新技术整合形成能够构建适应不同领域和部门的统一平台，为公众和其他用户实现面向应用的协同共享，以及以业务内外分解为原则推进服务适度集中和公益化，则是当前气象信息化过程中必须尽快解决的导向性问题。这些问题依靠传统手段和方法是难以甚至无法应对的，云计算是目前解决这些问题有效途径。

    云计算自出现之日起，便以其高性价比、应用的分布性、高可靠性、可扩展性、高度灵活性等特点而迅速发展并得到广泛关注【6】【7】。就目前气象信息岛网的治理而言，云计算是信息资源整合的根本保障。

    因此，在整合资源、提高效能、化解负担、优化流程为共识的前提下，针对气象信息岛网的治理工作，采用云计算的理念和方法，无疑是正确的选择。

    5.2 云计算在当前气象部门的应用前景

    相对于“功能与系统”及“系统与设备”紧密耦合的传统气象业务系统基本构造而言，云计算的特点之一是“业务服务”与“基础架构平台”之间的高度解耦；即所谓功能与系统相分离，系统与基础架构平台相分离。在云计算环境下，气象业务用户可单纯使用业务系统所提供的各项功能，不必为此事先购置服务器、存储设备、系统软件和应用软件平台，并为之担负沉重的日常运行维护负担。

    因此，即使在目前事实上不以“提高效率，降低成本”为首要工作目标的环境下，云计算在气象部门依然有着广阔的应用前景，并为我们提供依照传统方法已无法达到理想目标的新的行之有效的实现方法，其中之一便是通用业务系统的服务化；即：将那些已经或未来即将在全国基层业务单位部署推广的业务系统（如：MICAPS、SWAN等）部署在有限的几个“云端”（省局或国家级信息中心），将这些业务系统服务化，使各级预报员能够通过无线网络和移动智能终端直接使用这些系统所提供的各项功能，以更加灵活和便捷的方式向当地政府和社会提供气象服务；不必为运行这些系统而在预报员身边配置服务器、存储设备以及加载大量的系统运行所必需的各种数据，所有这些资源和系统全部部署、运行并维护在有限的几个“云端”.这是一幅令人神往的美丽愿景，值得所有气象IT人员为之努力奋斗。

    云计算在气象部门的引入和落地，必将对气象业务工作方式、气象信息化建设模式以及资源效益充分发挥等方面产生深远影响，使气象事业以更加健康的良好状态持续发展。而建造这个美丽花园的基础之一，是系统和资源的高度整合和集约化管理。所以，对气象信息岛网的治理，对业务系统专用数据库的整合，是迈向气象云计算的第一步。

    6.结语

    气象信息岛网的出现和逐步发展，使得气象业务逐渐处于亚健康状态。其所造成的负面作用虽如冰山一角，尚未被所有有关人士察觉并重视，但其潜藏在水面以下的巨大冰块正在快速增长，并已开始堵塞气象航船驶向光明彼岸的航道。通过整合数据资源，以及IT基础资源，并进而整合业务系统的方式，用智慧和辛劳溶解冰山，疏通航道，这是气象部门IT业人士和团队当前和今后相当长一段时间内的责任和使命。

    参考文献：

    【1】中国气象局预报与网络司：气象信息网络系统总体设计（2012年版），

    【2】曹国法：企业信息化产生信息孤岛的根源及解决方法分析，

    【3】和佳：直面信息化孤岛


    【4】沈文海：再论业务系统的持续改进，《气象软科学》，2009年第2期。

    【5】沈文海：关于CMA当前IT系统建设面临三大问题的初步思考，《气象软科学》，2008年第3期。

    【6】雷万云等：云计算--技术、平台及应用案例，清华大学出版社，2011年5月，第一版。

    【7】沈文海：从云计算看气象部门未来的信息化走向，《气象科技进展》，2012年第2期。

    【8】沈大风等：电子政务发展前沿（2012），中国经济出版社，2012年5月，第一版。

    【9】赵捷：企业信息化总体架构，清华大学出版社，2011年1月，第一版。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。