DDD战略篇:架构设计的响应力

当敏捷宣言的17位签署者在2001年喊出“响应变化胜于遵循计划”这样的口号时,鲜有组织会真正把这句话当回事儿,甚至很多经验丰富的管理者会认为好的计划是成功的一半,遵循计划就是另外一半。然而在时下的第四次工业革命浪潮中,可能很多管理者已经不会简单满足于“响应”,而是选择主动发起变化了。不确定性管理成了这个时代的主旋律,企业的响应力成了成败的关键。

随着这种趋势的深入,架构设计这个技术管理领域也被推到了风暴边缘。“稳定”这个过去我们用来形容好系统的词语似乎已经失去原有的含义,很多人开始用“健壮”这个词语来形容好的系统。比如Netflix公司采用的Chaos Monkey机制随机主动关停线上服务而不会造成整个服务生态宕机的作法更多的是在测试系统的健壮性,保证不会因为某个局部的问题而造成全身瘫痪。

然而架构的健壮性却比较难于定义和测试,以至于很多时候咱们在架构设计上还是在追求稳定性。在一个典型的企业IT组织里,当你询问一位资深工程师架构设计时,往往会得到一张搭积木一样的“架构图”。

图的底层是各种数据存储(从经典的Oracle到大数据标配的Hadoop),图的中间是类似Kafka这样的消息管道和传统的ESB(消息总线),上层则是各种业务应用(包括各种Web应用和移动的APP)。

仿佛这是一个流行的“稳定”架构设计。

(示意:典型的IT系统架构图)

当询问这样的架构是否合理时,不少人会告诉你问题可大了:这不是云时代的服务化架构。原因是这个架构的大部分组件,如数据存储,都已经可以完全“托管”给云平台了。于是乎,很多企业架构师又开始寻找像过去ESB一样能够对接各种云平台的PaaS了,然后抱怨现在的PaaS没有当年的ESB“稳定”。

两个核心问题却很少被提及:

  1. 当年基于ESB集成的SOA服务化架构解耦出的组件不但没有提升效率,反而增加了系统后续修改的复杂度。
  2. 看似“以不变应万变”的架构并不能支撑多样化的业务需求,最后各个业务部门仍然有一套自己的IT系统,即便是画出来的架构图惊人的相似(多少次有人惊呼“这就是我们之前那个工作流系统~”)。

就这两个核心痛点,让我们一起来谈谈架构设计面临的挑战和应对方式。

什么是架构设计

由于软件设计是一个复杂度很高的活动,“通过组件化完成关注点分离从而降低局部复杂度”很早就成为了咱们这个行业的共识。前面提到的数据存储、消息管道等“模块”在某种意义上都是组件化的产物。这样的好处是在不同系统里遇到同样的功能需求时可以复用。在云服务崛起的今天,这样的组件以“服务”的形式更容易为我们所采用。

当然技术出身的架构师们在架构设计的时候或多或少都有一种“搭积木”的感觉。大家都非常关注Kafaka有哪些功能,K8S是不是比Mesos功能更全,以及Akka是不是稳定。就像走进一个家装公司,在选择了“套餐”之后有工程人员给你介绍地砖和木地板用哪个品牌更好。

回到咱们的第二个核心痛点,如果只是这样的搭积木,为什么咱们总是在面对新变化、新需求的时候发现需要新的组装方式或新的组件呢?这样的架构设计对比直接按照需求实现(不考虑架构)有什么优势呢?

这里我们应该回到架构设计的本质,即为什么我们要在代码实现前做设计。显然如果去掉设计这个过程,大家会说问题这么复杂,如何下手啊?所以设计首先是要解决问题的复杂度。于是有人做了一个架构,交给了一个团队去实现,很快发现实现的架构和设计完全是两张皮。当然原因很明确——缺少了交流和沟通,所以设计其次是要建立团队协作沟通的共识

假设我们产生了一个团队都达成共识的架构设计,大家都兢兢业业把设计变成了现实。一个长期困扰软件行业的问题出现了,需求总是在变化,无论预先设计如何“精确”,总是发现下一个坑就在不远处。相信很多技术人员都有这样的经历,结果往往是情况越来越糟糕,也就是我们常说的架构腐化了,最后大家不得不接受重写。这些经历让我们逐步明确了软件架构设计的实质是让系统能够更快地响应外界业务的变化,并且使得系统能够持续演进。在遇到变化时不需要从头开始,保证实现成本得到有效控制。

面向业务变化而架构

基于上面的架构设计定义,关键因素就是业务变化。显然这个时代的业务变化是很快的,甚至很多业务主动在变,不变则亡是很多行业目前的共识。变化速度给架构设计带来了很大挑战,一个移动APP可能需要在一周内上线,然而为了支撑这个移动APP的后台服务,平台发布窗口是每两个月一次。这样的不匹配在IT领域里是随处可见的现实,我们习惯性地认为后台天然就很重因此很慢,只可能在牺牲质量的情况下满足这样的速度。

然而事实上这样的健壮架构确实是存在的,看看身边现在无处不在的互联网,又有哪一个企业的架构比之复杂呢。互联网系统的组件是一个个网站,每个网站完成着自己的业务功能更新,从新闻发布到在线聊天。而各个站点又是紧密互联的,聊天网站可能把新闻网站拿到的信息实时推送给在线的用户。每个网站都是独立的小单元,面向互联网用户提供着一定的业务服务。好的网站也根据用户的反馈在不停升级和变化,但这样的变化并不影响用户使用其它的网站。

从互联网架构我们可以学到什么呢?从架构设计角度我认为以下三点是关键。

  1. 让我们的组件划分尽量靠近变化的原点,对于互联网来说就是用户和业务,这样的划分能够让我们将变化“隔离”在一定的范围(组件)内,从而帮助我们有效减少改变点。
  2. 组件之间能够互相调用,但彼此之间不应该有强依赖,即各自完成的业务是相对独立的,不会因为一方掉线而牵连另外一方,比如新闻网站挂掉了,聊天网站应该继续正常提供服务,可能提示用户暂时无法提供新闻信息而已。
  3. 组件在业务上是鼓励复用的,正是这样的复用才成就了今天的互联网,我们不会每个网站都去实现一个强大的搜索引擎。而被“复用”最多的网站显然会受到追捧,成为明星业务。当然架构上这样的网站必然是健壮的。

上面的三点毫无疑问都指向了业务,从业务出发、面向业务变化是我们现代架构设计成功的关键

架构设计的核心实质是保证面对业务变化时我们能够有足够快的响应能力。

这种响应力体现在新需求(变化)的实现速度上,也体现在我们组件的复用上,在实现过程中现有架构和代码变化点的数量也是技术人员能够切身体会到的。面对日新月异的数字化时代,组织的整体关注点都应该集中到变化的原点,即业务上,而架构应该服务于这种组织模式,让这样的模式落地变得自然。

对比之前的传统SOA架构,这个思路的变化是本质性的。类似工业总线(ESB)这样的组件化其实是面向技术的,希望通过技术平台的灵活性来解决业务变化的多样性。虽然短时间能够收到一定的成效,长期看必然把自身做成瓶颈,因为所有业务的变化最后都堆积到了这个技术组件来解决。这也回答了为什么实施了传统SOA架构的企业最后都发现响应速度其实并没有提升起来。

面向业务变化而架构就要求首先理解业务的核心问题,即有针对性地进行关注点分离来找到相对内聚的业务活动形成子问题域。子问题域内部是相对稳定的,即未来的变化频率不会很高,而子问题边界是很容易变化的,比如在一个物流系统中:计算货物从A地到B地的路径是相对固定的,计算包裹的体积及归类也是相对固定的,但根据包裹的体积优化路径却经常会根据业务条件而变化。

(子问题域的划分)

面对业务的变化也要求我们的架构必须是演进的,因为业务的变化点也会随着时间推移发生着变化。这意味着在一款较长生命周期的软件产品中,不会出现类似ESB这样的重型组件,相反的我们追求的是一些面向业务服务的轻量级组件,它们的持续演进也会造成老组件的合并,新组件的重新拆分。当然这也成了现代微服务架构成功的基础条件之一。

打造架构响应力的方法

如果认同了上述现代架构的真正意义,大家一定会问怎么才能打造这样的高响应力架构呢?

领域驱动设计方法DDD(Domain Driven Design)为我们提供了很好的切入点。这个2003年就总结出来的方法终于在10多年后重新走入了架构师的视野,而这一次大家已经意识到了这种方法在这个快速变化时代的重要性。DDD通过以下两个模式去有效解决了文章开始提到的两大痛点:

  1. 让团队中各个角色(从业务到开发测试)都能够采用统一的架构语言,从而避免组件划分过程中的边界错位。
  2. 让业务架构和系统架构形成绑定关系,从而建立针对业务变化的高响应力架构。

这两点是DDD的核心,也是为什么时下全球架构圈在进一步向DDD这个方向靠拢的原因。DDD明确了业务和系统架构上的绑定关系,并提供了一套元语言来帮助各个角色有效交流架构设计。

(DDD的基本方法)

在战略层面,DDD非常强调针对业务问题的分析和分解,通过识别核心问题域来降低分析的复杂度。在战术层面,DDD强调通过识别问题域里的不同业务上下文来进行面向业务需求的组件化。最后在实现层面利用成熟的技术模式屏蔽掉技术细节的复杂度。

在这里我们也希望通过第一届DDD China建立起一个架构设计人员的交流平台。期待更多的中国技术人员能够通过这个平台和世界一流架构大师们建立起沟通的渠道,不仅在战略层面,也在战术层面和所有人一起分享讨论关于DDD的一切。


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

Share

DDD & Microservices

Microservices(微服务架构)和DDD(领域驱动设计)是时下最炙手可热的两个技术词汇。在最近两年的咨询工作中总是会被不同的团队和角色询问,由此也促使我思考为什么这两个技术词汇被这么深入人心的绑定,它们之间的关系是什么呢?

服务于更高的业务响应力

首先从两个词汇的发明来看它们是没有因果关系的。DDD是Eric Evans于2003年出版的书名,同时也是这个架构设计方法名的起源。DDD的想法是让我们的软件实现和一个演进的架构模型保持一致,而这个演进的模型来自于我们的业务需求。这种演进式设计方法在当时看来还是比较挑战的,更为流行的解决架构设计复杂度的方法是分层:比如数据架构、服务架构、中间件架构等。MVC在互联网应用开发领域也基本成为了标配。

时间很快过了10年,Martin Fowler和ThoughtWorks英国架构师James Lewis坐下来一起分析了好几个能够持续演进的大型复杂系统,总结出了9大核心特质,然后用Microservices来定义了拥有这些特质的架构。之后由于Google、Netflix、Amazon等一系列明星企业都对号入座,Microservices开始风靡整个软件业。这时候很多人会问微服务架构是怎么设计出来的,业界人士会说DDD是一个好方法,其中也包括微服务定义者Martin Fowler,毕竟DDD原书的序是他给著的;)于是乎DDD开始在被定义10年后火了。

从我个人角度来看,如果真的需要找到因果关系的话,最根本的驱动力来自于科技时代对软件系统(数字化)响应力要求的不断提升,而系统的复杂度却随着业务的多元化而与日俱增。如何驾驭这样的高复杂度成了每个企业必须面对的挑战,以至于业界开始把这种模型总结为响应力企业Responsive Enterprise),而模型中总结的大部分原则都是为了更好的适应环境不确定性带来的高复杂度。

从业务视角分离复杂度

每个人能够认知的复杂度都是有限的,在面对高复杂度的时候我们会做关注点分离,这是一个最基本的哲学原则。显然在针对复杂业务场景进行建模时,我们也会应用此原则。这个时候去分离关注点一般可以从两个维度出发:

  • 技术维度分离,类似MVC这样的分层思想是我们广泛接受的。
  • 业务维度分离,根据不同的业态划分系统,比如按售前、销售、售后划分。

以上两个维度没有孰优孰劣之分,在处理复杂问题的时候一定都会用上,但为了能够高效响应业务的变化,微服务的架构更强调业务维度的关注点分离来应对高复杂度。这是显著区别于传统SOA架构的特质之一,比如诞生于传统SOA时代的ESB(工业服务总线)就是一个典型的技术关注点分离出来的中间件。随着业务的变化,我们也看到ESB成为了一个架构上的反模式,即大量的业务规则和流程被封装在了ESB里,让ESB成为了不可驾驭的复杂度之源,以至于破坏了SOA架构之前承诺的各种优势。当然Microservices架构并非是新一代SOA架构这么简单,已经有不少文章在讨论这个话题,本文就不在展开了。

所以从本质上作为一种架构设计方法的DDD和作为一种架构风格的Microservices都是为着追求高响应力目标而从业务视角去分离复杂度的手段。

如果这个时代你还觉得自己的架构不需要这种响应力,我建议你问问身边维护3年以上系统的朋友或同事们,他们会告诉你这是怎样的一种痛苦。实际上很多企业对这种响应力的追求已经很“疯狂”了,这也是微服务的两位定义者可能都始料未及的。

他们在定义文章中带着很强警告语气让大家慎用,但在这个科技时代,微服务架构实施的可能风险对比高响应力在未来可能带来的市场机会几乎可以忽略不计。一个Netflix的成功就足以让大部分企业毫不犹豫的选择微服务作为自身的架构风格。

业务和技术渐进统一的架构设计

如果Microservices和DDD在目标上达成了上文的统一,那么在具体做法上和以前有什么不同呢?

为了解释清楚这个问题让我们极简化架构设计为以下三个层面工作:

  • 业务架构:根据业务需求设计业务模块及交互关系。
  • 系统架构:根据业务需求设计系统和子系统的模块。
  • 技术架构:根据业务需求决定采用的技术及框架。

显然这三者在具体一个架构设计活动中应该是有先后顺序的,但并非一定是孰先孰后,比如一个简单的web应用,很多人会说MVC是标配了(首先确定了系统架构),或者有人说用RoR快(首先确定了技术架构)。在给定的业务场景里,也许这样的顺序是合理的。

架构设计工作分层及传统意义上的负责人

这个时候咱们增加复杂业务需求快速市场变化这两个环境变量,这个顺序就变得很有意思了。于是我们听到不少走出初创期的互联网服务平台开始“重写”他们的系统(从PHP到Java),很多文章开始反思MVC带来的僵化(臃肿的展现层)。经历了这样变迁的架构师们都会感同身受的出来为DDD站台,其原因就是“跳过”(或“后补”)业务架构显然表明设计出来的架构关注点并不在业务的响应力上,因为业务的可能变化点并没有被分析出来指导系统和技术架构的设计。

DDD的核心诉求就是能够让业务架构和系统架构形成绑定关系,从而当我们去响应业务变化调整业务架构时,系统架构的改变是随之自发的。

这个变化的结果有两个:

  • 业务架构的梳理和系统架构的梳理是同步渐进的,其结果是划分出的业务上下文和系统模块结构是绑定的。
  • 技术架构是解耦的,可以根据划分出来的业务上下文的系统架构选择最合适的实现技术。

第一点显然也是我们产生微服务划分所必须遵循的,因为微服务追求的是业务层面的复用,所以设计出来的系统必须是跟业务一致的。第二点更是微服务架构的特质:“去中心化”的治理技术和数据管理。 作为架构设计的方法,DDD的各种实践,包括最近流行的Event Storming(事件风暴)实际上都是促进业务和系统架构梳理的渐进式认知。

在一次DDD工作坊中,一位同事给出了“你们连业务故事都讲不清楚,还有必要继续做架构设计吗?”这样的经典评论。而DDD的整个方法也没有涉及具体的技术架构实现,这个选型的权利很多时候被“下放”给了真正的开发团队。

值得一提的是采用DDD这种架构设计方法并不一定就产生Mircoservices这种架构风格,往往会推荐用大颗粒度的服务来包含业务分析过程中发现的不确定点,以避免拆分后变化过度频繁带来的双向修改成本。

跨职能协作的架构设计

业务和系统的渐进认知改变了很多之前的架构工作模式,在采用DDD的过程中,很容易感受到业务专家的重要性。而如果还有人寄希望让业务能够一次性给架构师讲清楚需求,那我建议抱有这样希望的同学去亲身参加一次自己不熟悉业务领域的架构设计讨论。你会很容易得出结论“原来业务也不懂他要什么”。当然业务人员听说要参加某种(软件)架构设计方法时心里也一定是抵触的。

DDD成功运用的基础就是创造让业务和系统这两种不同认知模型逐步统一的环境。

业务架构和系统架构设计

所以“不幸”的是如果你不能建立一个跨业务和技术的新型架构设计小组,你的DDD实践就没有成功的基础,继而采用微服务架构可能就会是一场灾难。幸运的是这种跨职能组织结构已经是前文中“采用”微服务架构企业(如Amazon)的标配,你不必再论证这件事情的可实施性。剩下的关键就是如何能够让不同背景的人们协作起来。这也是大家可以看到DDD领域的下一个热点,类似Event Storming这样的模式化协作工作坊会更多的出现在大家的视线里。

永无终止的DDD和演进的Microservices

DDD是容易上瘾的,当大家发现原来通过这个建模过程业务专家更了解服务划分(系统模块),架构设计更懂业务需求,这种协作会成为常态。在这个tech@core的时代,这样的融合将成为企业的核心竞争力。

当然刚开始采用DDD方法的时候,请不要认为每个系统搞一次所谓的DDD工作坊就能够找到最佳的服务划分了。业务的变化是持续的,而每次业务架构变化必然牵动系统架构的变化。良好的领域架构绑定了业务和系统,让双方人员能够用统一语言交流,这件事情建立不易,而持续运作更难。

成功的DDD方法运用是贯穿系统的整个生命周期的,这个过程中业务和技术的协作是持续发生的。

Microservices的最后一个特质:“演进式”设计 – 也明确了设计是一种持续的活动。DDD提供了一种符合这个微服务特质的工作方法,让演进能够落地。值得一提的是就笔者最近的经验,这个演进过程中最难认知到变化的就是DDD里最显而易见的“统一语言”。当大家形成了一个业务概念-“客户”后,少有团队能够持续审视这个“客户”是否随着市场的变化而发生了含义的变迁。

对比传统的SOA,微服务的拆分也是动态的,禚娴静在自己的文章中描述一个系统采用微服务架构历程中服务拆分的演变。这里不会有一个ESB来以不变应万变,这种幻想在过去的10年里已经被数次打脸。DDD的好处是让业务和技术人员都能够在合作中理解这种变化,而不至于陷入业务人员抱怨技术架构不知所谓,技术人员觉得业务人员朝三暮四的尴尬。

你需要成为那个高个子!

Martin Fowler在Microservies的定义文章中画了下面的图,评论“你必须有那个高度”来隐喻微服务实施的能力要求。就架构建模方面来说我认为DDD应该是一个团队必须去掌握的,包括这个团队的业务人员和产品设计人员。

微服务前置条件示意

很有意思的是目前Service Design也是全球用户体验设计领域的一个热门话题,从用户视角出发去设计整个服务链条。比如时下热门的共享单车,一个成功的服务设计应该是从用户开始有用车需求触发到最后完成骑行缴费离开,而不仅仅是去设计一辆能够互联网解锁的自行车。

我们可以找到很多Service Deisgn和DDD在原则上的相似之处,比如用户中心和协同设计。借用上面的高个子说法:

在业务需求认知和跨职能协作方面你一定需要成为高个子!


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

Share

微服务化小团队集群的组织和管理

随着微服务架构风格的流行,组织内部不可避免的产生了许多小规模团队,原来一个几十上百人的产品团队被拆分成了类似Amazon这样的2 pizza(6~10人)小团队。组织结构上也由之前的层级化职能团队设置变成了扁平的小团队集群。每个做这样调整的企业都希望借助小团队的灵活性在这个科技时代跟上市场变化和创新的脚步。

(组织的两种基本模式示意)

当然这样的组织方式本身就带来了一系列的挑战,技术实践方面Martin Fowler已经通过微服务的定义文章做了很形象的叙述,还用了“你必须长这么高”(You must be this tall!)来比喻在技术实践方面所需做出的投入。

在组织管理方面,越来越多的挑战被识别出来,把“自组织”当做银弹来回答这样集群小团队组织和管理中的问题是行业里存在的一个不好趋势。在最近和Matin Fowler的讨论中,我们达成共识的一点是:与其说微服务是一种技术架构,还不如说是一种企业组织架构

希望通过本文与大家一起研讨这样服务化小团队集群的组织和管理方法。

组织原则:对齐业务

科技时代带来的最大变化就是对变化本身的认知。在上一个时代,变化被认为是高成本甚至有害的,大家总是希望能够尽量减少变化,或者能够循序渐进地变化;而现在我们会认为变化是必然的,是会给我们带来新的市场机会的,甚至是会引发颠覆式创新的。

由于这样的认知变化,企业必须具备相应的灵活性,而扁平的小团队集群组织结构被不少企业(例如Google和韩都衣舍)证明是提供这种灵活性的有效组织方式。很多企业争相效仿,但不少会发现并没有得到之前追求的灵活性,反而做事情更为复杂了,以前一个接口部门变成了现在的多个团队。

作为咨询顾问,这两年经常接触到不少人抱怨划分成小团队后需求的实现成本增加很多,以前简单的业务需求现在要分解到很多“服务”团队才能完成。有的团队觉得这是技术问题 – 架构设计前瞻性不够;有的团队觉得是管理问题 – 没有跨团队的协调机制。而我往往喜欢从组织入手,让团队从业务需求出发,分析为什么那么多“集成”。

熟悉康威定律的同学可能已经理解我的用意了,以上团队出现的问题核心症结在于团队的组织结构和市场业务没有对应关系,大量的服务集成等同于把市场需求“翻译”适配到已有的组织结构。这样的痛苦在过去职能组织结构的时候就广泛存在,而错误的“服务化”只是把这种痛苦转换成了小团队之间的集成。

所以微服务化组织结构的核心原则是: 小团队的组织结构应该和市场业务对齐,并跟随市场业务变化而改变

稍微实例化一下以上的原则,比如最近一个客户的电商团队,100人左右规模。开始时候划分成了10人上下的小团队,每个团队负责几个服务,其中有几个“重要”服务,如customer(客户)和catalog(目录)。在一段时间里,几乎所有的需求都要经过这两个服务,工作量很大,团队实际上也根本不是十几人,而是几十人。团队告诉我:撑过这段高峰期模型就稳定了,以后就可以真正“微服务化”了(很多同学可能都有同样的幻想~)。

我用领域驱动设计的思想很快指出,就现在业务需求驱动出来的大量集成已经可以明确这些“重要”服务的划分是有问题的,新增加电子产品(比如点卡)的customer和之前的电商customer已经有不同的含义了,电子产品要求客户提供对应电子平台的账号和授权。按照上面的原则,不应该继续去扩充已有的customer服务,而应该重新分析新的业务模式下是否应该有新的服务(其中也包含新的customer模型)。

(不同的customer概念)

以上的例子在很多走向服务化组织结构的企业里比比皆是,而遇到问题时大家更容易从看似明确的技术或管理手段入手。这里希望读到此文的各位在遇到这样的挑战时别忘了康威定律。 管理原则:适应不确定性

《大教堂与集市》这本书中对比了两种不同的组织架构模式,很多特质也能够类比到单体架构和微服务架构之上。当微服务架构落地形成生态时(如Google),好比一个繁荣的集市,中央管理固然重要,但各个经营摊位却自主在为客户提供着琳琅满目的商品和服务。

作为一个企业,不太可能完全容忍集市一样的市场化,当然也有企业如海尔,把这种市场化更大程度上地引入到了内部。假设刚刚从过去职能层级组织结构转换到扁平小团队集群结构,这个时候管理者最大挑战就是如何还能够获取过去一样的“全面”信息。管理者往往会告诉我他们感觉到随时可能失控,因为每个团队都没有统一的开发方法和流程。

很不幸的是大多数从MBA课堂走出的企业管理者们都是管理“大教堂”建设的高手,却很难驾驭集市带来的“混乱”。然而我们的管理者们又都渴望着自己的企业能够有创新的环境。根据创新理论(Edge of Chaos),集市混乱产生创新的可能要远大于大教堂的整齐划一。那么在这个你不创新就被别人创新颠覆的时代,管理者就必须正视这个挑战。

管理的原则应该改变为: 放弃对掌控全局的虚幻追求,拥抱不确定性带来的挑战和机遇

同样实例化一下上面的原则,一个300多人的大产品经理与我谈他的困惑,自从转型成为扁平小团队结构后,他的会议比之前多了N倍,基本每天正常工作时间全部在开会。自己的产品方向和运营只能靠夜深人静的时候加班。他告诉我如果这就是所谓小团队要付出的代价,那么他觉得这事儿没法持久。

我首先肯定了他的观点,即如果作为产品经理都没有时间看产品方向和运营,那么模式上肯定是错了。进而询问最占用他时间的会议需要他做什么?很有意思的是他的答案是“我需要知道xxx信息才能保证计划的拉通”、“开会已经同步各个小团队最高效的方式了”… 这里表达出来的行为全部是希望掌控全局的急迫,和他嘴巴里说出的赋权团队、打造自组织文化大相径庭,当然知行合一本身就是困难的。于是我们花了很多时间来讨论为什么一定要有拉通的计划、为什么要中央同步各个小团队 … 这位管理者最后带着更多的困惑离开了那次讨论。

对比组织结构的调整,管理者思想和方法的转型确实任重道远。我往往给出的建议是从小处着手,比如放弃给每人安排任务,让大家自己来选择;又比如在团队之间冲突时,放弃作为管理者的“拍板权”,让团队通过快速实验来验证哪种方式更好。另一位大师级同事Jim Highsmith在八年前就总结出了适应性领导力(Adaptive Leadership),十年后的今天仍是少有管理者能够真正践行。

合作原则:简化集成关系

微服务下小团队集群的结构不可避免的需要更多的团队合作。一个运作良好的微服务生态圈背后是一个紧密协作的小团队网络,而团队之间的合作就是这个网络里无形的手。合作很多时候是团队和团队在运营过程中实时发生的,并非是预先设定或中央控制的,这个时候如何高效合作就成了一个很大的挑战。

在共同满足业务需求的过程中,大多数的合作是由于实现过程中服务之间的集成关系产生的。如前面讨论组织结构时的案例,很多组织在转型后反而集成多了,造成交流沟通成本持续增高,最后不得不安装很多会议和流程来“协调”这样的合作。结果当然是响应力越来越差,小团队名存实亡。

在团队合作方面DDD(领域驱动设计)原书中提出的(业务)限界上下文(Bounded Context)的关联关系可以借鉴。服务划分强调从业务视角出发,限界上下文提供了很好的划分指导,即可以根据限界上下文来设计相关的服务边界。由于每个服务对应一个小团队,那么实际上我们就建立了团队之间集成关系的模式。Eric Evans用了一个子章节描述了不同的基于领域模型耦合方式的关系模式(248页14.4),并零散地叙述了几个模式的演进场景,很多读者可能都不会特别关注那个章节。然而在微服务开始落地实施的时候,这些模式就变得十分重要了,因为这些模式本身也是团队之间的合作模式。

(限界上下文关系模式要求矩阵)

Eric Evans通过上面的矩阵总结告诉我们集成是高成本的,要尽量避免集成。同样道理在咱们团队合作的过程中,原则也是简化集成关系。在微服务架构下,显然右上角的“大泥球”(Single Bounded Context)和“共享内核”(Shared Kernel)是不推荐的;“独立自主”(Separate Ways)这种完全松耦合的关系是值得我们考虑的,但大多数情况下小颗粒度的服务之间还是会被不同的业务需求串联起来。

很多刚转型的企业会出现不少的“用户/供应商”(Customer/Suppier Teams)模式,主要是团队之间关系还是由更高层的领导在指挥,作为一个演进的合作关系应该更进一步向“开放主机服务”(Open Host Service)模式推进。现代的服务多是以API的形式更为规范的对外提供接口,所以其实在团队沟通方面的成本并非比领导中央决策高多少。

随着API规范的更进一步发展(如采用RESTful架构),很多时候服务团队之间只用做简单的翻译或遵从提供者的模型即可,耦合程度进一步下降,这个时候左下角的另外两种模式“防护层”(Anticorpution Layer)和“跟随者”(Conformist)就更为常见了。显然这两种模式集成关系更为简单,合作过程中调用服务的团队是不需要知道提供方的内部模型细节的,当然这个时候团队之间的信任关系也应该是相当高的。

服务化转型小结

采用微服务架构后自然会产生小团队扁平化组织结构,我们应该意识到在组织、管理、合作的原则及思维观念上都应该发生转变,忽略任何一个方面最终都会造成转型的失败。

  • 在组织结构上,团队划分要面向业务能力,持续提供市场价值。
  • 在企业管理上,管理者要拥抱不确定性,持续提升管理适应力。
  • 在团队合作上,考虑跨团队领域模型的耦合,持续简化集成关系。

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

Share

也谈“精益”

精益对大家来说都不陌生了,无论是最开始提取的丰田制造原型,还是后面延伸出来的物流供应链管理,再到近两年颇为流行的精益创业(Lean Startup),都在不停刷新着“精益”这个概念。最近也不乏把精益当成“热词”来包装的各种理论,以至于很多客户建议我另外给“精益企业”取个名字。我一般都会礼貌回答说:看看精益房子(见下图)吧,我们并没有发明什么新东西。

(图片来源于Six Lean Sigma – Learn | Teach | Impact )

当然,精益房子所表达的架构其实还蛮复杂的,也不是一两篇文章可以论证的,日本和美国管理学界也没有达成完全的一致。很多人的疑惑是咱们好歹是21世纪的新兴产业,肯定跟上个世纪的汽车制造业有不同吧?还用精益思想合适吗?这里我来谈谈自己的理解,抛砖引玉。

精益思想为什么适合于咱们这个行业,在我看来有以下两点:

  1. 追求快速价值交付的小批量生产模式
  2. 追求极致卓越的匠艺文化

追求快速价值交付的小批量生产模式

“这个谁都知道”、“这不等于白说吗”、“这个太虚,来点干货吧” …

这些都是每次抛出这句时会收到的反馈。然后我反问,“能给我讲一下你最近交付的一个功能挣了多少钱吗?”一般这个时候对方会回避我真诚的目光,嘴巴上说着“我们的系统很复杂,一个功能太小了…”。那么我们再来看看各个岗位的绩效考核吧?开发了多少条需求和测试出了多少bug,横比环比增长了多少都是报告中的常客。这里的“价值”被定义为了每个角色、每个人的阶段输出,类似富士康流水线上生产一个iPhone零部件的工人,至于最后是iPhone 6还是7于这个工人其实并没有太大关系,反正这批订单200万台,本周得搞定,做的越多个人收入自然会更多。

上面的例子告诉我们,并不是所有的生产模式都是追求“小批量”的,富士康在生产模式上是成功的,甚至是行业标杆。而丰田制造当年形成精益的生产模式,其核心是追求对市场变化的响应力,即用户一旦变了口味想开SUV,我的轿车生产团队及流水线能够很快调整开始生产SUV,并且我能够通过这种能力快速验证SUV的市场是不是真的。在这样的生产模式下,较之每个员工的资源利用率及输出,我们更关心的是“需求”是否能够在团队快速流动产出最后的产品,应运而生的是对生产批次小规模化及人员跨职能的要求。持续交付(Continuous Delivery)显然是咱们这个行业对这小批量生产模式的总结。

当然不用论证的是科技行业的市场是持续变化的,具有不确定性,所以逻辑上这种生产方式应该是必须的,即使是所谓的后台核心系统,其需求也不得不跟着所谓的前台用户需求变。很多人会说这个很自然啊,咱们拆了User Story做迭代不都是这样吗?那么有多少次大家会说“这几个User Story关联很紧,客户都要,我一起开发(测试)了,效率高一些”、“上线走流程麻烦死了,咱们还是一个月上线一次吧”、“所有都是Must Have,砍不下去了,PM上去磕客户了” …

当然我们不否认有的时候这些意见表达的可能是正确的选择,但显然,坚守这样的生产方式就需要在这些时刻去思考是否大家真的都运用了精益思想来指导自己日常的生产工作。

这个时候可能会有大牛又跳出来拍一砖:”看吧,还是管理的人不懂精益!”

那么技术人员真的理解了“小批量”的含义吗?在你的内心深处有理解包括TDD这样的基础技术实践是在践行精益“小批量”的价值观吗?用测试来描述一个业务小场景,然后加以实现,这种小步前进的方式正是个人对精益思想的日常修炼!每个“小批次”业务场景实现后,都要严格重构,追求代码的极致简洁,这又是我们接下来谈的对”匠艺“的卓越追求。那么环顾四方、环顾行业,有多少工程师能够坚持TDD呢?当开发进度紧张成为压力的时候,有多少人是选择第一个放弃TDD,将“小批量”原则第一个放到裤兜里的呢?!

追求极致卓越的生产匠艺

回到富士康流水线上,一个杀马特造型的青年在熟练地完成着iPhone屏幕的组装,他下意识地拿着工具钳咯噔一下,熟练地把一个屏幕扣入了iPhone的背壳,时间不到10秒钟,然后他开始重复循环。他的眼神好像有点游离,嘴角不时露出微笑,脑子里在回忆着昨晚和兄弟们撸串时的高谈阔论。他到岗1个月,第一天就学会了这道工艺,除了有一次把屏幕扣反了,这一个月还没出过啥问题。最近谈恋爱花钱不少,他每天都工作10个小时,虽然辛苦但想到和女友的甜蜜时光还是觉得值。

上面对等的场景是一个蓬头的程序员,对象(OO)也搞了5年了,这次遇上了函数(FP)项目,于是“WTF”成了口头禅,有时候在pair时忍不住说了还得道歉。最近code review出来问题很多,功能是没问题了,但老是想着修改变量值。每天盯着屏幕的眼睛有几根血丝,脑子里不时闪过无数马匹从Monad身上压过去,都上项目一个月了,最近几个User Story还是被QA揪出不少问题。虽然“心”苦,这段时间还是觉得很充实的,回家地铁成了最好的思考地儿,有时候突然开悟,回家兴奋着也想来个session,当然结果一般都是家人2次元的眼神。每每这个时候都希望第二天快点开始,能够去把代码重构了,实践一把自己在地铁上的灵感。

上面的两个场景很普通,在这两个行业里可能比比皆是。经常我们会开玩笑说一个卖体力,一个卖脑力。但其实本质的不同是生产者采用的生产方式的不同:在流水线上的杀马特少年需要的是严格遵循制造工艺的每一道工序,通过不停的重复形成机体的记忆;而程序员需要的是认清自己认知的局限性,通过不停的学习形成更好的解决方案。好的流水线生产者能够通过认真练习、快速形成机体的记忆,使自己产出的效率和成功率都能够达到一个高水平。好的程序员能够通过刻意练习形成大脑的思维体系,从而能够持续提升自己面临新问题时的响应力。由于丰田当时的“特殊”市场环境,迫使其表面看是一个偏重于前者的流水线,但实际却走出了一条持续学习和提高的文化之路,收获了对市场需求变化的高响应力。

所以有人会说:“对嘛!管理层都想着用熟练工,所以没法有精益的文化了!”

咱们还是小处着手,刚才谈了TDD,现在谈谈pair。曾经作为一名PM,我也为两个人结对指着代码论道半天非常恼火,虽然内心万马奔腾,但对“匠艺”的认可还是阻止了我去拆散这对pair,毕竟我清楚两人确实是在讨论重构而非其它琐事。当然事实证明这对pair现在都是业界有名的敏捷和架构专家了,好歹也算是对我当年苦难的回报。

再次环顾四方、环顾行业,有多少工程师能够坚持pair,甚至code review?有多少人希望能够在功能已经实现的代码之上持续追求卓越,而不是想着我自己干实现快一点好交差。至少这么多年的咨询生涯所见者有限,令人惭愧的是code review成了咨询需要去说服团队的日常工作之一。如果都没有分享和交流,甚至是争论,又哪里来的真正意义上对极致卓越的追求呢?

小结

上面两点可能只是整个精益思想落地层面的两个具体方面,但就我个人的体会而言,要做到已经非常困难了!即使在ThoughtWorks这样对敏捷高度认可和实践的团队里,要坚持做也可谓是一件艰苦卓绝的事情。什么事情喊口号容易,持之以恒的一万小时是每个希望成为精益践行者必须经历的磨练。“着眼长远”这一精益的另一基本原则送给还在坚持的同学们。


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

Share

超越SAFE,创新需要EDGE

EDGE(边缘)和SAFE(安全)这两个短语在字面上给人的感觉是截然不同的。在没有具体上下文时,我相信大部分的人会选择“安全”,“边缘”总是给人摇摇欲坠的紧张感。然而人类的很多突破正源自于这些反直觉的思考,让大家能够踏出自己的舒适区。

在这个科技时代,人人都期待创新和颠覆,都希望自己成为引领时代的创新者或颠覆者。然而创新却又是那么琢磨不定,没有显然的规律可循。

我们无从预见人类未来的创新是什么形式的,但从历史的经验教训中,我们可以学会一个朴实的道理:作为企业的领导者,要想在科技时代引领自己的组织迎接时代的挑战,就需要让自己站在创新的边缘,而不是让自己和组织蜷缩在看似安全的舒适区里。

1-grave

今天的舒适区就是明天的“英雄冢”!

创新:混沌的边缘(Edge of Chaos)

这两年有很多关于创新理论(Theory of Innovation)的研究,大家都希望找到最适合创新发生的土壤。根据斯诺登教授(Dave Snowden@Cognitive Edge)的Cynefin框架对问题认知的分类(见下图),普遍理解这样的土壤存在于简单(Simple)和混沌(Chaotic)的边缘,是一个峭壁,驾驭不好可能就掉进混乱(Disorder)的深渊。

在认知理论中,大家往往首先考虑遇到的问题属性是复杂(Complex)还是繁杂(Complicated),目的也是为了降低陷入混乱的风险。但这种认知问题的通用模式并不代表着我们在考虑创新时应该远离那个峭壁去寻求SAFE之所。恰恰相反,不到EDGE边缘就不会取得创新和突破。

2-cynefin

Cynefin问题认知框架

很多创新,比如风靡一时的自拍杆,在今天看来是一个很简单的解决方案,但为什么在其发明之前很多人却没有想到,而是凑合着利用已有的定时快门功能呢?自拍杆的发明是否遵循了一定的流程呢?

如果我们仔细思考,会发现即使是这样的微创新也存在很大的“随机性”,即我们很难说遵循一定的流程就能产生某种创新。但当创新产生后,我们往往会觉得豁然开朗,某些问题的解决方案顿时变得简单了。这个例子应该能够让大家体会到“创新为什么存在于混沌的边缘”。

当自拍成为了一个主流需求,有人开始思考简单的定时快门是否是最佳的解决方案,很快有人会发现如果能够用竿子撑起手机就能够解决自拍时经常找不到地方放手机的问题,第一代自拍杆就这么诞生了!继而会有人发现定时设定还是挺麻烦的,于是利用蓝牙来触发快门的功能也就应运而生了。那么是不是现在的自拍杆就是最佳的解决方案了呢?不一定,谁知道小型无人机会不会是更方便的下一代“自拍杆”呢?能随时自动跟着你,自动侦测到你的各种姿态。

所以创新本身是一个非连续性的混沌问题,人类目前还不能流程化、批量化的去复制创新,如自拍杆的例子创新是持续演进、没有终点的。作为一个组织,我们应该做的就是培育并保持这样的土壤,容忍一定程度的混沌去孵化创新。

再举个简单的例子,实现一个业务需求的时候,我们很多管理者希望的是从接口到数据库字段都能够“完美”的预先定义,写好规范文档然后交给码农去堆代码实现,大家都按照说明书工作;而另外一种小众做法是管理者给程序开发团队明确业务价值及需要解决的业务问题,让开发团队自己去决定最佳实现方式。

显然第一种方式更安全,但团队却决然没有做出创新的可能;而按照第二种方式运作的团队往往会产生很多创意的设计。有人会质疑这样做的风险和回报是否成比例,毕竟没有谁能够保证在某一段时间里按照第二种做法来做的团队一定能产出创新。

但不要忘记创新的本质是颠覆性的,伴随着科技的进步,试错成本持续下降,不能够驾驭创新带来的不确定性就只能坐等被别人的创新所颠覆,这是本世纪对组织管理者提出的最大挑战:

让组织既有足够的混沌来孵化创新,又能保持足够的简单来稳定基本的秩序。

结果胜于输出(Outcome over Output)

下面是我们经常会见到的两个典型场景:

  • 场景一:“通过团队这段时间艰苦卓绝的奋斗,我们成功达成了不可完成的使命,交付了100个功能点,交付效率提升了50%!”
  • 场景二:“我们上线了部分设计的用户体验,得到的反馈不是特别理想,好评度只有10%,我们准备重新定位用户群体。”

在大多数企业里,我相信第一个场景在各级汇报材料中比比皆是,第二个场景可能出现后就要被问责,大家会下意识的认为做产品设计的同学不负责任,而第一个场景下的团队最差也是“没有功劳也有苦劳”。这里的“苦劳”就是(努力的)输出,“功劳”就是(有价值的)结果,所以这句俗话就成了:没有(有价值的)结果也有(努力的)输出,等于“输出胜于结果”。这样的设置对既有组织机构下的每个人来说都是SAFE的。

但上面推导出来的结论可能大家都觉得是不能接受的,花了功夫做没有价值的事情怎么能够说得过去呢?

回想一下你或者你团队的年度述职报告,上面难道不是充斥着和场景一类似的描述吗?很多人会说开始时我们也不清楚是否有价值,而且市场变化决定了没有人能够100%确定产品功能交付后价值就一定兑现。

甚至很少有团队能够在设计功能的时候做出价值的估算。我们这里说的价值并非是“X功能实现后每天会有Y人次使用”,而是“X功能实现后每天会为公司在Z工作上节省15%的劳动力投入”或者“X功能将带给已有客户群体额外15%的经济收益”,简言之,这样的价值才是我们说的结果。

很可怕的是即使在这个所谓的高科技时代,当我们走近不同企业和组织,仍然可以看到帕金森定律在起作用:大家都很忙,每天有做不完的事情,每件事情都有输出,来再多的人还是这样忙碌,但却看不到转化出来的经济收益。

如果每个人都把自己的工作输出当成最后的结果,那么这样的现象是不会有一丝丝缓解的,“部门墙”、“各种会”、“大企业病”等等也会接踵而至。时下很多企业说”我们一直在做精益”,然而却忘记了精益的本质是价值驱动、结果导向。

价值驱动的决策系统(Value Driven Decision)

相信组织里的每个人都不会反对价值驱动和结果导向,但实际工作中却是知易行难。我们先来分析一下几个主要原因:

问题一:结构僵化

每个组织都有自身的结构,画出一个树状图的清晰架构在上个世纪是很时髦的,画不出来说明缺乏管理。采用这样的管理哲学必然导致结构僵化,这在当代已经成为大家的共识。然而有意思的是很多企业反僵化的手段就是不停的组织变革,采用不同的“先进”管理框架,然后针对泊来的框架“先僵化再优化”。

于是有意思的事情发生了,企业结构从一个僵化转移到另一个僵化,开始一般大家都热情高涨,“我们要变化,要站在时代的边缘去!” 然后是瞬间一落千丈,感觉新框架新结构又搞出了一套新的官僚机制。

4-bureaucrat

反僵化不是让大家把组织结构从原来的树状图转义成三层结构图,而是让整个组织具备在混沌环境下的运作能力,学会去感知环境时代的变化,然后快速做出反馈。这就是自组织的核心实质,也是为什么每个现代管理框架都要提”去中心化”的原因。正确的决策(决定创新的命运)可能发生在任何一个层级。

问题二:缺乏授权

现在,企业的管理者们并不缺乏主动授权的意识,但缺乏如何有效授权的方法。很多管理者的困惑在于授出的“权”最后还是回到了自己手上,所有的决策还是由几个人拍板,授权带来的只是效率的牺牲。

问题的症结在授权的方式上,很多管理者觉得给了“权”就要把“责”一并转嫁了,天下没有免费的午餐,所以如果授权张三可以决策产品是否发布,那么发布上线出了问题就要张三述职。这样看似公平的权责明确其实在“被授权者”看来更多是责任的转嫁,抵触心理可想而知。同时这样的授权方式下其实又创造了一个新的“中心”,根本没有促进自组织的形成。

举个典型的例子,很多团队的站会被我戏谑为“小组长汇报会”,所有人都向着小组长发言,甚至发言顺序都是小组长点名。每遇到这样的情况我都会首先“禁言”小组长,然后站会就混乱了,大家着急了,有意思的是也只有这个时候大家才开始思考共同的纪律应该是什么了!

这就是自组织的发生,即使在这么小的集体活动中也能体现出来。所以授权就是要让团队能够自发去找到决策机制,信任团队的协作,容忍站在外部看内部的混沌。

问题三:目标割裂

平衡积分卡这样的机制,在企业战略实施过程中应该已经是标准套件了,看似科学的分层分解机制从企业战略一直分解到执行层面的战术,很多企业的战略地图挂起来真的能让人欢心鼓舞好一阵子。但大部分企业实际的情况就是分解清楚了,图画漂亮了,仅此而已。

5-kanban

各级管理者抱怨下级执行层面不给力,年初的战略只有年底绩效考评的时候才会拿出来对标,当然往往都还是能“对上”。就这样年复一年消磨,直到颠覆者出现了,企业在抱怨声中衰落甚至解体。

战略目标分解有错吗?答案是没错,但错在分解的方式上!企业的战略目标被一次性分解到了各个部门各个团队,假设这些部门和团队都是努力负责、能力强的,都能达成自己的小目标,那为什么企业的战略目标往往成了空中楼阁呢?

这里大家忘记了不确定性,在我们制定战略的时候是无法排除接下来执行过程中的不确定性的,而这些不确定性意味着我们需要在执行的过程中不停调整,上面的分解方式显然是不支持这样的调整的,各个部门和团队领到了各自的小目标,越努力可能离企业真正希望获得的收益就越远,这里缺乏的就是响应变化的机制。

那么怎么才能建立响应变化的机制呢?答案其实很简单,抗击不确定性的法宝就是建立短周期的反馈闭环,要短周期就要求目标“小而精”。所以分解的方式不是按照企业现有的组织架构去“解码”,而是应该定义出战略目标下的MVP。

针对上面三大问题,ThoughtWorks抽象了一个决策系统(见下图)。这个系统首先是一个闭环,能够持续提供反馈并修正方向。在此基础上建立起来对愿景(Vison)和目标(Goal)的分解机制,并充分认识到每个机会点(Bet)的不确定性,通过尽量小的尝试(Thin Slice)来不断调整投资组合,保证对外界变化的快速响应。

7-edge

EDGE决策系统

精益的生态圈(Lean Ecosystem)

“大型企业如何进行大规模组织级创新”是一个世界范围的热议话题,如果说在一个小团队构建并维持一定的混沌来孕育创新是相对确定的,那么在一个千人万人的大型组织里怎么构建这样的混沌而不掉落到混乱状态就是一个非常不确定的问题。

目前来看,很多企业正在尝试着化整为零的小团队策略,希望通过这样的自组织小团队来平衡创新所需要的混沌和大组织治理所需要的简单。在此之上我们也看到了很多管理理论和框架的产生,都会用“规模化”来形容,其危险性在于从过去的职能部门僵化移步到新的小团队僵化,所以本质上并没有带来创新所需要的组织环境,每个小团队仍然可以SAFE的过日子。

更进一步看,规模化的方向不应该强调从三两个小团队运作到几十几百个小团队运作,而应该是企业各个职能部门的卷入,从扩大(Scale Up)变为扩广(Scale Out)。只有这样才能够在组织里真正意义的建立起创新的支撑环境。试想如果一个团队希望能够引入虚拟现实技术,而采购部门说设备没有事前预算等明年吧,在这样的环境下扩大是没有任何意义的。

近期的一些成功企业,如海尔和小米其实也在实践着这种扩广的精益生态圈打造,正如要做出一道创意的菜品首先需要各类调味品齐全一样,当一个企业形成了精益的生态圈、能够不停丰富自己的调味品种类时,某一时刻就会有新式的菜肴产生,同时生态圈意味着这种创新会持续自发产生,组织持续能够在创新的EDGE上跳舞,也只有这个时候创新才会成为常态。

8-edge

ThoughtWorks在科技时代精益企业背景下提出的“价值驱动决策”框架并用“EDGE”命名,主要针对如何在市场高速变化时保证投资有效性。针对EDGE的具体实践将在近期有系列的发布,敬请期待!

EDGE有6大主要的核心原则,见下图。

9-edge-frame

EDGE框架及核心原则


你想看到的洞见,都在这里

wechat

Share