我们应该做个大系统！
我刚刚到学校网络服务中心工作的时候，对于学校信息化应该做点什么，以及应该如何做，并没有太多的概念。记得有一次去参加高校信息化学会的会议，听来自某知名学府的老师介绍 URP，瞬间觉得那真是一个很高大上又及其复杂的的东西。想想我们这些信息部门只有几个人的小学校，真是没法做这样的事情啊。
后来在学校里面跟同事们聊到信息化的时候，就经常有同事说，你们就应该做一个大系统，你们网络中心做，我们各个单位用。对于此，有些我是非常认同的，譬如学校的信息化的确应该一盘棋，不能乱来。但一个包罗万象的大系统，总要花很多时间很多钱吧，也许光需求调研就得几个月，研发起来就得几年，然后再投入使用……不敢想象。
在当时，做一个大系统的说法在高校的信息化界，时常被提起，也有厂商的宣传在朝着这个方向努力。于是也就真的有厂商找上门，来推销一体化学生管理系统之类的东西，把教务、学工、宿管等各个部门的需求，做在一个庞大的软件里面。他们说这样的系统最大的好处，就是天生没有数据孤岛。说真的，面对这样的说辞，还真说不定有人会很心动，做个大系统一下子把信息化推上一个台阶，那真的是大功一件，再加上没有数据孤岛，岂不是非常先进？
一个大系统真的现实吗？
作为一个每周都要写几行代码的程序猿，对于这种大系统之类的说辞，还是有一点天生的警惕的：
首先，软件开发是一个非常复杂的工作，软件项目从出现的第一天开始，其失败率就远高于其它行业。譬如，我们很少听说盖房子刚盖好就塌了，但软件到期做不出来以及上线第一天就崩溃可不是什么新鲜事儿。并且，一个软件系统的复杂性，会随着功能的增加而成指数级增加，量变导致质变，用来形容一个系统功能不断增加和该系统的稳定性不断下降之间的关系，再合适不过了。
其次，大系统的工期无法控制。单一软件项目的工期，通常应该控制在六个月以内，如果工期过长，无论是承包商还是相关部门的业务人员可能会因为长时间没有效果而陷入一种疲劳状态，同时软件自身的需求也可能因为业务的变化而不断发生变化，直接导致软件的工期更长，进而陷入一种恶性循环。
再次，按照当今高校信息化行业对软件价格的普遍认识，很多人都认为一个软件系统四五十万就已经很贵了。但四五十万如果扣掉税，扣除销售的成本，在当今也就是一两个普通程序员一年的工资吧，而他们挣的钱不吃不喝合起来在北京这样的一线城市也就能买个厕所。请问这样的投入，能找得到做的出大系统的人吗？
最后，即便是在 2010 年，人事、财务、教务、图书馆、卡务、网络中心等各种部门就已经建立了自己的管理信息系统，做一个大系统是要把它们各个部门的系统都干掉然后合在一起吗？这些完全属于不同管理领域的事情，真的能有一个公司都搞明白么？
如果一个事情在理论上就不现实，那么也就没有什么实践的必要性了。
数字校园的架构
在软件工程领域，人们一直寻找着控制软件复杂性的方法，而其中最经典的一句话，就是 UNIX 所奉行的设计哲学：* K.I.S.S. = Keep It Simple, Stupid! *
Unix 系统，就是一个典型的简单系统，系统中的每一个命令行工具，都只完成一个单一的任务，譬如 ls 就只能列目录、wc 就是用来统计单词个数，若想知道一个目录中有多少个文件，就需要用 ls | wc 这样的组合了。
数字校园，作为一个涉及不同领域，既要支撑教学、管理，又要服务学习、生活的庞大 IT 设施，其必然由各种大大小小的组件构成，但这些组件之间又必须建立联系，否则就会形成数据孤岛。在经过长时间的调研、实践和思考之后，在我们心中数字校园的整体结构和建设方式开始慢慢清晰，基本上可以用“大平台、中系统、小应用”来描述。
由于今天平台、系统、应用这些词语有着广泛的含义，因此有必要对其进行一下定义。平台，本身并不完成特定的业务工作，它的存在就是为了支撑系统和应用的正常运行，最典型的应该被称之为平台的东西就是基础服务层的如统一身份认证、展示层的如门户这些东西；系统，也就是管理信息系统，管理着某个领域的一组特定数据，并且支撑某个领域的日常工作，譬如人们熟知的教务系统、财务系统；应用，基于平台和系统中的数据，为用户提供某项特定的服务功能，门户平台中的集成的成绩查询、网费充值，都可以称之为一种小应用。
大平台和小应用的概念今天已经被很多人理解并认同，那么“中系统”指的是什么呢？
中等规模的业务数据管理系统
业务系统是数字校园中不可或缺的一部分，通常是数字校园建设过程中最早启动的那一部分，但也经常成为被吐槽最多、失败率最高的部分。如今已经有很多原本做业务系统的公司被高校玩儿死了，这是为什么呢？
预期错误：很多人认为做业务系统就是做软件，必须好看、功能全面、高大上，做个系统就要一切事情摒弃手工操作、不用 Excel。其实，信息化的根本任务在于对数据的管理，管理信息系统，就是帮助业务人员管理数据的工具。建设管理信息系统的根本，是梳理数据、优化管理，软件只要不出错、基本好用，可以保证主干业务正常运行就够了。
边界模糊：以高校中使用最为广泛的教务管理系统为例，在十四五年前大家刚刚开始做教务系统的时候，教务系统本身的功能还是很明确的，主要为了支撑学校最基本的教务运行。但随着教务处业务的不断增加，很多人就觉得诸如大创管理、计算机等级考试报名等各种各样的功能都应该增加到教务系统中来。各个软件厂商为了卖出自己的东西，毫无节操的迎合各校教务处的不合理需求，在自己的产品中加入了越来越多乱七八糟的东西，活生生把学校的“教务系统”做成了“教务处系统”。
需求泛滥：在高校做业务软件，需求调研的过程往往非常奇葩，一种最常见的做法，就是业务部门的领导会把部门内所有的工作人员叫到一起，开动员会，然后让每个岗位上的具体工作人员向厂商提出软件修改需求。这种方式，极易导致需求的泛滥和不可控。请问银行做软件会把所有柜台的服务人员都叫来跟承包商谈需求吗？正确的软件需求采集方式，应当是由部门中管理经验丰富、全面掌握业务的一两个人跟软件开发方的专家共同商讨制定。而一般的工作人员，作为软件的普通使用者，则应当按照既定的管理模式工作。
上述问题，都会使业务系统不断膨胀，一个业务系统塞进去各种有用的没用的东西。正如前文所说，随着功能的增加，软件的复杂性也会不断增加。因此，我们强调业务系统，应该是“中等规模的业务数据管理系统”，一个业务系统应该只负责处理关联极其紧密的重要的、成熟的、频繁发生的业务，其管理模型应当是业内普遍采用的。业务系统应该更多地强调数据准确性和及时性，易变的流程审批性内容，则应当向学校统一建设的 BPM 流程平台迁移。
譬如教务系统，就应该只包含学籍、培养方案、排课、选课、成绩、毕业设计管理等最基本功能和相关的学生、教师服务界面。如果教务处还有什么其它的需求，都可以做成基于学校数字校园平台和教务系统基础数据而运行的独立应用。以这种模式构筑的教务系统，由于其需求稳定、数据清晰，如果再加上合理的软件架构设计和精心地实现，就可以用很久。
应用小型化和微服务
幸运的是，今天已经有越来越多的人认识到了系统中小型化的必要性和必然性，并且在实践中按照这种方式构建系统。在互联网领域，其实也有一种应用中小型化的趋势，也就是今天很多人所说的“微服务”模型。
互联网领域所使用的“微服务”模型，实际上是将过去一套代码、一套数据库的单体软件结构，分解为每个模块一套代码，每个模块一套数据的结构，这样不同的模块可以根据自身的需要选择合适的语言编写，也可以根据实际应用的需要选择横向扩展方式。而模块与模块之间，则通过消息队列或是 API 接口等方式进行连接。
如果我们把数字校园看成一个大的互联网平台，那么今天数字校园的应用小型化趋势和互联网领域的微服务架构其实如出一辙，只不过在模块划分的粒度、实现方式的把握上，有着不太一样的标准罢了。
写在最后
任何一种技术的变革，都会多多少少带来一些问题。应用的小型化，使软件的安装部署和运维工作量迅速增加，而这样的问题该如何解决呢，敬请期待《从虚拟化向容器化迈进》。
数字校园实践系列
- 之一 《从构筑大系统，到编写小应用》
- 之二 《从虚拟化向容器化迈进》
- 之三 《看不见的基础服务层》
