【CICC原创】软件定义战术（二）

喻祉祺  闫红伟（编译）  中国指挥与控制学会

软件交付是在正确的时间将正确的bit送至正确的位置。

历史经验表明，作战胜败不仅取决于拥有多少力量，还更加取决于如何动员和有效使用这些力量。正如第一次世界大战期间美国西线远征军司令、陆军上将约翰·J·潘兴(John J. Pershing)的精辟名言“步兵赢得战斗，后勤赢得战争”。

现代作战仍然需要步兵，但还需要从卫星成像系统中提取数据，将雷达信号传给某个导弹连，把对手的位置信息发送到步兵的平板电脑等等。

软件不仅正在改变经济，还与军事能力密切相关。正如物流是在正确的时间，将物资交付到最需要、影响最大的地方，软件交付是在正确的时间，将软件产品交付到需求和影响最大的地方。就像后勤一样，软件交付能力的高低同样可以影响战争的胜败。（美）国防部需要在和平时期的软件交付中奠定基础，通过优秀的适应性生成战略优势。

（一）对物流的思考

如图3所示，数百年来，物流体系在不断发展变化。各种发明催生了网络，网络又催生了系统，然后是系统之系统（体系）。随着系统设计者耦合更多的元素，系统复杂性也在增加，设计空间也变得更加开放。

图3不断发展变化的物流体系

物流体系不只是轮船、卡车和飞机的集合。它将高速公路网、铁路网、航空运输网以及其它东西耦合在一起，是一个集成了不同交通方式的网络之网络。此外，它是一个复杂的体系，通过软件，连接、运行着许多系统和网络，以最大限度地实现灵活性。例如，美军除了自身专用的运输能力之外，还有长期的商业合同，以及当地东道国的支持。

多层信息系统交织形成这样一个组织：军队软件系统发布订单；商业运输管理系统接收订单；第三方收集、融合全球的相关位置信息，预测交付时间，并将其回售以实现卓越的库存管理。多样性和复杂性是物流体系的基本特性。

图4将其分解为一个更简单的用例。读者可以直观地看到，其拥有多种运输方式，并需要在它们之间进行协调。关键的性能参数，如距离和有效载荷等，可以帮助我们做出选择，但可用性和人员熟悉程度也可以帮助我们做出选择。

图4物流体系中不同运输方式的协调问题

关于物流问题，也有一些隐藏的维度，如图5所示。对于任一特定的运输要素，一个组织可以通过许多不同的方式获得——购买服务或自己操作运载工具，购买现货载具，定制或租赁。想设计一个合理规模的、同质的（即只使用一种运输工具）物流系统，是不合情理的。最适当的做法是针对问题的不同部分选择正确的（交付）方式。

图5物流需要处理各链路、协调关系与要素间的流动

（二）与软件系统的相似性

如图6所示，软件交付与货物交付有着非常相似的地方。可供选择的应用和目标架构有许多种。正如让军方只能选择一种运输方式是不合理的，要求军方从一个集合中（手机、平板电脑、笔记本电脑、台式机、浏览器、增强或虚拟现实设备、中间件、嵌入式，固件），设定唯一的、标准化的架构也是不合理的。想要有效驾驭软件系统，涉及到多种模态的协调。

图6软件交付中跨模态协调活动

例如，并非所有军用软件都会以云托管的Web应用方式进行交付和使用。在图7中，程序员可能使用桌面环境实现对某种云环境的更改，而这个云环境还会从其他社区引入各类库和中间件。该云环境可能托管着一个Web应用，为某个已部署的（飞行）中队提供实时状态更新信息。当连接可用时，该中队的前沿部署人员可能会使用笔记本电脑从云端提取某种功能发布，然后在无连接的情况下，在执行任务之前，对飞机上的某个嵌入式系统进行配置。

图7软件交付需要协调诸多要素以实现能力优化

运输方式的选择不仅与距离和载荷有关，还可能与不断变化的环境有关。一般来说，我们可将这些环境或需求的变化描述为梯度(gradient)。一位硅谷的居民可能会租一辆滑板车前往公交车站，再坐公交车到火车站，坐火车到旧金山，然后叫一辆优步。环境的变化推动着决策的改变。

军队的运转需要依赖于体系，这意味着大量的梯度。未来的飞行员可能会先使用某款手机应用来预定使用模拟器训练的时间，然后使用增强现实/虚拟现实(AR/VR)在一个构造性训练环境中演练任务，然后向训练团队请教，并可使用连接到会议室台式电脑的双4K显示器重播训练情况，最后再使用固件和嵌入式软件执行真实世界的任务。在安全返回基地后，他们可能会将所有传感器数据卸载到在云中运行的无头中间件(headless middleware)，以进行后续分析和情报挖掘。国防部不仅应该容忍环境中的这种多样性，还应该认识到它是有益的。

（三）软件解决方案是一个组合论问题

对项目执行官(PEO)来说，在这样的生态系统中开发一个完整的软件解决方案架构，面临的是一个组合论问题。如表2所示。

表2：软件管理人员面临的难题（示例）

面对大量的选择和考虑因素，通过组合数学运算，项目执行官(PEO)面对的组合超过60亿种，这还没有考虑数据特性、人工智能/机器学习(AI/ML)的影响模型和其他支持技术。面对这种复杂性，想为美国防部确定一种最佳的软件交付解决方案是不现实的，采办人员需要接受异质（构）性。

（四）有效应对这种复杂性

有效应对这种复杂性是可能的，但应该围绕经济学理论展开，而不是技术或创新。全球移动通信系统协会(GSMA)的报告称，截至2021年底，有53亿人订购了移动服务，占全球人口的67%。考虑到机器对机器的移动服务订购，到2023年全球移动连接将超过85亿。这个惊人的统计数据意味着连接到互联网的片上系统(SoC)微处理器数量超过了生活在这个星球上的人口数量。根据荷兰ASML公司提供的数据，2021年，该行业制造了1万多亿芯片，相当于地球上每个人拥有130颗芯片，建造芯片制配厂的成本已经高达146亿美元。面对如此巨大的消费市场，各厂商舍得投入大量的资金，不断推动数字技术进步；而（美）国防部没有哪个采办项目具有如此的规模和发展速度。

消费者只有通过芯片上运行的软件应用，才能实现这些芯片的真正价值。到2025年，这些芯片和软件每年将产生175ZB的数据。

这些统计数据为美国防部及其项目执行官们描绘了其当前所处的经济格局。国防部曾经资金雄厚、实力强大，获得国防部合同就意味着生产的提升，但现在已经不是这样了。如今，经济格局发生了巨大变化，在全球芯片代工厂和云原生计算基金会(CNCF)等大型全球软件组织眼中，美国防部的消费已没那么重要。受这种经济格局的影响，对于美国防部来说，最合适的词是“觅食(forage)”；如今，国防部不得不四处寻找获得芯片和软件解决方案的途径，因为与巨大的消费市场相比，国防部已不再那样具有吸引力。

美政府问责局在2022年的一份报告中表示，美国防部计划采购2,500架F-35飞机。F-35设计中所需芯片的确切数量尚未公开。然而，即便按每架飞机购买10,000个芯片这种荒谬编造的数量计算，也只有2500万个芯片。对于2020年制造的万亿级芯片来说，大约占0.000025%。据报道，2020年款奔驰S级轿车的软件代码超过3000万行。与之相比，F-35据报道只有800万行软件代码。

从经济角度来看，国防部正在开发的技术最先进的平台，与商业领域的巨大市场相比，其芯片和软件需求显然是小巫见大巫。仅仅在几十年前，情况还不是这样——那时国防部的产品处于新型制造工艺和设施的最前沿。我们不应哀叹这一变化或将其归因于国防部的运营不佳。我们需要认识到，信息技术创造了一个巨大的商业市场，并引发了一种良性经济循环。我们应该接受它带来的变化。从经济上讲，（美）国防部必须寻找军民两用技术，而这正是项目执行官们在预测时存在最大机会和最大风险的地方。

（五）寻求规模经济

传统上，美国防部的软件交付方法是将资金和各种需求分配给各个项目办公室。各个项目办公室再签发各类合同，提供各自的产品以满足上述的需求。

这种方法的缺点在于它将武器系统视为独立的，就像从需求中派生出来的众多“雪花”（注：每片雪花的样子都是不一样的）。只有极少数的项目经理会寻找共性，重用一些构件。在这种模式下研发的某型濒海战斗系统，其控制台的各个构件与舰船机械紧密绑定在一起。然而，随着时间的推移，舰队和项目办公室需要花费大力气给操作系统打补丁、更换内存芯片或更新阀门伺服控制器接口。每一项工作都需要跟主合同商修改合同，更新相应的“雪花”以解决问题。

如图8所示，通过对商业公司和国防部进行类比分析，可以得到一个更佳的问题解决方式。没有哪个现代化的、灵活的初创企业会梦想采用雪花型模式实现发展目标。它们会选择一个云服务提供商来构建开发平台，随着员工的加入和产品的多样化，公司将在这个云基础设施和各种平台服务之上构建一整套应用。这样一来，在开发新应用时，无需针对每个新应用另起炉灶、构建新的平台，从而降低增量成本。美国防部想必会寻求集中式的安全云服务，为开发各种平台服务打造联合通用的基础设施，并集中资助或强制使用这些服务。这有助于实现快速协作和数据整合，尤其有助于实现各种集中式应用，如许多商业机器学习(ML)方法。

图8 雪花型、集中型和机会型模式

不幸的是，这种集中型模式是行不通的。美国防部的需求多种多样，各类用户和应用所需的安全保密级别不同，只是简单地提升所有用户和应用的安全保密权限是不切实际的。美国防部的某些软件需求很低，比如用于天线阵列伺服控制器的嵌入式软件。这些软件需要在气隙环境中运行，但仍能够在未来进行打补丁更新。对于各种web应用，无法通过单一开发渠道强制实施这种更新。此外，集中型模式无法充分发挥商业开发的优势。在某些情况下，商业应用非常适合在断开连接的安全网络中使用。在某些情况下，商业数据提取-转换-加载或AI模型构建工具可能非常适于某种安全应用。在某些情况下，美国防部可能会在准公共云上开发自己的应用程序，供盟友和合作伙伴使用。换句话说，国防部更像是一个经济体而不是一家公司。

因此，本报告提出了第三种模式——机会型模式。它与雪花型模式一样，仍需要项目执行官选择路径。但在第三种模式中，项目执行官是交付能力的最终集成者，负责从合作伙伴那里寻找可用的相似基础设施和平台。这是最可行的模式，既能提高开发效率，又能提高资金利用率。对于大多数的大型采办项目，这可能需要建立一个软件工厂或找一个现有的、合适的软件工厂。在这方面，美国防部几乎肯定会犯错。当初美空军Kessel Run团队选择了Dell收购的Pivotal Software平台，最终意识到这不利于政府继续集成、维护和交付完整的能力。虽然因失误耽误了一些时间，但这是学习过程的一部分。硅谷的初创企业也经常犯类似的小错误；例如，Snap公司认识到其需要多样化的基础设施提供商，从而改变了全部采用亚马逊Web服务(Amazon Web Services)的决策。在开发过程中，外部环境、可用的基础设施和平台都可能发生变化。

（六）渐进式架构

如同硬件采办需要首先确定需求，在软件采办中，寻求在软件开发之前就充分定义某种软件架构，这是一种错误认识。当然，在开发伊始可能会在架构方面犯许多错误，但只有当架构师在证据面前仍顽固坚持有缺陷的方案时，这些错误才会产生严重后果。经验丰富的软件架构师会欣然承认：在一个软件应用的整个生命周期中，最好的架构都是渐进式的，几乎没有僵化不变的。

人们很容易陷入预测陷阱，而忽略了这样一个事实，即软件开发中，由于追求“永不过时”(future-proofing)，使得开发人员更难将该代码用于任何单一目的。由于这种“永不过时”的影响，交付初始工作产品和收集反馈会变得更加困难。在许多情况下，更好的方式是立即着手解决一个重要问题并接受少量的技术缺陷。上述那些软件架构师也会说，过早进行最优化是有害的。

当然，物流中也有各种架构模式。比如，大型商业物流公司“联邦快递(FedEx)”肯定需要规划其在订单处理、航空运输、地面运输、分拣等方面的投资，但它根本不会尝试提前数年预测每个包裹的合适路径。联邦快递有些选择是固定的，比如枢纽机场、机队、主要分拣设施——但在许多方面是开放的，比如可以根据当前的知识，对每个包裹选择合适的运输路径。在发生机械故障或需求量过大时，它会从枢纽向各卫星机场派遣空闲飞机。虽然早期公司的领导者做了一些选择——包括选择孟菲斯作为一个枢纽中心并实现隔夜交付——但大部分物理架构是在随后的几十年里，随着公司的发展和新市场的开拓而形成的。即使作为一家大量投资于资本基础设施的公司，联邦快递公司的发展也不是从定义其架构开始的，而是专注于解决客户问题。

与采用“瀑布”方式定义和审查软件架构相比，项目执行官更应花时间确定期望的结果和用户需求中哪些是最重要的，哪些未来的发展路径最不确定，以及其项目的哪些方面最有可能需要改变。应当通过明确这些问题，再结合初始的开发工作，来解决架构问题。

初始的开发工作从哪里着手？这是一件复杂的事情。“捕食者”无人机的创造者、前以色列飞机设计师阿比·卡瑞姆(Abe Karem)有一句名言：“懒惰是优秀工程师的突出特征；平庸的工程师试图自己完成所有工作。”推而广之，一个好的项目执行官的突出特征是渴望在现有基础上进行扩展，而不是所有的东西都自己做。这充分反映了美海军陆战队网络空间司令部网络技术官瑞纳达·斯平克斯(Renata Spinks)等高层领导的观点：海军陆战队不想所有的事情都自己做。我们是一个讲求团队合作的机构。每个平台都是不同的，没有一个是放之四海而皆准的。如果有某种能力需求或存在某种差距，我们首先要做的就是去看看谁有这种能力或能解决这种差距，观察一下什么才是“正确的”。

在过去的几年里，美国防部的软件工厂已增加到至少30家。一个项目执行官，该如何考察、量化和确定某个能够完成初始软件开发任务的软件工厂，以及如何合理确定其所需的物流？

十多年前，约翰·库克(John D. Cook)认为，将软件重用描述为器官移植，比描述成拼装乐高积木更好。更进一步，与乐高乐园探索中心相比，现代软件工厂更像是一个一级创伤中心。随着软件在各个项目中的普遍应用，每个项目执行官都必须面对复杂的软件工厂物流问题，并选择一条路径：（完全靠自己）构建或重用。

历史经验表明，作战胜败不仅取决于拥有多少力量，更多地是取决于如何动员和有效使用这些力量。正如第一次世界大战期间美国西线远征军司令、陆军上将约翰·J·潘兴(John J. Pershing)的精辟名言“步兵赢得战斗，后勤赢得战争”。

现代作战仍然需要步兵，但还需要从卫星成像系统中提取数据，将雷达轨迹传给某个导弹连，把对手的位置信息发送到步兵的平板电脑上。

正如前面章节所述，软件不仅在改变经济，而且与军事能力密切相关。就像物流是将物资交付到最需要、影响最大的时间和地点，软件交付就是将软件产品交付到需求最大、影响最大的时间和地点。就像物流一样，软件交付能力的高低同样可以影响战争的胜败。同样类似于物流，国防部需要在和平时期的软件交付中奠定基础，以实现卓越适应性带来的战略优势。

（未完待续）

（《中国指挥与控制学会通讯》编辑部供稿）