软件平台的基本设计原则

是不是所有软件都适合做生态？当然不是。如果有一个图形算法程序能够提升摄像头拍照的清晰度，傻瓜才会把这东西开放出去，要是再想把它开源出去，那就更蠢了。类似这样的软件生态就更说不上了。并不是所有软件都是平台，不是所有软件都需要生态。

找到东岸和西岸

如果回忆一下前面所述我在WR的经历，整个设计逻辑一直都是在努力搭建起来一个连接芯片厂商和应用开发商之间的桥梁。我把这个过程称作寻找东岸和西岸。

东岸可以看做是生产方，西岸可以看做是消费方。在东岸和西岸之间由于某种原因缺乏一种有效的连接手段，需要一座桥梁来帮助东岸和西岸连接起来。

l  对于WR来说，芯片厂商是东岸，应用开发商是西岸。

l  对于微信来说，每个人对信息的分享欲望是东岸，每个人对其它人信息的渴望是西岸。

l  对于Android来说，手机硬件商是东岸，手机软件商是西岸。手机是东岸，用户是西岸。

任何一个软件产品，如果能找到你所在领域的东岸和西岸，那么你就有搭建一个具有生态潜质软件平台的可能性。东岸和西岸累计的客户越多，桥梁的价值越大。

清明上河图精华中的精华就是这座桥。

如果一个领域存在东岸和西岸，那么就有可能做成平台类软件，否则就不可能。依照这个原则：

l 车载系统是有东岸和西岸的。

l IoT是有东岸和西岸的。

l 一个摄像头的算法是没有东岸和西岸的。

l 一个智能摄像头里面的软件平台是有东岸和西岸的。

l 。。。

桥架起来了，如何能把平台做起来呢。有没有一些通用的规则。我们来探讨一下这个问题。

桥上卖水&形成风暴

很多时候，哪里需要架桥是一个大多数人都能看的到的事情，甚至在一条河上的东岸，西岸会同时有很多座桥梁。东西岸的用户选择哪条桥梁通过就是一个问题了，一般意义上来讲，作为一个过桥客，应该会考虑下面的几个因素：

l  谁先修好，越早把桥架好越有先发优势，大家更习惯通行。

l  桥上是不是舒适的休息区，渴了是不是能喝到水，饿了是不是能买到吃的，车坏了能修好么？

l  有过桥费么？

l  。。。

这是一个相辅相成的过程，越早修桥，早日通车就能早日吸引客户，早日吸引商铺入驻，更多的商铺，更多的服务入驻就能吸引更多的客户。更多的客户就能进一步刺激更多的商铺和服务。从而形成循环。

如果能完成这样的循环，基本上这个平台软件就成功了，生态也就逐步建立起来了。

整个过程比较类似风暴的形成过程，从一个小气旋开始，逐步的将周边的资源不断裹挟进来，形成飓风

其中非常重要的一条原则是：快。用快速的发展来摧垮对手，东西岸的客户是有限的，我们多一个用户，对手就少一个用户。

我们再来聊聊快吧。

现代软件的有趣转变

软件设计区别于硬件设计的差异前面的章节已经有了分析和介绍。这里我进一步的讨论一下。

现代软件经过长时间的发展，整体的面貌已经有了非常巨大的发展。作为一个工程师，我自己的体会有两点：

1.       软件的零部件极大丰富，现代软件早已经脱离了刀耕火种的时代，对于某个特定零件和部件来说，你肯定在github上能找到相应的项目，好用不好用另说，但是肯定有。很多时候，一个软件系统的搭建过程只是需要用胶水语言将现成的零件胶结在一起就能上路了。一个架构师的能力越来越多的体现在他的脑海里储备了多少已知的零件，是否能用最快的速度，用现有的零件把系统构建起来。

2.       编程语言发生了极大的变化。Python, Golang， Rust等一大波语言蓬勃而出，这些语言的开发效率相对C/C++快了几乎几个数量级。而且不容易出错。性能也不见得差。只要不是需要一个cycle一个cycle扣性能的地方，我看不到任何理由再选用C/C++了。更重要的是，这些现代语言，在设计初期就考虑到了代码的依赖性，甚至语言自己就内嵌测试单元测试框架，和github这样的开发平台无缝的对接等等，都让软件开发越来越从一个高智商的脑力活动变成了一种体力活。

这些变化归根结底还是让软件形成业务生态快点，再快一点。再这些变化的基础上，催生出了一个很有趣的变化，整个软件的开发组织也在逐步发生着变化。以往需要千军万马开发的大型系统，现在一些小团队，甚至是2-3个人就能建立起规模庞大的系统。

l  从统计来看，Etcd的核心开发就4个人，如果考虑merge pull，核心干活的应该不超过10个人，Etcd的代码规模可不小

l  Containerd，容器引擎的运行时代码10万行，活跃的开发也就4个，加上一些相对活跃的也不超过10个。

用新语言，使用新的开发体系，快速做出原型，快速演进，开发测试一体，这些在外界早已不新鲜的东西在华为还鲜有出现。

谁应该来做

前面已经讲了很多平台类软件应该具有的模式，那么在公司的范围内，那些部门应该承担这些职责呢？我个人认为，至少以下的部门我认为应该是走的靠前。

l  2012的软件平台部门。

l  产品线的软件平台部门。

l  某些已经成熟系统所属的部门。举个例子，espace，这个办公利器如果早点按照外部的玩法来搞，钉钉可能就未必存在了。

在华为，大部分习惯了自己的世界，可当我刚进公司的时候，看到espace，真的惊为天人，这是多少公司梦寐以求的办公系统，这么棒的软件为何藏在深闺人未知呢？肯定有人会质疑，钉钉现在也不赚钱呀，还持续亏钱，我们为什么要学习钉钉，我对此的回答是：

l  软件做到的最高层次就是钉钉这样把用户都揽入怀里，至于为啥要把这么多客户揽在怀里，这里需要有一个宗教般的信仰：客户最终都能转换成钱。这，就是软件的玩法。

l  钉钉目前不收钱，不代表未来不收钱，不收钱是一种扩充市场的手段，并不是目标。即使不收钱，只要客户群足够大，也有其它变现的手段。

l  Espace我不知道有多少人还在开发和维护，该投入的都已经投入了，该亏的钱也都亏了，可预见的未来还是在亏钱。那为何不能放出去一试呢？

l  假设这个世界上无数的公司都在用Espace办公，是不是能助力我们的公有云呢？是不是能为我们的公有云导入海量的客户呢？

回到部门的问题，其中2012的我认为应该是这个工作的排头兵。因为产品线由于本身急迫的产粮食的压力，产品线几乎没法去做稍微长期一点的打算，特别是这种所谓平台，生态，产业抓手等。这些东西前期都很难看到成效，而且周期又慢，失败概率又高。而承担公司向前看的2012应该是更多承担这类任务。

如果平台部门的定位发生了变化，则相应这个组织的运作模式，考评体系，预算体制等一系列问题都会受到很大的冲击。

平台部门的尴尬境地

理论上，承担上述任务的应该是公司的平台部门，但是不幸的是，平台部门本身目前是很难承担上述工作。原因很多。我们只做一个简单的对比吧，因此来说明问题在什么地方。

以风河为例，它的技术部门分为两个部门：

l  产品部门：负责核心产品，比如WRLinux, VxWorks等产品的开发，演进等等。

l  PS部门：在标准产品上提供定制化开发服务。

产品部门会按照自己的节奏（更多是行业的节奏）来规划自己的版本计划，产品特性等等。虽然会有客户拜访，但是整体上还是按照自己的节奏走。也就是说，产品部门的新产品会很大程度上影响PS部门，但是PS部门却很难影响到产品部门。产品部门有自己的“产品灵魂”。

但是在华为，各个层级的平台部门其实做的事情是WindRiver的PS部门所做的事情。所谓平台，看起来像是一个东西，但是从微观看，其实是为各个产品线一个个定制的烟囱，只是捆绑在一起起了一个名字而已。平台部门会因为一个产品线的一个“核心竞争力”而随意变动核心部件。本质上，各个平台部门没有“产品的灵魂”

承担公司各种战略任务的各个层面平台部门都做成了一个个PS部门，也难怪最终产品线会不断的质问“你们和高级外包有什么区别？”。一个部门的行为和它的定位是强相关的，和具体执行层面关系不大，即使把对平台部门怀有一肚子怨气的产品部门的人置换到平台部门，他们的做法也不会有一丝一毫的改变。

平台变成这样，还有一个非常重要的原因是由于一个在公司耳熟能详的词“差异化竞争力”。

差异化竞争力

讲到了平台，生态，就不能不再谈谈我司炙手可热的一个词“差异化竞争力”。一般来说，差异化竞争力一定是和产品强相关的，脱离一个具体的产品，平台系统自身不存在所谓的差异化这个属性，反而要“平庸化”，也就是要按照相关行业的标准来做东西。不同产品的差异化竞争力千差万别，没有一个统一的标准来衡量。

这里有一个很难以处理的矛盾。平台如果只强调标准化，除了能够保证业务的连续性以外，很难给产品线带来直接的竞争力。但是如果要给某个产品带来差异化竞争力，首要的工作肯定是要深入产品，针对产品有特殊处理，通常来说，对兼容性，标准型破坏越多，整个产品的性能越有可能提升。但是这样一来，就又和产品形成了强绑定，不自觉中又构建起来了一个烟囱。除了走到了烟囱，盒子的老路上带来的一系列弊端，这样做在未来还有可能带来另外潜在的问题：

举一个例子，比如EulerOS已经拿到了很多国际认证，包括EAL4+这样的高等级安全认证，这些认证都是基于标准产品做的，换句话说，就是EulerOS只有做的非常平庸，完全没有特点，才能和行业内的生态，标准进行对接。但是如果我们针对某个产品线做了特殊定制，那么这个定制的OS还算是EulerOS么？它还能享受EAL4+认证的保护么？这也是一个民不告官不揪的地带。但是过往的历史告诉我们，如果有可能发生的事情最终都一定会发生。

这是一个两难的境地，平台部门在产品线介入的越深，就越能提供“差异化竞争力”，但是这就几乎必然导致对平台整体架构的破坏，必然会让平台变成一个个烟囱，必然导致最终的人力陷阱。但是如果平台按照行业标准来演进，虽然可以避免上述的问题，但是也很难给产品线提供很强有力的炮弹，特别是盒子类产品。

这个问题的核心是：平台部门的定位到底是系统的提供者，还是能力的提供者。目前的运作机制来看，整个平台部门实际上是能力提供者的角色，也就是因为我拥有这个能力，所以，相对于产品线，是以出卖能力来支持产品线。这也是各个平台部门做着做着就做成了外包感觉的重要原因。

虽然看起来好像无解，但我还是从我的经验提出我的看法吧：

l  我个人认为平台部门应该更偏向系统提供者这样的定位，平台应该还是以固化能力，形成平台，帮助产品构筑外部生态，扩展行业生存空间为主。

l  平台部门本身也还是能力提供者的角色，但是这种能力提供者的目标应该倾向于将产品线的差异化竞争力通用化，标准化，产品化，开放化，做到安装即可用的状态。成为公司各种技术的汇聚点和交流点。

规划还是尝试

如前文所述，华为是一个硬件公司，大部分的设计思维是硬件的道路，在具体的行为方式上体现的也很具体，那就是所有人都希望未来是规划出来的。这是CT时代留给华为的深刻的烙印，因为在CT领域，标准是缓慢演进的，产品是按照标准来设计和迭代的，因此所有的一切都如同经典物理学中的动力方程般具有连续性和衔接性。如同天文物理学家运用经典物理学原理可以精确的预测所有行星的运动轨迹一样。

这种模式在CT领域或者硬件设计领域没有问题，但是在软件领域却并不完全是这样，如前面所述，软件开发有一个非常重要的一个特点，那就是“快”，就如同经典物理学在高速情况下不适用一样，传统的洞察预测，规划，实施这样的三部曲在软件光速演进的模式下就很难适用了。特别是在以云化，IOT，车载等环境下，在以互联网公司的带动下。

l  首先没有办法坐很清晰的洞察和预测了，所谓的未来的时间越来越短，在CT领域通常是以若干年来进行洞察和预测，但是在软件为代表的新兴行业，半年都是很遥远的未来了。

l  其次规划不出来了，经典物理学中所有的一切都是可以预测的，但是在量子力学体系中，所有的运动都是概率性事件。硬件设计和软件设计很有经典物理和量子力学的差别的味道。在软件领域，无论多高深的专家，也只能告诉基本原则，但是却无法规划未来。

l  在实施层面，硬件的设计和开发，用户见面的那个时间点是一个泾渭分明的分界线，发布前客户几乎不可见，发布后也很少变动。但是软件很大程度不是这样，很多时候，软件的设计和开发是一个和用户持续互动，随时调整的过程。没有硬件那么明显的分界线。

对于软件来说，越来越多的模式变成了如下的三部曲：

1.        做出一个原型。

2.        发布出去，把客户involve进来。

3.         依照客户，市场进行快速迭代，成功了就顺势而上，失败了则换一个思路goto 1。

软件不同于硬件，它的更新，撤销的成本很低甚至趋近于0。所以快速的试错，快速的跑马圈地，在行业内树立flag，这些都是软件成本低带来的行业的特点。

因此，传统上各级软件部门的洞察à规划à实施这样的体制可能要转变成为更为灵活的发布à试错à持续改进这样的模式上。

 

考核&预算机制

在任何一个组织，维护一个体系，创建团队文化都是通过考核和预算机制来实现的。如果整个平台部门的定位发生了大的变化，显然相关的考核和预算机制都需要做很大的调整。

本质上，世界上最容易的考核机制就是一个字“钱”，钱是一个产品价值大小的唯一客观准则，也就是用户用钱来投票的机制。但是不幸的是，一方面，诚如前面的分析，软件产业的商业意义在发生深刻的变化，平台部门越来越难以直接和“钱”打交道，即使如微信这样伟大的平台，真正的影子大佬是负责支付的微众银行。微信也仅仅是一个引流的渠道而已。另一方面，在公司内部，平台部门更多是能力中心，所以也没有办法直接用类似商品交易的形式来用钱来衡量。

当价值没办法通过用户拿钱来投票的形式衡量的时候，平台部门的考核机制逐步变成了竞争力评议机制，而在华为传统的竞争力定义下，就只剩下“性能”这个一个属性了，但这个属性又严重偏离了软件平台生态建设这个核心属性。所以导致了各级平台部门越做越别扭。越别扭就越强调竞争力。从而形成了一个负反馈的恶性循环。最终变成了一个个故事大赛，催生出一批批的故事大王。当一个个立项材料我这个做技术的都看不懂的时候，结果也就可想而知了。这些问题不是执行层面兄弟们的错误，是公司整体对平台定位的错位所导致的必然结果。

考核&预算机制是公司治理的范畴，这是一个专门的学科，我这个码农就不做探讨了。但是结合前面我们探讨的软件平台的核心价值是找到属于自己的东岸和西岸，并架起桥梁的整体设计思维。我认为考核一个软件平台（甚至硬件平台）至少有三个重要的指标是要纳入

视野的：

1.         软件平台和上游（东岸）厂商的连接程度。和越多的上游厂商有合作，有连接则考核越好。

2.         软件平台对下游（西岸）厂商的覆盖程度，覆盖越多的下游厂商则平台的考核越好。

3.         软件平台的用户规模。使用该平台的用户范围越广，用户规模越大，则考核应该越好。

brand，copyright，license，开源

前面说到了品牌，这里就顺带讲一下brand, copyright, license，因为这个是法律范畴，我不能代替律师来讲这些内容，在这里我只谈一下我的理解。很多人常常会把这些东西混为一谈。

以我的理解：

l brand（就是品牌）可以把一大堆具有开源license的软件放在一起贴上自己的标签成为brand的。比如Redhat, WR, EulerOS。

l copyright是开发者还是拥有它所有开发内容的版权的，他并不随着被集成的brand而受到影响。也不因为采用了某些开源license而受到影响。你开发的东西copyright还是你的。

l License是你对你的权利的一种说明，别人可以使用你的东西，但是不代表别人拥有你的东西。

因此，一个开发了属于自己copyright的软件的人，可以将自己的软件设定为开源的license，然后被另外一个公司集成到该公司brand下。如果这个开发者非法使用了该公司的brand，依然是违法行为。（画外音：喂，喂，是律师么？有人在这里瞎扯淡，砸你的场子，你们管不管？）Brand品牌是核心中的核心。

所以，公司里很多人理念中的一旦把代码开放出去我就失去了他们的理念是不对的。你写的东西永远是你的，没有人能拿走，只是我开放了一定的权利而已。我依然有诉讼你的权利。

好了，一下子讲了这么多，到了该总结一下的时候了。

总结一下

l  公司对软件平台的定位应该转变为成为行业标准，打破垄断和建立垄断，为公司开疆拓土的战略定位。

l  软件平台建立垄断的方法是做生态。

l  软件平台的生态是为了进攻而不是防守。

l  生态的目的是把用户，上下游等围在自己的怀里。

l  生态的核心是构建品牌。

l  建立生态要找到东岸和西岸。

l  建立生态比拼的是速度

l  平台部门的定位需要有所变化，由单纯的能力提供者变成系统提供者+能力提供者。

l  软件平台的上下游覆盖度和用户群规模应该是考核的重要内容

软件定位的问题基本上算是告一段落，任何一个在行业内能形成规模，构建起生态的都是一个庞大的体系。通常都是规模巨大。没有好的方法，也很难保证整个系统的稳定构建，也就谈不上能建立起这样的体系了。

下面更进一步的谈一下具体软件平台开发的一些模式和方法：敌人是规模