数字化转型与平台战略

[摘要]

放眼数字化潮流前端的企业如亚马逊、海尔和华为等,我们发现在其快速响应力的背后,是一整套的支撑平台——顾客触点平台全方位洞察顾客所需、资源服务化平台快速供给数字化服务、数据自服务平台支持基于数据的决策、实验测量平台赋能受控创新实验。这样的平台帮助企业构建了强大的“生态圈”。

数字化浪潮对传统行业的冲击已经被越来越多的企业领导者所感知。据《哈佛商业评论》的调查,半数以上的企业高管认为自己的业务将在12个月内受到数字化浪潮较大程度的冲击,其中媒体、通信、消费者金融服务、零售、科技、保险、消费者产品、专业服务和教育等10个行业受到的影响最大。

图片来自:http://t.cn/RYz4m97

数字化对企业的要求

数字化到底对企业提出了什么要求?可以从一个真实的案例中看出端倪。一家全球知名的快消品企业,在京东618购物节之前花了大量的成本和精力设计促销计划,细到优惠力度、广告Banner等每个具体环节都经过多次论证。市场部从领导到一线员工都如临大敌,力求方案精益求精。对待一次重要的促销机会,当然需要重视,但是从上到下如此关注、投入如此多的精力,这是为什么?原来这家企业对市场数据的处理能力还停留在相当初级的阶段,电商平台提供的数据还在用Excel归集处理。在这种数据处理能力的支撑下,市场部的促销举措至少需要两周时间才能看到数据反馈。也就是说,一旦促销举措设计失误,在购物节的时间窗口内就没有再次调整的机会。

这家公司的情况让我联想起几年前看过的一组数据:Etsy在2012年平均每天能往生产系统部署超过30次;Amazon在工作日平均每11.6秒就有一次生产系统部署发生,峰值时一小时内部署超过1000次。当这家快消品企业响应一次变化、进行一次实验的周期需要以两周计,领先的互联网企业几年前就已经能够以小时、分钟为单位响应变化和开展实验。这种快速响应变化的能力,是数字化企业的核心竞争力。

为了打造快速响应的能力,海尔把传统的层级管理体制改造成了三级的自主经营体机制。海尔将7万名员工自我组织成了2000多个自主经营体,最大的自主经营体数百人,最小的只有7人,如果一个员工在海尔内部找不到一个自营体能够接受他,海尔就会和他解除劳动合同。海尔的首席执行官张瑞敏说:“每个小微(团队)都要变成一个个的小团体,所有相关人员都在这里头,负责开发某一个地方的市场,或某一个地区的市场。”直接来自顾客和市场的信息,就像鲶鱼一样激活了小团队的响应能力。

图片来自:Supercell

芬兰的游戏公司Supercell也倡导以小团队模式进行游戏开发,一般来说两个员工、或者5个员工、最多不超过7个员工组成独立的开发团队,称之为Cell(细胞),这也是公司名字Supercell(超级细胞)的由来。团队自己决定做什么样的产品,然后最快的时间推出产品的公测版,看看游戏是否受用户欢迎。如果用户不欢迎,迅速放弃这个产品,再进行新的尝试,期间几乎没有管理角色的介入。这家公司在2015年手机游戏排行Top10中曾占据榜单大半江山,2016年腾讯以86亿美元收购了员工数不到200人的Supercell公司84.3%的股份。

从海尔、Supercell以及其他很多小团队的成功经验中,我们看到直面市场与顾客的四大优势,使得他们能很好地应对数字化浪潮带来的对响应力的要求:

  1. 协作高效。小团队协同效率最高,能全力提供顾客所需,避免组织内耗。
  2. 目标清晰。小团队对战机(商机)的把握更加敏锐。
  3. 调整快捷。当情况发生变化或获得新信息,小团队能更快调整。
  4. 迅速扩展。一旦找准目标,小团队能全力投入,迅速扩大战果。

小团队需要大平台

然而,并非所有小团队都能天生地具备这四大优势。实际上,我们看到很多创业小团队并没有很强的感知和响应变化的能力。成都的一支小团队在2016年创办了“翘翘动感沙拉”品牌,针对有轻餐食及塑形需求的白领人士,一方面能够作为一道主食满足都市白领的午餐需求,另一方面为有塑形减脂需求的人士提供热量较低且健康的食物。翘翘沙拉斥资30多万装修厨房,邀请了国际五星级酒店主厨加盟,筹备用了近半年时间。上市后才发现产品定位与市场不符,4个月后就停止了经营。这支小团队规模虽小,却没能发挥出预期的响应力。

再次放眼站在数字化潮流前端的企业,我们会发现:原来他们不止是倡导小团队模式,而且为小团队建立了一整套的支撑平台。在海尔的自主经营体结构中,有三个层次的自主经营体。其中一线经营体直接面对顾客,为所负责的顾客群创造价值;二级经营体(或称平台经营体)则为一线经营体提供资源和专业的服务支持,包括人力资源管理、供应链、市场营销、质量体系、战略管理等,所以,平台经营体是一级经营体的资源平台、流程平台、专业化服务平台。平台的存在让一线经营体获得了响应力。

图片来源:http://pic2.pedaily.cn/201609/20169680137734.jpg

阿里巴巴则是用共享服务体系支撑前端业务。今天的阿里巴巴已经将集团20多个核心业务中公共的、通用的业务以服务的形式沉淀到了共享业务事业部,整个集团的核心业务能力均建立在这样一套共享服务体系之上。共享服务体系从会员、商品、交易、支付四大中心开始建设,支撑1688、淘宝、聚划算、闲鱼及全集团超过2000个应用。共享服务体系强调的能力包括:服务分布的能力;数据分布的能力;数字化运营的能力;平台稳定的能力;平台开放的能力等。

《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》

华为也在强调用大平台炮火支撑前线指战员。任正非在华为质量与流程IT管理部员工座谈会上说,华为内部IT要做到“能力模块化和微服务化,使能公司实现数字化转型和大平台下的精兵作战,在研发、销服、供应等业务领域要率先实现ROADS体验(实时、按需服务、在线、自助、社交化连接)”。

透过对各种小团队的观察我们发现,独立自主、直面顾客的小团队,在具备组织灵活性的同时,也必定面对基础能力的局限。那些走在数字化潮流前端的企业,都是以平台形式为小团队提供了四大能力的支撑,才能发挥出小团队精准、灵活、高效的优势:

  1. 洞察顾客的能力。小团队需要透过多种数字化渠道获得对顾客的全面了解。
  2. 服务供给的能力。小团队需要迅速整合企业内部的资源和能力为顾客提供服务。
  3. 数据决策的能力。小团队需要随时捕获市场反馈,根据真实数据做决策。
  4. 实验创新的能力。小团队需要开展受控实验,通过实验检验创新假设。

数字平台战略

企业数字平台,是基于云计算“基础设施即服务”(IaaS)能力之上,为企业数字化战略提供能力支撑的一系列平台服务(PaaS),涵盖IT系统研发与运营全生命周期。企业数字平台为直面市场与顾客的精益团队提供顾客洞察、服务供给、数据决策、实验创新四大能力支撑,赋能团队快速创新和响应变化。而这四大能力的基础,是IT组织的精益研发能力和相应的基础设施。

对众多成功的数字化企业的调研显示,这些企业有着一些引人注目的共性。他们逐步构建自己的数字平台,以此为基础激活企业核心资产。数字平台支撑小团队迅速响应市场和顾客的变化、高效地实验创新,给这些企业带来了显著的改变:

  • 提升IT效能,为产品和技术团队赋能,更快更好地为客户交付产品。
  • 构建行业生态,使得新业务、新产品、新服务能充分利用服务化后的企业核心能力和资源。
  • 促进业务创新,充分利用核心资产进行高效、快速的创新实验,保持企业竞争力。

特别针对数字化小团队需要的四大能力,ThoughtWorks的数字平台战略提出了一个基础设施、四个平台的框架结构:

  1. 精益研发需要的交付基础设施。
  2. 顾客触点平台全方位洞察顾客所需。
  3. 资源服务化平台快速供给数字化服务。
  4. 数据自服务平台支持基于数据的决策。
  5. 实验测量平台赋能受控创新实验。

基于数字平台战略提出的框架,企业可以结合自身情况,逐步建设当前数字化进程所需的支撑平台,用平台助推企业的数字化战略。

了解更多关于数字平台战略的信息,可下载《数字平台战略》白皮书。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

什么是数字平台战略

传统企业正在面临IT新技术的挑战——单从“传统企业”这个居高临下的称谓,你就能读出“非传统企业”(也就是IT企业、互联网企业)满满的优越感。每天在各种新媒体平台上看着BAT们又掌握了什么黑科技、又颠覆了哪个行业,“云大物移”已经成了高频出现的热词,传统企业们愈发清晰地感受到IT的重要性与挑战。数字化浪潮躲不过,和BAT拼技术又拼不过,传统企业的出路在哪里?

目光投向大洋彼岸,最传统的传统企业、年收入数千亿美元的沃尔玛在过去几年中的数字化历程颇有可玩味之处。直到2011年,沃尔玛还不是出色的数字化玩家,只能算一个有电商网站的线下零售商而已。正因为如此,当沃尔玛的电商收入在2011年至2014年的三年间增长150%、从年销量49亿美元增长到122亿美元、超过史泰博(Staples)成为亚马逊和苹果之后的美国第三大在线零售商时,这一变化才更令人惊叹。像沃尔玛一样的数字化转型先行者,能给我们带来哪些启示?

数字化企业的三个关键字

首先,传统企业们需要清楚一件事:“传统”不应该是贬义词,它同时意味着数十年积累的宝贵资产,包括客户关系、数据、品牌形象、供应链、渠道等等。传统企业要在互联网时代的竞争环境中占得一席之地,靠的不是突破最高精尖的技术领域,而是以数字化的形式激活自己多年累积的核心资产,将核心资产转变为可以在互联网上使用的服务,使其焕发新的价值。

对众多成功的数字化企业进行的调研显示,这些企业有着一些引人注目的共性。在“激活核心资产”的过程中,他们对三个关键字的重视特别值得我们关注:IT效能、生态系统、创新实验。

首先,这些成功的数字化企业重视提升IT团队的效能。正如ThoughtWorks在第16期技术雷达中所指出的,技术人员的工作体验正在成为科技企业的差异化竞争优势。这里所说的“体验”不止是给程序员舒适的座椅和人体工学键盘,更重要的是消除IT团队在工作中遇到的阻力和摩擦,尤其是充分利用云计算的弹性能力大量简化和自动化与实现业务功能无关的基础设施性工作,让IT团队将注意力集中在真正与业务相关的工作上。这里涉及的一些技术和实践(例如技术栈管理)乍听起来可能困难重重,但为提升IT团队效能付出的成本终将物有所值。

随后,这些成功的数字化企业把他们的核心商业能力与资产以服务的形式在互联网上提供出来,构建本行业的数字化生态系统,使新的服务和产品能够在这些服务的基础上被创造出来。同样是在技术雷达中,我们看到了“平台的崛起”:几年前只有亚马逊这样的巨头企业能在互联网上提供各种云服务;而现在有更多原本不太有“互联网基因”的企业围绕自己的核心资产建立起了数字化平台,不仅对内、而且对外提供服务。在国内,我们看到华为把软件开发能力变成了云服务、海航建立了自己的云生态。我们相信,更多的企业也能从核心资产的服务化中受益良多。

最后但绝非最不重要的,这些成功的数字化企业养成了创新实验的习惯。在互联网中弄潮的经验让他们承认,自己不能预先掌握所有需求、做好所有设计。因此他们转而打造组织的响应力,致力于缩短精益创业的“构建-度量-学习”周期。他们知道成千上万的用户不会明明白白地说自己想要什么功能,于是他们监控用户行为、用A/B测试等方法进行受控实验,用“假说-实验”代替了“需求-实现”,在不断的反馈中完善自己的产品和服务。

数字平台战略的五大支柱

以提升IT效能、构建行业生态、促进业务创新为目标,有志于迈出数字化步伐的企业应该立即开始制订自己的数字平台战略蓝图。不要被“平台”和“战略”这样的大词欺骗:这个以增强企业响应力为目标的平台战略不应该是在漫长的规划之后建设出一个庞然大物,而应该是迭代的、精益的、价值驱动的。更多的时候,我们谈论的“数字平台”更像是一系列IT技术与实践的落地结合。这些技术与实践有机构成的五个支柱,让数字化的企业能快速交付IT系统、围绕核心资产构建云上生态系统、从线上系统和用户行为中获得洞察、开展受控实验、并为顾客创造全渠道统一的用户体验。在成功的数字化转型案例(例如沃尔玛的案例)中,我们就能看到这五个支柱的投影。

第一个支柱:支持云和敏捷的交付基础设施

为了让IT团队快速交付,他们使用的基础设施应该具有弹性,开发、测试、运维等不同角色应该可以随需动态获得完整的应用环境,从而统一环境、标准化研发实践、规范化研发能力。他们开发的应用程序应该用持续交付实践打通开发、构建、验证和部署流程,使软件随时处于可发布状态。他们的交付流程中应该内建对安全的考量,而不是依赖最后的整体安全检查。生产系统所使用的运行时环境应该前向拉通到验证和研发环节,保障运行时环境的一致性。需要对系统的IT运维和业务运营进行全面的监控,聚合起来了解系统整体状况。

第二个支柱:以微服务为核心的API和架构治理

为了鼓励不仅企业内、还包括企业外的开发者在平台上发挥创造力,平台架构和API的设计应该注重开发者体验。在API的背后,应该从业务功能的角度出发划分合理的限界上下文和服务边界,对外提供高内聚低耦合的服务。在服务边界之间,应该考虑使用异步的事件机制实现服务之间的通信,来客观地描述运行时间比较长、甚至本质上不可能立即完成的操作(例如涉及人工操作)。为了方便使用者,应该提供API网关作为所有服务使用者的单一入口点,在API网关背后去处理众多内部IT系统的复杂性。整个API架构应该以微服务的风格呈现,避免典型SOA架构中普遍存在的、过于复杂的ESB编排逻辑。

第三个支柱:允许开发团队数据自服务

为了让业务和研发团队获得关于生产环境、关于线上业务、关于顾客的洞见,他们需要首先定义数据流水线,使数据能够顺畅地流过收集、转换、存储、探索/预测、可视化等阶段,产生业务价值。他们需要用实时的架构和API在短时间内处理大量、非结构化的数据,从中获得洞见,并“实时”影响决策。为了提高应变能力,系统中的数据不做ETL预处理,而是以“生数据”的形式首先存入数据湖,等有了具体的问题要回答时,再去组织和筛选数据,从中找出答案。IT团队会更进一步把数据包装成能供外人使用的产品,让第三方从数据中获得新的洞见与价值。为了支持数据产品的运营,他们需要实现细粒度的身份认证,针对不同的用户身份,授权访问不同范围的数据。

第四个支柱:创新实验基础设施和监控体系

为了让创新真正基于数据(而非拍脑袋)来开展,IT团队需要从多种来源采集关于系统、关于顾客的数据。需要根据业务目标在系统中埋设监控点,并及时把监控结果可视化呈现给业务用户。为了降低实验试错的风险,在把新版本发布给全部用户之前,应该以“金丝雀发布”的形式首先发布给一小部分用户,确保新版本不造成重大损害。系统需要支持功能切换开关(toggle),允许团队在不修改代码的前提下改变系统的行为,再加上用路由技术支持蓝-绿部署和A/B测试,方可高效地开展受控实验。

第五个支柱:支持全渠道的用户触点技术

为了通过多样化的触点技术向顾客提供随时随地、连贯一致的用户体验,整个企业需要建立对其顾客和目标顾客的唯一、连贯、准确、整体的视图,从而更好地了解和服务顾客。他们需要结合顾客的特征和不同数字渠道的特征建立连贯的内容策略,在多种渠道(例如电脑、智能手机、门店等)之间引导顾客的消费旅程,与顾客产生正确时间、正确地点、正确方式的交互。基于从各种渠道获得的顾客本人及其行为的数据分析,他们可以向顾客提供定制化的内容、服务和产品推荐。作为必要的技术保障,所有数字渠道的软件应用(尤其是原生的Android和iOS应用)都应该实践持续交付,这样才能实现全渠道的快速响应。

小结

在数字化的浪潮面前,传统企业不必恐惧于互联网企业的技术优势。只要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱,逐步建设自己的数字平台,不断提升IT效能、构建本行业的数字化生态系统、养成创新实验的习惯,传统企业同样可以用数字技术激活自己多年积累的核心资产,在新的竞争环境中找到自己的一席之地。

了解更多关于数字平台战略的信息,可下载《数字平台战略》白皮书。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

从海尔模式看数字化平台

[摘要]

探讨海尔“人单合一”管理模式的已经有很多。那如果要变革成这样一种管理模式,需要什么样的数字化能力,什么样的数字化平台支撑呢?文中的思考希望能对你有所启发。

关于数字化、网络化转型的目标,海尔的定义是:企业无边界、管理无领导、供应链无尺度。

  • 企业无边界,意味着要让全球第一流的资源进入海尔,并能够持续动态优化。
  • 管理无领导,即打破科层制组织,让员工与用户零距离连接,拥有自主权,快速响应市场,最终实现“无为而治”的最高境界。
  • 供应链无尺度,要探索按需设计、按需制造和按需配送的体系,实现从大规模制造向大规模定制的转变。

与这个定义相对应的运营体系是人单合一管理模式,其中包括了顾客价值、自主经营体、日清体系和人单酬四个基本要素,分别体现了业务经营的目标、组织形态、工作方式、度量方法。对顾客价值负责的自主经营体,抢单进人、按单获酬,日常工作讲究日清日高,那么自主经营体必然就会进化为与顾客、与市场、与业务价值高度对齐的“双创小微”。

双创小微具有驱动力强、响应灵活的优势,潜在的劣势则有两个方面:

  • 第一是小微目标与公司目标缺乏对齐、彼此之间形不成协作效应;
  • 第二是基础能力缺失或重复建设,不能保障服务交付的高效与高质量。

经过多年的探索,海尔发现三层结构既能体现足够的控制,又能够维持各个系统自身的活力。所以,在海尔的自主经营体结构中,有三个层次的自主经营体,分别是一级经营体、二级经营体和三级经营体。

图片来自:http://pic2.pedaily.cn/201609/20169680137734.jpg

  • 一级经营体,又称为一线经营体,这些经营体直接面对顾客,为所负责的顾客群创造价值。
  • 二级经营体,又称为平台经营体,它们为一线经营体提供资源和专业的服务支持,包括人力资源管理、供应链、市场营销、质量体系、战略管理等,所以,平台经营体是一级经营体的资源平台、流程平台、专业化服务平台。
  • 三级经营体,又称为战略经营体,主要负责制定战略方向,解决内部的协同和发现新的市场机会,同时为经营体配置资源,帮助一级经营体和平台经营体达成目标。

这个结构与1960年代英国控制论学家斯塔福·比尔提出的“可生存系统模型”有异曲同工之处。如果将可生存系统模型简化为“肌肉(系统1)-神经(系统2/3)-脑(系统4/5)”的三级,它的落地形态就会类似于海尔的三级自主经营体。

图片来自:http://7xpvay.com1.z0.glb.clouddn.com/d04bd630-b32d-11e6-96cf-69a982993485

双创小微有三个基础:制度之基是用户体验交互制;人才之基是创业者;平台之基是云平台。云平台可以看作是二级经营体的IT替身:为了面向大量、变化频繁的小微(海尔8万多员工分为2千多个自主经营体),为了跨越企业边界支持企业内外的创业者,平台经营体不可能再靠人工提供服务,必须以云平台的形式提供小微需要的资源和服务。

于是人单合一管理模式就演变为一个创业平台模式,它包括一个主题和两个功能。海尔人单合一创业平台模式的主题是“人和机会的匹配”,即创业者和创业机会的匹配。为了服务这个主题,它有两个主要功能:创业机会的识别和创造(Opportunity Creation)和创业机会的转化和实现(Opportunity Capture)。前者聚焦于创业者如何把市场上的潜在需求转化和升级为消费者的实际需求,从而识别、发现或者创造出新的商业机会;后者则强调通过一系列机制设计、制度安排、创新策略等将战略机会进行转化,从而为消费者创造价值。

基于机会创造和机会捕捉这两个功能,海尔交互与协同平台是人单合一管理模式最为重要的信息支持平台。海尔交互与协同平台包括6大系统:以顾客为主的虚实交互平台、开放式创新平台、供应链信息平台;以员工为主的电子损益表、电子人单酬表、信息化日清平台。

《智慧转型》的框架来分析,这些系统帮助一线经营体获得4种能力,从而更好地为顾客创造价值:

  • 准确掌握顾客和市场需要的能力
  • 快速、高质量、低成本地交付顾客所需价值的能力
  • 基于数据了解并改进工作状态的能力
  • 通过受控实验快速验证创新的能力

图片来自:http://t.cn/RjGxlV3

在创业平台模式下,顾客、员工和企业都被重新定义。顾客被重新定义为“资源”,员工被重新定义为“创客”,企业则被重新定义为数字平台。在海尔组织中只有平台主、小微主和小微成员三类角色,小微成为为用户负责的独立运营主体,只有为用户创造价值才能获得报酬,充分享有决策权、用人权和分配权。小微和平台之间是市场结算关系,平台的报酬源自小微。

从这个角度,海尔的组织变革不是简单的扁平化、跨部门和跨层级通道的建立,或者新设部门。海尔的组织变革核心是,在一流资源和用户之间架构起快速配置资源的平台,释放平台的同边和跨边网络价值。


了解关于数字平台战略的信息,可下载《数字平台战略》白皮书。

更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

技术领导者即服务

八年前我写了一篇文章《Tech Lead的三重人格》。迄今为止为数众多的敏捷交付团队中,Tech Lead(技术领导者)对于交付的效能和质量起着至关重要的作用。

我在那篇文章中指出,Tech Lead需要扮演三种重要的角色:技术决策者、流程监督人、干扰过滤器。一支团队能否有效采用架构最佳实践、交付流程最佳实践和项目运作最佳实践,很大程度上取决于Tech Lead把自己的工作完成得多好。

如果更进一步把那篇文章中Tech Lead承担的责任做一个拆解,我们可以看到,一个称职的Tech Lead是这样去为项目的顺利交付做出贡献的:

  • 首先,他要制订适合该项目要求的技术方案。他要参与架构设计,了解平台和编程语言、主要的框架和库、集成点、部署策略、数据迁移策略,确认总体技术方案能够支撑系统的业务要求。
  • 随后,他要保障交付顺利开展。他要确保环境的一致性,搭建和管理持续集成流水线,指导并监督团队遵循持续集成的流程和实践。
  • 最后但绝非最不重要的,他还要管理和提升团队的能力。他需要确认团队是否熟悉用到的技术栈和工具,而且——虽然这一点在我写文章时的ThoughtWorks还不那么凸显——要帮助团队成员组织刻意练习来提升能力。

正如当时那篇文章的一位读者非常正确地指出的,要一个人做这三方面的贡献很多时候是不切实际的。在很多组织里,这三件事是在三个环节中分别进行的,这三个环节的彼此割裂造成了很多问题:

  • 在方案环节,架构师根据客户的要求和痛点,基于自己的知识储备设计技术解决方案。他是如何分析客户的要求和痛点,他的知识储备是什么,组织里的其他人不一定知道,于是不同架构师提出的解决方案就很可能不一样。
  • 在交付环节,交付团队基于自己的知识储备来交付技术解决方案。方案背后隐含的知识储备,交付团队未必具备,所以屡屡会出现交付质量不佳的问题。不是他们没有能力,只是能力与方案的需要不符。
  • 组织感到团队的能力有不足,于是找来教练提升能力。然而教练基于的是一个标准的能力集来训练团队,这个能力集与项目实际需要的能力又不一定匹配。于是出现能力发展计划不对症、能力建设效果不明显的问题。

由此可见,只有当方案、交付、能力三者有很好的协同,项目和团队才能健康成长。而这个协同之所以尤其困难,是因为它跨了三个非常不同的问题域(在很多组织是三个不同的功能部门),需要三种非常不同的能力,对这个居中协调者的要求非常高。

所以,如果我们能用一个云上的平台来承载这个居中协调者的能力,对整个组织的交付质量和能力成长都会有帮助。这个平台的核心实际上就是技术栈管理:针对典型的应用场景(例如企业资源服务化、移动数字化渠道),制订组织统一的技术栈,并从技术栈推导出对应的能力评估模型和刻意练习课程。于是我们就得到了以技术栈为核心的IT能力三环联动模型:

当提供技术方案的架构师选择一个技术栈,用这个技术栈交付软件的能力要求就被明确地传达到交付团队。交付团队不用自己去设置开发环境和持续交付流水线,用云原生的持续交付环境即可启动开发,并复用在技术栈上积累的交付最佳实践。通过云上的能力测评系统,能力教练可以清晰地知道哪些成员已经具备需要的能力、哪些成员能力还有差距,然后为有差距的成员提供针对性的刻意练习和指导。

云计算已经成功地模糊了硬件与软件的界限,使IT的一大挑战——管理设备——极大简化。现在,对于IT的另一个大挑战:人才短缺,云计算的“XXX as a service”模式是否可以继续发挥作用?IT组织是否可能借助云计算获得优质IT人才的弹性和伸缩性?这是一个值得去探索的课题。在这个方向上,将对交付质量与效能起着重要影响的Tech Lead的能力以云平台服务的形式提供,有可能是触手可及的一个目标。


更多精彩内容,请关注微信公众号:软件乌托邦

Share

持续交付2.0:云原生持续交付

《持续交付》提出了一系列贯穿整个软件交付生命周期的最佳实践。但它成书的年代(2010年)云计算尚未得到广泛应用,尤其在软件开发过程中的应用非常有限。如果站在今天的技术水平和对云计算的理解水平基础上回顾《持续交付》的内容,我们有可能提出一组全新的、原生于云环境的持续交付实践。

软件发布的反模式

《持续交付》中列举了软件发布过程中的一些反模式,这些在行业中常见的不佳实践使软件发布过程容易出错,使软件发布的风险和压力增大。这些与可靠的发布过程相对应的常见的反模式包括:

  • 手工部署软件。靠详尽的发布文档来描述发布步骤及每个步骤中易出错的地方,靠手工测试来确认发布后的应用程序是否运行正确。不自动化的部署过程既不可重复也不可靠,会在调试部署错误的过程中浪费很多时间。
  • 开发完成之后才向类生产环境部署。开发团队认为“开发完成了”,才第一次把软件部署到类生产环境(比如试运行环境)。假如应用程序是全新开发的,第一次将它部署到试运行环境时可能会非常棘手。
  • 生产环境的手工配置管理。通过专门的运维团队来管理生产环境的配置,如果需要修改一些东西,就由这个团队登录到生产服务器上进行手工修改。经常导致部署到生产环境时就失败,尽管多次部署到试运行环境都非常成功。

在云计算的背景下,我们可以看得更远一步:这些反模式如果在今天的研发团队中仍然出现,背后反映的是这支研发团队还不会利用云计算提供给他们的便利能力。

  • 手工部署软件 => 软件发布形态和流程不标准。因为软件的发布形态多种多样(JAR、WAR、RPM、DEB……),因为软件的功能与配置不解耦,所以才会需要手工部署。而发布形态和发布流程的不标准,背后的原因是计算资源稀缺,需要复用服务器。
  • 部署到类生产环境太晚 => 开发环境与生产环境不统一。因为开发和测试用的环境与生产环境有很大差异,才会出现部署到类生产环境时的种种困难。开发环境与生产环境的不统一,背后的原因也是计算资源稀缺,生产环境昂贵,无法做到随需可得。
  • 生产环境手工配置管理 => 环境管理情况复杂。因为环境需要长期使用且不断升级,才有了对环境进行管理的需求。环境需要长期使用和升级,背后的原因是计算资源缺乏弹性,不需要的时候不能随意丢弃。

对于这些反模式,《持续交付》提出的解决办法是“将几乎所有事情自动化”。但在当时的技术水平下,由于软件发布的形态和流程不标准、开发/测试环境和生产环境不统一、环境管理情况复杂,“将发布流程自动化”在每个团队的具体做法都不同,因此持续交付的水平高度依赖于团队的能力与觉悟。《持续交付》也只能苦口婆心地劝说“如果需要执行这个流程数十次的话,就不是那么容易的事了”,而且“不需要把所有的东西一次性地全部自动化……随着时间的推移,最终你可以、也应该将所有环节全部自动化”。

但如果在软件的开发过程中充分利用云计算的弹性能力,这些反模式有可能被根除,而不必由每个开发团队重复地尝试通过自动化来缓解。

部署流水线

《持续交付》提出了“部署流水线”的概念(如下图)。“随着某个构建逐步通过每个测试阶段,我们对它的信心也在不断提高。当然,我们在每个阶段上花在环境方面的资源也在不断增加,即越往后的阶段,其环境与生产环境越相似。”

在充分利用了云计算的情况下,部署流水线会有两方面的改变:

  1. 不存在“所用环境与生产环境的相似度增加”的情况,从提交阶段开始(甚至在此之前的开发阶段),所有环境都与生产环境是一致的。
  2. 由于不需要根据项目拥有的计算资源来定制各个环境与生产环境的相似度,这个部署流水线不再是一个需要由开发团队来实现的概念模型。部署流水线可以是标准的、一致的,开发团队只需要定义自己这个软件的生产环境即可。

《持续交付》中提倡整个部署流水线“只生成一次二进制包”,并且在各个验证步骤之间传递二进制包。只生成一次二进制包的实践是非常必要的,因为“出于审计的目的,确保从二进制包的创建到发布之间不会因失误或恶意攻击而引入任何变化是非常关键的”。但实际的项目中经常出现二进制包非常庞大、在各个步骤(及各个环境)之间传递二进制包很费时的情况,这也是导致一些项目最终仍然退回到每个步骤重新构建二进制包的原因:增量的编译和构建可能比通过网络传递整个二进制包还省时。

如果构建的产物是容器镜像,所有运行时环境都从云上获得,那么实际上不存在传递二进制包的过程。每个验证步骤都用指定版本的容器镜像搭配对应的配置,启动一个新的运行时环境后,在云上的运行时环境中执行(自动的或手工的)验证即可。

持续集成

尽管《持续交付》说“选择并安装好持续集成工具之后,只要再花几分钟的时间配置一下就可以工作了”,但实际上很少有哪个项目的持续集成实施会如此顺利。例如当“发现在运行持续集成工具的机器上缺少一些必需的软件和设置”时,《持续交付》提出的建议是“将接下来你所做的工作全部记录下来,并放在自己项目的知识共享库中……并将重建全新环境的整个活动变成一个自动化的过程”。实际上,这是一件需要高度技能水平和纪律性的事,拥有这两者的技术领导者(Tech Lead)很罕见,希望每个开发团队都有这样一名技术领导者坐镇是个奢侈的梦想。

而且,持续集成环境与开发环境仍然是有区别的,这个区别很可能是由于计算资源的限制。《持续交付》中说,“你可以很有把握地说:‘只要是在与持续集成一模一样的环境上,我的软件就可以工作。’”。然而问题就在于大多数情况下,开发环境与持续集成环境不是一模一样。这也是为什么持续集成必须集中式地进行,需要有“铃声和口哨”来及时发现构建失败,并且“要让持续集成能够发挥作用……整个开发团队就必须有高度的纪律性”。

在充分利用云计算的情况下,开发一类软件(例如“Java微服务”或“ReactNative移动应用”)所需的环境和部署流水线可以由少数几名优秀的技术领导者来标准化,开发团队不需要再操心如何配置一个持续集成环境的问题。

并且正如《持续集成将死》一文中所说,云的弹性能够使每个人、每次构建都使用标准的类生产环境,因此持续集成没有必要发生在一个中心化的“持续集成工具”上。由于持续集成的“集成”这个动作在代码进入团队代码库之前发生,很多的提醒和纪律变得不必要了:构建失败就不能提交代码,于是确保构建成功成了每个开发人员自己的事,不能把不成功的构建扔给团队去处理。


更多精彩洞见,请关注微信公众号:思特沃克

Share