说说信息技术工程化问题_风闻

       自2014年国家取消运转10年的信息化建设监理制度以后，面向过程的瀑布模型开发方法正式落幕，取而代之的是面向对象的所谓敏捷模型开始野蛮生长。

       瀑布模型包含“需求分析（含调研）、概要设计、详细设计、编码实现、模块测试、集成测试、试运行、交付验收、运行维护”几个阶段，是一次性过程，项目实施管理过程中发现，当实施范围、开发规模大到一定程度后，这种模型就显得过于理想化，被人类天生的认知规律所局限，时常发生到项目后期试运行或运维阶段才发现之前提出的需求不是内在真实需求，而此时项目已经成型。基于人类认知是螺旋上升的这一客观规律，人们将瀑布模型的各阶段提炼，然后进行全阶段迭代，即重复迭代执行“分析、设计、编码、测试、小版本发布、反馈”全过程，逐步形成符合真实需求的信息系统。在方法提炼时，人们将以流程为核心驱动的功能化设计变更为以对象（功能与数据封装）为基本单位粒度、以接口松耦合方式对系统进行组织，方法上称为“面向对象的敏捷开发方法”。只是此时的定义显得一厢情愿了，因为更基本的对象、对象特性、粒度标准都没有形成共识，实践活动中产生了无数技术分支，大量的新开发语言、新编译环境等新技术诞生，而所谓敏捷管理模式也沦为一种不再包含内容性内涵的行为过程抽象，至此信息技术实施路线全面分化。

       信息技术实施的天破了，自然就谈不上什么有效的管理，只能让子弹飞啊飞。在这个源头紊乱、技术路线繁杂的领域那些强行要求规范管理的、并且与建筑管理领域进行比对和复刻的都挺蠢，愿望挺好，也只能是为增进规范可能性提供素材，至于那些实施相对比较成功的项目，是被流弹打中了，多数则成为了光荣的时代背景。但仔细梳理现实中的技术要素，则会发现几条大的脉络逐渐成熟起来。

       首先是基础服务器和网络领域基于并行访问和硬件资源利用效率的问题驱动，沿着“集群、虚拟化、云计算”轨迹发展。原本这是很朴素的一个问题驱动轨迹：因服务器有并发访问请求问题，于是处理上考虑将请求分发到不同的服务器上，由多台服务来响应这些请求，这多台服务器就构成了集群（自然也有了针对集群的反向代理和负载均衡技术，衍生技术先不表）；又因为并发访问请求有时间段，集群在访问波峰波谷利用效率就成为问题，解决方案就是虚拟机技术，将一台实体服务器虚拟成10台虚拟服务器，在需要的时候通过调度程序快速热部署虚拟服务器，这自然会提高物理机器利用效率；这项技术展现出了潜在市场价值，于是轨迹变了，利益开始驱动，一时间几乎所有的IDC服务商、大公司和风险资本都被吸引，使虚拟机技术得以深化，宣传上则美其名为云计算，其性质不过是计算机网络世界的“廉租房”方案，因虚拟资源可调度、可计量，天然具备可租赁的商业模式。到此为止，云计算技术还算正常，可接下来市场推广就偏离正常轨道了，有意忽略了“廉租房”实际定位，通过概念混淆，把云计算包装成包医百病的技术路径，一夜间企业如果没有云或者没有加入云仿佛就落后百年了，待到这些企业探头进去才发现：CRM（客户关系管理）服务器、ERP（企业资源管理）服务器、PLM（产品生命周期管理）、MES（生产计划执行系统）系统等企业常规应用服务器和数据要怎么办？关键问题是：这些系统并发访问需求真有那么大吗？生产制造企业脱离这股风潮后，一些网络平台则是迎来了真正的春天，平台型企业服务进入到社会公共平台领域。

       其次是软件系统开发（尤其是事务型应用系统开发）领域面向对象的Java开发语言环境成熟，Struts2、Spring、Hibernate覆盖MVC（业务模型、用户界面、控制）开发模式，提供全面的功能包支持，再辅以23种开发模式构型，开发工作仿佛标准得不能再标准了，工程化时机俨然成熟，只是相对于同期那些扎根云计算，依托开源社区，围绕hadoop（分布式文件系统）、map-reduce（映射-规约）这一算法模型逐步生成的一个庞大生态，公共平台以行为分析为目标，催生了大数据、商业智能新业态雏形后，显然，资本更偏向后者，于是一些全新的价值增长点、机制变革点爆发显现，如机器学习、人工智能、深度学习、区块链等。

       第三是围绕软件开发实施过程的管理标准框架，自60年代提出软件工程概念到二十一世纪初，针对软件开发实施内容的管理标准框架是TOGAF（The Open Group Architecture Framework 美国国防部的信息管理技术架构），针对软件开发实施过程的则是大家都很熟悉的项目管理标准。TOGAF在内容上指导思想沿袭了詹姆斯马丁的信息工程论思想，将内容架构依据所面向对象的不同，划分为业务架构、应用架构、数据架构、技术架构四个基本框架；针对过程的信息化项目管理与其它行业项目管理标准基本一致，包含范围管理、进度管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、配置管理、外包管理9大知识领域以及42个可裁剪过程管理模块。在新业态显现、开源社区作用日益加重之前无论国外国内，工作中遵循的指导都是这两个方面的标准，大小公司、企业只在分工全面性、严谨性上有所差异，基本思路都是一致的。但面对开源社区的作用凸显以及新业态业务内容、技术边界这些源头上的不确定性，TOGAF和PM都显得不能适应，国际上一些标准组织和国家（包括我们的工信部）都应急跟进，大量出具一些行业指导白皮书，尝试攀登标准高峰，尤其在工业互联战略核心要地，中国的AII，即工业互联网体系架构2.0、德国的RAMI4.0（Reference Architecture Model Industrie 4.0）工业4.0参考架构模型、美国的IIRA（Industrial Internet Reference Architecture）美国工业互联网参考架构、日本的IVRA（Industrial Value Chain Reference Architecture ）工业价值链参考架构。这些架构共同的地方都是以多维度多层级的视图为内容组织依据，都是以数据架构为核心，侧重则有所不同，德国日本侧重价值链发掘与对接，美国侧重视图层级衔接标准化，我们则是以产业层、企业层、边缘层作为顶层划分，侧重系统性交互连接。但到目前为止，我们并不清楚不同层级的核心需求究竟是什么，我因工作关系，在电子、医疗等生产制造企业承担过十余年的ERP、PLM、CRM等企业常见系统的实施以及二次开发工作，在面向综合性国企、政府数据互联互通、智慧城市等项目里承担数据架构类工作近十年，所以个人认为产业层（目前多数是像电网这类垂直系统）需求重心是技术升级（高速交互与高度自动化交互），企业层需求重心是互联互通和原有价值保护（它才是形成AII中产业层的前提），边缘层是面向未来的泛在物联全新构建。

       第四就是当前以数据为核心的大趋势，它也是我近10年来数据工作领域的体会，数据除了呈现为决策支撑外，过程数据资产化已成必然。只是目前数据工作中的概念还比较混乱，不同的应用方向、技术路线把大数据、数据结构、数据架构、数据模型、数据集、决策数据、数据呈现、数据平台、数据中台、数据中心、数据仓库、数据挖掘、机器学习、数据算法等等绕成一团乱麻，它也让我遭遇了工作上的滑铁卢，在获取一个高级别的工作平台后，却在无序变革带来的概念及层次混乱中无法给工作内容清晰定位，也就无法为甲方做出有效贡献，于是卷了铺盖。沉默了近一年，仔细梳理了华为、阿里、京东等服务商提供的体系手册、资料以及针对甲方真实需求的回顾，将问题锁定在信息技术工程化问题上，为了验证思考，更深入理解重要行业的数据以及标准问题，个人也做了其它一些临时工作性调整。

信息化项目建设时，许多管理者都习惯用建筑工程项目进行比对，建筑工程项目管理能够标准化的前置条件：

l  分段、分部、分项清晰，场平、桩基、结构、水施、电施、消防、暖通、内外饰。

l  计量核量标准唯一，每一方土石、商砼，每一种材料都可以有标准计量。

l  结构技术上桩基、框架、砖石相对稳定，设计意图、实施范围容易明确。

信息化项目建设过程特征则是：

l  业务特征、业务需求与项目建设实施方案、技术紧耦合，形成交叉依赖，自然也会交叉影响。

l  计量上约定俗成的核价方式是“代码行”计量方式，但随着开源社区庞大的第三方库源代码开源，使得衡量工程造价的基础标准不再具有可信性，成本造价与产出交付价值失衡。

l  传统意义上的业务、价值链价值增长业务（如生产制造、销售等）与辅助业务（如人力资源、后勤保障等）、信息技术性业务之间因信息数据耦合性原因无法有效分离，使得项目控制难以机制化。

l  信息安全、状态探针的嵌入，物理硬件资源的虚拟化，虚拟技术的多样化，软件开发技术路径的多样化，应用领域的全面介入，新业态不断衍生深入，技术生态支持化都使得信息化项目越来越远离规范标准而走向特殊情况、特殊案例。

在考虑信息技术工程化问题时，除了上面这些内在的内容性和计量性因素外，还有外在法规制度、行业分类一些上层指导，但这些天国家发布了“数据安全法”（6月10日），国家统计局前几日则是发布了数字经济分类分级文件，将数字经济独立为农业、工业之后的第三种经济，区分两条路径：数字产业化和产业数字化。数字产业化包括数字产品制造业、数字产品服务业、数字技术应用业、数字要素驱动业四个领域；产业数字化只有数字化效率提升业一个业态。

数据安全法明确了数据权利归宿与数据利用保护，有了这些顶层的分级分类和法律规定，在范围和边界确认上就具备了法理基础。

目前来看，国家信息数据资源、产业管理部门下一步工作应该就是集中精力解决计量核量问题了，随着数字经济的明确，表明技术层面的一些核心思想已经达成共识：那就是让数据驱动占据主导地位，问题驱动、技术驱动、流程驱动退居辅助地位。这些工作都是形成工程标准的基础。