软件定义标准，软件定义一切

Biz 事业

/ Standard / tmf / tmforum / 华为 / 开源 / 标准 / 软件

• 2014年7月30日

at 2014年华为标准大会
by Jerry Zhu

序

在CT时代，我们一直认为是标准定义了软件。

IT来了，我们才猛然发现，软件已经跑在了前面，快速迭代、快速试错、快速占领市场，同时快速定义了标准。

有人说软件可以定义一切，小到计算、存储、网络这些基础能力，大到我们的日常生活、工作、行为，凡是一切可以用信息表达的都可以被软件化。也许在不久的将来黑客帝国中的Matrix不再是科幻片，而编程大师将成为这个世界的神….

为什么是软件？标准是什么？由谁定义？

回顾历史，从通讯终端的发展隐射出标准的变迁：从硬交换到软交换，从传统手机到智能手机，我们发现越是偏向硬件（物理设备），对标准的依赖性越强。成本、生产周期、互联互通等都是促进标准发展的动力。而现在，软件横行，虽然手机的box依然由众多厂商生产和开发，但业务的互联互通标准却逐渐在减弱甚至消亡。原因就在box之上的软件层中间件：OS。中间件是典型的IT产物，连接软件之间或是软硬件的隔离层，消除软件层级的复杂性，以便于各软件部件之间的沟通。搭载着iOS、Android、WP等智能终端的出现彻底颠覆了传统手机和业务对标准的诉求。以往，手机上的应用是嵌入到手机当中，用户很难进行升级、替换、删除，而只能通过刷ROM等繁琐复杂的方式实现。再看看现在，想要什么业务、应用，自己下载一个，直接安装即可，连我奶奶都会无障碍的使用。

智能手机是一种软硬分离的思想，手机是box是通用硬件，资源管理和逻辑控制是OS，而应用留给广大开发者和业务提供商。用软件的思想解构了手机，培养出了iOS、Android，用软件思想结构了网络，诞生出了NFV/SDN，软件思想解构标准，又会诞生出了什么？

业务有没有标准？如果有，那业务标准又是什么？我总结了3类业务标准：

第一类，互联互通类的标准，CT玩家笑了，这太熟悉不过了，您先别急着笑，我对其细分成3个子类，前两类是CT非常擅长和熟悉，而最后一类确是IT标准的路子对源自CT业务标准的思想冲击：

1) Protocol：通讯的基础，不可或缺，标准重要性无人质疑。

2) Flow+interface+parameter：接触过3GPP、OMA的朋友非常清楚，由于要考虑多vendor的场景，必须定义清楚交互流程、接口协议、接口参数等细节。3GPP的核心网控制，因为网络的物理特性和多vendor的现状，其作用不可或缺，而OMA标准的情况可以用惨烈来形容，除了早期2003年以前的DS（估计现在已经没人用了）、MMS、DRM、DM标准还有较广泛的商用，之后的标准被互联网的事实标准打的满地找牙、体无完肤（但专利的意义依然存在，标准和专利在业务层已经脱钩了），原因何在？来看看互联网怎么定义什么标准就知道了，由于不涉及多vendor和SP的互联互通问题，多数为第三个子类的标准：

3) Schema/Language：如XML、HTML、CSS、JSON等标准，它不定义业务模块、交互流程，而定义实现模式和表现方法，具有很强扩展性和易用性。并且，还有一系列的开发工具、辅助工具帮助实现。

可以看出， 2定义了业务是什么，如何交互，却不告诉你怎么做，用什么工具，而3并非定义业务本身，而是提供了原料和画笔，让开发者随意创作。

前者授之于鱼，后者授之于渔，
前者利益难平，后者和平共赢，
两者孰高孰低，自见分晓。

并且，由于消除了多SP和多vendor的影响，业务交互模式从之前的multi-C/S和NNI转变为B/S或single C/S模式，极大的弱化了子类2的标准价值。

———–

对于第二类标准，搞IT的再熟悉不过了，框架类标准。而这一类标准对于搞CT标准的人简直是噩梦：

其一，没法埋专利了；

其二，不是强制执行的；

其三，标准内容和产于方式变化巨大，标准人员和研究人员无法全盘handle了

而在过往3年，针对Framework类的标准做了一系列的探索和积累，也算小有成就，请参见下一胶片。

———–

第二类标准虽然头痛，但总还能从容应对，无非就是参与范围大了，参与主体多了而已。但对于第三类标准，最是让CT备受煎熬、苦不堪言。De facto，事实标准，刚开始是业务巨头（寡头）为主导价值链而定义出的标准形态，是一种松耦合的合作模式，以价值分配为控制手段。有点类似帮派，我打头阵，建平台，吸客户，小弟们共同打拼，利益分享，实现共赢，如Amazon AWS、Google GAE等，典型的老大吃肉，小弟喝汤的模式。

格局就是用来打破的，这世上总会有一些公司欲打破当前巨头制定的秩序，从虎口中分一碗羹。于是乎Open Source火起来了，Linux对抗Windows Server，OpenStack对抗VMWare，Android对抗iOS，典型的“合众弱以攻一强”的合纵策略。

无论是寡头还是开源，第三类标准的重点都在于：生态链的构建和价值的重新分配。

框架类标准的实践：TMForum

互联互通类标准大家的实践经验非常丰富，我也不敢随意板门弄斧。而对于比较陌生的Framework框架类标准，分享一些参与TM Forum (TMF)标准的经验。

在标准大会上与小徐总的对话中也可以看出一斑，它不能称为严格意义上的标准组织，而更像是行业组织，的确，在TMF的网站从2013年改版同时也修正了自己的定位为global trade association（全球行业组织）。小徐总戏称其为有“自知之明” 🙂 …不论他是不是标准组织，TM Forum对我们的价值是值得肯定的：

1) 800多个公司已加入了TMF，1/3是运营商，包括全球所有Top10的运营商。TMF的展会，超过1/10的人数为CxO级别（2013年5月Nice展，参会共3000+人，其中CxO占了350+），完美的接触客户机会！

2) TMF如同BSS/OSS领域的巴展，像GSMA在MobileCommunication领域的地位，包括全球展会、演讲、峰会、测试、认证、年度大奖、基准测试、产品认证、报刊杂志等一系列产品，完美的展示实力平台！

3) 99.99%的BSS/OSS的标书上会写明，需遵从TMF标准。不仅是BSS/OSS，在2013年SmartCare收到的某欧洲运营商的标书上一半的内容来自与TMF CEM标准。

这里并没有完全的列举出TMF的价值，如它是最早讨论和促进运营商向数字世界转型的组织之一等….

TMF是IT和CT融合的组织，我们一直痛苦地从传统CT标准向IT标准思想迁移。经过这3年来的努力，标准团队与BSS产品线各相关团队建立了的通畅的交流和互动机制，逐渐加深了产品人员和管理者对TMF标准的理解，并帮助产品实践标准，甚至深赴一线辅助项目应标和解答客户疑虑等。

人类是在压力中进化的，从痛苦的经历当中，我总结了少许经验与大家分享：

1) 标准团队是无法单独应对行业组织的，必须与产品和市场部门合作，各有分工去突破。而突破的主力应该是产品和市场，架构师、营销人员更应直接参与，标准专家除了标准职位、提案、影响力等传统标准职责以外，还应起到洞悉先机、思想步道和穿针引线等作用。

2) 标准滞后于产品或与产品齐头并进。最佳实践，不实践哪知道最佳？没有产品又怎么实践？

3) 产品符合度认证和卓越大奖是它的特色和亮点，极大的提升产品在业界的影响力和竞争力。据了解，如果不是2010年BSS产品荣获TMFSolution Excellence Award，很多运营商还不知道原来华为也是softwaresolution provider….

4) IPR不是主要诉求，商业价值才是终极目标！

5) 运营商利用TMF做什么？CxO交流平台，概念验证孵化器。如Orange Shine项目，利用TMF Catalyst（孵化项目），直接引用标书中的几个场景，在TMF召集几个厂商，就开始构建原型来快速验证商业需求，如同GSMA的PoC (prove of concept)。

IT标准新玩法：开源

最后再来聊聊开源，公司非常重视的领域。骨头再难啃，也要硬着头皮上。开源和标准天生纠缠不清，利用标准的方法管理起开源也是讨论热点之一。不论这方法能不能玩得转，先要弄清楚开源与标准之间的差异，我总结了开源的5New：

1) New Rules：新的游戏规则。与IT标准特征类似，IPR不是主要诉求（但不代表不重要），开源第一要看其商业前景，第二是看受众的多寡，第三才是技术门槛，而前两点是决定开源成功的最重要的因素。这也解释为何了CT技术不适合开源。

2) New Personal Skill：新的人员素质。激情我放在第一位并非随意为之，在OpenStack、Cloud Foundry等开源大会上接触到的小伙伴们可以清晰的感受到激情洋溢，尤其是谈起开源，眼睛里冒着光，浑身朝气蓬勃，与CT的小伙伴暮气沉沉的面貌截然不同（当然CT也经历过激情澎湃的岁月…）。第二，编码能力，不解释了，你懂的，但标准人员最缺乏的素质之一。第三，英文交流能力，在这点上，标准人员占了优势。第四，分享，开源本身蕴含着分享精神，如果你不乐于分享，那开源一定不适合你。

3) New Weapons：新的武器。如果标准提案、预埋、职位等是标准领域的武器，那开源领域也有相似的对应。提案，在开源里就是代码，它是最有力的武器，尤其是优质代码，如同优质的标准提案，让众人欲罢不能…职位，开源一般分贡献者、审核者、执行委员会成员、董事会成员，显然，这些职位都是与代码息息相关的。IPR，在开源中并非不重要，要么微软怎么能从每部Android手机中抽走$5净利呢，不过开源的IPR玩法不太一样，如果你明目张胆在代码中埋个专利，该专利很有可能被授权免费使用，如果强制收费，那一定会被无数人鄙视，很难再在业内混下去了…License，是开源独一无二的武器，它有效地制约了该项目的商业友好性和传播性。当然，任何约束都是一把双刃剑。

4) New Target：新的目标。我们的战场不仅仅是标准组织，还有开源基金会、开源社区、开源展会，甚至代码竞赛等。

5) New Player：新的玩家。敌人也是伙伴，是为了共同的敌人（寡头）而构建的生态链，不要总想着作恶。谁也无法预料最大的受益者，贡献多不代表收益多。Java的创始公司Sun最后还不是被Oracle收购了么，而Java最大的受益者也非IBM莫属吧。

拥抱开源，该怎么做？

IBM成为Cloud Foundry（CF）的战略合作伙伴这一新闻给了我一些启发，CF在PaaS开源中小有名气，由VMWare开源。IBM的加入将推进CF走向基金会运作方式，打消开源项目寡头控制的疑虑，并且IBM专门建立了CF开源团队，包括架构师和一票程序员组成，专门投入CF下一版本的核心代码模块的编写。