1.2 软件工厂——软件的标准化生产

最近在与某通信运营商的一位领导交流时，我得到一些启发。他认为IT领域之所以没有出现垄断性的软件生产商，根本原因是缺乏标准。通信运营商领域是从CT（Communication Technology，通信技术）领域发展起来的，CT领域是高度标准化的领域，国际行业标准非常完善，任何一家有志于进入CT领域的设备生产商，只要生产的设备满足行业规范标准，就能参与竞争，而IT领域并没有这样的标准化生产模式。因此，IT领域要健康、有效地发展下去，需要像CT领域一样有统一的信息化体系标准，软件生产制作在整体信息化体系标准指导下进行，所有进入的生产商都按照标准做事，力求集成容易、配合简单，最终实现业务能力完全开放，快速整合投入运营。

信息化体系标准，即IT系统采用CT化思路建设，将整个IT架构、IT基础设施视为一个整体，先考虑端到端，再界定其中的单元部分，以及每部分的功能、地位、与其他单元的关联性，每个单元可以按照生态域的逻辑进行工作，每个生态位必须满足两个基本条件：

（1）都是一个开放领域，都可以满足标准自由竞争，让最强者生存。

（2）可替换性。

只要满足以上两个基本条件，就能实现信息化系统快速整合上线，实现能力完全开放（对内、对外、对入口）。

1.2.1 标准化生产模式需要一个集成底座——PaaS

在上述理论指导下，标准化生产模式得以实现，我们可以借助PaaS（Platform as a Service，平台即服务）提供生产要素集成的底座。具体来说，就是PaaS要实现什么目标。我们的PaaS将来一定是一个应用生态的平台，为了让应用生态更好地衔接，底层应包括以下关键要求。

（1）与外部资源的交换、通信，包括对外能力API（Application Program Interface，应用程序接口）。

（2）内部支撑所有应用需要的功能，这些功能会以稳定的API层存在，成为移动业务所有应用标准化的基础，如RESTful、OSLC、Linked Data。

（3）数据层是一系列数据容器，支撑移动业务的所有数据。数据容器必须是抽象的结构，和底层数据库（Database，DB）无关。

1.与外部的交互设计

与外部的资源交换、通信交互必须采用统一的API，这种信息交换方式类似于细胞膜的物质交换方式。对于外部来说，内部是一个封闭的未知领域，不管内部怎么变化、更改，通过API调用就能得到想要的结果。

例如，当你需要一个地图查找功能时，一般来说是实现一个地图应用，如高德地图、百度地图等，但如果这个地图应用出现问题就找不到需要的结果。如果PaaS通过API形成统一的对外能力（地图能力），那么业务系统只需要调用地图API。至于内部是使用高德地图、百度地图还是其他地图，都没有关系，无须固定，可以随时切换。对外能力API固定之后，与外部的所有交互都是透明的，用户可以随时获取想要的结果。

2.数据容器设计

PaaS管理的数据必须是以非数据库方式存储的，必须是面向实体的。

采用RDF（Resource Description Framework，资源描述框架）进行业务实体的序列化（Data Serialization），当把对象从一个地方传输到另一个地方时，中间必然存在一种形式，比如文本。把一个对象变成一个半结构化文本的过程就是序列化过程。实体的序列化包括一系列对象的序列化，账户、用户、客户等都是对象，对象要序列化，数据容器的存储基础应该是对象的序列化，而不是现在的关系型数据库。数据存储最终要采用混搭模式（如SQL+NoSQL），实现这种模式的关键是序列化。

这样改造之后，PaaS管理的数据层就变成了一系列数据容器，数据容器都变成微服务结构必须满足OSLC、Linked Data、序列化等标准，这样数据和应用就可以随时像Docker封装好的集装箱一样移动。

3.能力开放设计

能力开放不仅指对内的能力开放，还包括对外（合作伙伴）的能力开放，争夺生态入口的能力开放。具体设计需要从以下三个角度考虑。

（1）通过构建应用生态中稳定的“冻土层”，以API层的形式存在，支撑所有信息化建设和业务应用的快速功能整合开发、上线。

（2）以可插拔的架构设计模式对外暴露生态位，合作伙伴可以随时竞争生态位，可以随时替换，可以随时部署上线运营。

（3）通过标准化的IT流程管控设计、成本模型设计、结构化的架构设计，形成开放的通信运营商IT、CT化管理、建设、运营能力，在C（Customer，消费者）端或B（Business，商家）端的入口争夺中（如园区生态圈、金融生态圈等）应用强有力的IT、CT化开放能力。

1.2.2 标准化软件生产流水线

生产力发展的主要标志是生产工具，社会发展的各个阶段就是以生产工具的发展水平来划分的。

软件行业处于发展的初级阶段，从生产工具的发展水平就可以看出。

高阶的软件制作生产模式应该是将业务需求和设计作为生产线的原材料输入，生产线先自动产生所需软件，然后部署上线并投产使用。

而现在的软件生产模式是：软件需求无法精确表达，设计与代码脱节无法直接映射，缺乏高级的生产工具，依赖人工编程的方式进行软件生产，这样必然导致软件生产严重依赖程序员的“创造性智力劳动”，以及程序员的工艺水平。

由于软件生产过程高度依赖人，而人又是容易出错的，因此我们会看到程序员辛辛苦苦、信心满满地生产出来的产品，在传递给大量的测试人员进行大规模测试后，却发现大批量的缺陷，返工成本居高不下。更重要的是，测试人员也是人，他们也会出错，无法覆盖大规模复杂应用的所有代码执行路径，从而导致这些缺陷交付给最终的客户和用户，在产品上线之后才被发现。

高级的生产力应该依赖高水平的生产工具，但反观现在的软件生产过程，工具应用得好的少之又少，我们尝试分析了一下原因。

首先是不擅长生产软件的甲方不务正业地拉上几个人凑成一个所谓的软件研发部门，采用大量外包的方式，找了一批价格低廉的外包劳动力，在不管开发商采用何种方式、何种技术、何种工具的情况下，吭哧吭哧地琢磨起所谓的业务支撑系统，发现问题了再改造、升级。可想而知，在这种软件生产模式下，没有人会考虑如何利用工具，也没有人会考虑如何改造和升级工具。

其次是工具的价格与价值认可问题。有些专业的工具生产商，如IBM、HP等，在某些领域做出了比较专业的工具，但是这些工具通常价格高昂，甲方要么没钱采购；要么觉得软件生产者已经转为外包供应商，他们自然应该自带工具提供服务，结果是外包供应商能满足合同要求就不错了，若还要增加工具的成本，他们自然不乐意；要么采购的工具被束之高阁，因为某些工具是用来规范约束开发商的开发行为的，开发商存在抵触心理，工具自然不会被利用起来，有些工具是需要专业技术人员操作的，而无序低价竞争模式下提供的劳动力是无法及时、有效地掌握这些技术的，加之劳动力的流动率高，工具应用形成最佳实践的机会不大。

从本质上看，是小规模作坊式的生产软件模式导致对工具应用的需求不大。只有流水线作业的工厂，才会对工具应用带来的效率提升、生产力提高有迫切需求。