数字化企业敏捷建模

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动高于流程和工具

工作的软件高于详尽的文档

客户合作高于合同谈判

响应变化高于遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

—— 《敏捷宣言》摘抄

作为 DDDChina 的发起者之一，看着越来越多的技术人员加入到领域驱动设计（Domain Driven Design，DDD）社区，分享经验、总结实践、甚至于辩论观点，确实十分高兴。然而，担忧的仍然是并未看到很多非技术人员参与其中，当初力推 DDD 的目的仿佛渐行渐远 —— 我们一直认为 DDD 是促进业务和技术在系统架构上逐步达成共同认知的一种好方法。只有共同认知才能共同演进，才有能够避免一次又一次上演的遗留系统惨剧。

也许是疫情给了更多独立思考的时间，没有能够吸引更多的非技术专业人员加入，应该说并非是我们声音不够大，更重要是 DDD 所涉及的方法仅仅瞄准了整个企业架构建模过程的一个阶段，对于我们希望吸引的非技术群体，他们有着自己更需要参与并负责的阶段。

这促使我开始从整个企业的视角去考虑架构建模问题，目标也不仅仅局限于让系统架构能够跟随业务需求的变化而持续演进。面对这个数字化时代，企业的数字化底座成为了核心基石，而这个底座的架构是高质量可持续发展的关键。我希望去解决当下很多人都已经看到的传统企业架构方法带来的问题，从不同的视角去尝试新的方法，找到破局之路。

从静态走向动态

“Be water, my friend.” - Bruce Lee（李小龙）

随着数字化进程的持续深化，企业越来越依赖于自身的信息化和数字化系统，甚至很多新兴业务的诞生就源自于技术的发展，比如现在大家习以为常的人脸识别认证方式，正是由于机器学习技术在近 5 年的快速突破才得以实现。

这样的依赖性一方面激励着企业在信息和数字化系统研发方面持续加大投入，另一方面也让系统的全局复杂度快速攀升。过去从企业内部运营视角出发形成的简单通用信息系统划分，如 ERP、CRM 等，已经完全不能满足数字化时代企业的需要了。于是我们也看到阿里这样的互联网巨头提出了业务强绑定的“中台”系统概念。

移动互联给我们展现了数字化业务的潜力，而未来的元宇宙、Web3.0 将有可能带来更多的创新、甚至颠覆性的业务。由此企业所依托的信息化和数字化系统必然会要求很大程度上的“定制化”，这也让针对全局设计的企业架构（Enterprise Architecture，EA）工作变得越来越重要。

然而，已有的企业架构方法，如 TOGAF 和 Zachman，更多关注的是企业架构治理的流程和参考内容模型，希望从一个抽象层面指导企业产出适合于当前业务的企业架构全局视图。为了驾驭日益复杂的业务场景，往往需要将设计和实施步骤越来越细化，从而能够调动不同的的专业细分人员来完成固定事项。

在企业实际应用过程中，这样的企业架构方法带来了两个比较显著的问题：

1. 产出的架构模型及组件划分更多是以确定性的“静态”视图呈现，每个阶段的产出往往是通过特定人群“翻译”上一个阶段模型而得出的，这样的工作模式有违软件需求的基本特征，即需求的澄清实际是通过可工作的软件交付来迭代完成的；

2. 对于未来业务的变化和创新“设计”不足，往往只能将感觉变化比较快的领域，如移动互联网应用，划到产出的架构模型之外，美其名曰“非模型”需求。

不少企业架构专家提出信息化系统在一些行业的主干业务上应该是比较清晰的，由此，类似 TOGAF 方法的“静态”产出应该是适合的。然而，我们需要看到，这样的假设实则非常危险：在通信行业，从 2G、3G 到 4G 的连续发展，给了大家类似的预期；然而 5G 的到来，很大程度上颠覆了过去十几年积累的系统模块划分，于是全球各大运营商纷纷开始高喊数字化转型，其中很大一部分工作就是要改变过去的信息化系统架构。

国内不少大型银行都在实施基于 Zachman 方法的企业架构，希望通过统一的业务模型和 IT 模型来驱动新一代信息化系统建设，从而能够支撑未来的数字化业务发展。然而即使如清算这样看似稳定的底座，真的就已经业务上明确了吗？数字货币和区块链技术应该说才刚刚崭露头角，未来的具体影响还不得而知。我们更应该尊重这个科技时代的客观规律，不能一边高喊着“主动求变”，一边却在为系统的演进设定“确定性”的障碍。这样一时的大力而为，埋下的是未来的诸多隐患，苦的是为了业务连续性而需要持续开发和维护系统的研发团队。

由此，我们希望用动态的“建模”，来替代大家习以为常静态的“架构”。我们希望推动一系列针对企业价值定位的、可持续的、可落地的建模活动，来促进整个企业的系统体系得以持续的演进，从而能够通过持续提升组织的整体架构认知，完成对业务发展的支撑和创新的使能。

（数字化企业敏捷建模方法高阶视图：三个建模过程域+ 两个运营闭环）

针对软件开发本质去建模

“[...in interaction diagrams], comprehensiveness is the enemy of comprehensibility.”

― Martin Fowler（老马）, “UML Distilled: A Brief Guide to the Standard Object Modeling Language”

软件带来的新产品形态在这个数字化时代被越来越多的人认知。作为程序员，我们曾经很难向业务同事解释为什么之前加一个按钮一天完成，现在加一个类似按钮需要三天。而现在大家都知道软件从第一行代码开始就是会被持续修改的，是否易于修改成为了开发效率的基础。真正的难点是如何让软件在面对未来源源不断新需求时，持续保持较低的修改成本。

这件事情对于一个单体软件已经是非常困难的事情，而在我们的企业架构上下文里，面对的是一个成百上千软件组成的系统，这件事情就更是难上加难。在这样的环境中，我们没有办法预测未来的需求，只能通过持续提升团队对于“好修改”的认知，并落实到大家的日常工作实践中来应对。显然，在过去的企业架构方法中，我们鲜有看到对软件这个本质属性的关注。更像是今朝有酒今朝醉，明日问题归别人的视而不见。

在总结这套方法的同时，很欣喜地发现在不同企业架构阶段的建模活动设计上，早有全球专家意识到了过去这些静态架构方法的危害。比如已经提出近 20 年的领域驱动设计（Domain Driven Design，DDD），目前在云原生的微服务时代被很多组织引入，作为系统和平台设计的方法，其精髓就在持续地构建广泛的、跨业务和技术层面的“统一语言”，减少翻译工作，从而能够让系统的架构随着业务的变化快速持续演进。

最近两年行业内从“逆康威定律”出发，转换了在服务组件和技术架构设计上的单一视角，从组织和团队划分出发，明确组件设计目标带来的对应团队特征的不同，并能够从持续发展的视角来设计团队的动态划分和演进。这种团队拓扑（Team Topologies）的思想，实际上已经为我们提供了在技术实现层面上的持续建模活动蓝本。

（团队拓扑 Team Topologies 知识图谱，来源于《高效能团队模式：支持软件快速交付的组织架构》一书作者总结。）

站在这些新思想和方法之上，让我们一起来定义针对数字化企业的建模方法：

● 我们认可业务和应用架构的重要性，但更重要的是持续价值建模，任何业务和应用架构只是实现预期商业价值的一种支撑；

● 我们认可系统和平台架构的重要性，但更重要的是持续领域建模，任何系统和平台架构只是应对复杂问题分治的一种结果；

● 我们认可服务和技术架构的重要性，但更重要的是持续组织建模，任何服务和技术架构只是高效实现组织划分的一种映射（康威定律）。

在以上的定义中，业务架构阶段指明确架构所需满足的业务目标的定义过程，由于越来越多的数字原生业务，技术和业务的高度融合造成不少企业直接采用应用的说法。系统架构阶段，或云时代越来越多的平台型架构，明确相关软件程序和数据的各方面设计原则及高阶架构。技术架构阶段，或服务化架构下，主要是明确技术实现框架、组件（服务）划分等落地细则。

随着市场和用户需求的持续变化，以上建模方法中的活动也应该持续迭代进行。更由于这些变化不可预期，我们更应该关注建模活动带来的相关人员和团队认知的提升，不同视角的架构视图是阶段性共识的可视化呈现。对于架构视图，我们推荐大家采用类似 C4（https://c4model.com/）这样的轻量级可视化工具，重要的是关键人群之间的沟通、论证和确认。

一言以蔽之，我们更关注产生企业架构的建模协作活动和实践工艺，而采用轻量级治理流程和过程文档。

我们认为这样的建模方法符合于《敏捷宣言》所倡导的工作方式，因为：

● 更强调人通过互动协作的认知提升，而不拘泥于每个活动的专业对口；

● 更强调建模工作的迭代演进，而不拘泥于追求某一个时刻的绝对明确；

● 更强调价值驱动，而不拘泥于现有业务的框架；

● 更强调持续响应变化，而不拘泥于繁琐的流程和文档。

任何方法都存在局限性，从数字化企业的视角，这套方法不包含两个重要方面：商业模式和组织文化。前者不能脱离各行业背景，在这个产业互联的时代，行业的重塑、整合、创造不断发生，着实很难抽象出相对能够广泛应用的方法。文化则是一个需要更多阅历的领域，就现在的个人经历来总结组织文化的方法，难免贻笑大方。

下文中我们将整体介绍这个敏捷建模方法框架的含义，三个建模过程和两大运营闭环的细节，将在后续的文章中进一步展开。

三个建模过程

从业务架构设计到最后的技术架构落地，我们抽象了三个高阶建模过程域，分别是：价值建模、领域建模和组织建模。通过这三大过程域帮助企业明确端到端的建模活动，从而能够高效组织不同角色协同完成整个企业架构的设计。

建模过程中应该遵循“共识大于正确性”的原则：企业架构每个阶段的产出是相关角色或团队协作过程中形成的共识，而不是某个专业角色或团队的单独交付物。在任何一个时间点，都应该坦诚认知的局限性，通过保持协作的开放性来兼收并蓄。

一、价值建模：面向商业成功

业务架构一直以来被认为是企业架构的起点，然而面对这个数字化时代，真正的起点应该是我们的客户/用户，这点已经成为了企业管理者们的普遍共识 —— 只有持续创造客户/用户价值，才能够实现企业的持续发展。

由此，我们认为针对客户/用户的价值建模是数字化企业的必然起点。企业需要针对自身的行业及客群定位，确定相关的价值模型，作为不同专业背景角色同事们共识的基础。在很多企业中，我们看到业务和技术的融合都被提升到了组织战略层面，但由于没有从价值建模出发，在实际的执行过程中没有建立起来统一语言，造成客观上难以融合的困局。

（招商银行采纳的价值三角模型，让组织能够围绕客户价值来行动。来源于 TWLive 2021 年分享：https://insights.thoughtworks.cn/cmb-value-driven-lean-transformation/）

我们也要正视数字化技术带来越来越多元化的价值创造可能性，一家企业可能同时经营非常不同的业务模式，比如不少互联网 2C 服务起家的企业希望抓住下一波企业 2B 服务的浪潮，这样的场景下，应该有针对性的不同价值模型。而不应该由于是一家企业，所以就强制性只能有一套价值模型或一套企业架构。驾驭这种多元化是数字化企业未来的核心竞争力。

（某金融机构建立的价值模型示例。）

在共识的价值模型下，首先还是需要从产品/服务组合的视角去明确优先级，切忌搞大而全，时刻保持对变化的敬畏心。敏捷宣言签署者之一的 Jim Highsmith 老先生为此提供了一套比较完整的方法框架 EDGE，在《EDGE：价值驱动的数字化转型》一书中有比较完整的介绍。其中的关键实践精益价值树（Lean Value Tree，LVT）在亢江妹老师的《轻量级规划实践方法——精益价值树》也有了具体的介绍。

明确了企业级的价值定位，产出业务架构的方法和实践已经有不少的积累。比如服务设计（Service Design）方法，从关键的用户旅程切入，通过端到端的用户场景来明确用户触点及前后台的支撑系统。

（服务设计方法下的用户场景化梳理，从用户行为出发，明确能力支撑及前、后台的业务服务设计。）

具体推荐的方法和实践我们将在后续专门的系列文章中展开。这里值得提醒企业的管理者们：价值建模是业技融合的起点，也是一个组织是否真正践行客户为中心的标志。希望大家时刻不忘“客户价值”这个数字化时代的北极星指标！

在一些相对信息化积累比较好的行业，如银行业，也可以采用类似付晓岩老师在《企业级业务架构设计：方法论与实践》一书中介绍的工序比较明确的方法。但仍然需要注意定期审视用户价值随着市场变化而发生的迁移。

二、领域建模：面向统一语言

软件行业几十年的积淀形成了一个共识原则：关注点分离（Separation of concerns，SOC）—— 在复杂场景中，把不同的关注点分离开来，分别处理，以应对复杂性。这个原则最早由图灵奖获得者，荷兰计算机科学家埃格斯·迪克斯特拉（Edsger W. Dijkstra）在上世纪 70 年代提出，而后成为了我们在计算机建模领域及系统设计领域的底层范式。

我们时下的系统和平台架构某种意义上是其支撑的复杂业务的一种映射，所以我们在这个阶段处理的问题是比产生业务架构更为挑战的。在此基础上，需要再次提醒大家对于变化的预期，即使当下再完美的业务架构也会在未来某个时刻变得不合时宜的，所以系统和平台架构必然需要考虑面向未来持续修改的灵活性。

这是一个很难解决的命题，要求更深层次的业务和技术人员的融合，背后是我们需要在企业里建立一套业务和技术人员都能够理解的“普通话”。2003 年提出的领域驱动设计（Domain Driven Design，DDD）无疑给我们提供了统一语言的落地思路。很多人认为 2015 年开始流行的微服务带火了 DDD，但实际上是由于越来越多的企业感受到了在系统架构这个层面日益膨胀的复杂度，同时之前依靠外部购买系统套件搭建起来的信息化系统开始成为新数字化业务发展的障碍。

（DDD 思路下的具体方法，类似事件风暴 Event Storming，实质上就是在促进业务和技术人员统一语言的建立。）

2017 年为了在国内更好的介绍 DDD 的思路，我也写下来《DDD战略篇：架构设计的响应力》、《DDD战术篇：领域模型的应用》、《DDD实战篇：分层架构的代码结构》三篇。这里就不再赘述，相信很多的国内研发组织已经有实战经验。

在这个领域建模阶段，我们仍然还有很长的路要走。走访不少采用了 DDD 的企业会发现大多数都是技术人员在关注 DDD 战术层面的模型应用，讨论最多的是具体的模型如何映射到分层的架构实现。很多企业的研发团队对于和业务建立统一语言这件事情感到失望，甚至于从思想上放弃了这方面的努力。

我认为企业架构这个话题在近两年的崛起，是我们解决业务人员加入系统和平台设计阶段的契机。在这个领域建模的过程中，我们需要注意以下两点：

1. 建立业务和技术都能够理解的简单语言体系。在这一点上事件风暴 Event Storming 方法给我们呈现了一个简单有效的实例。当然由于各企业所经营业务的多元化，我们还需要更多的方法和实践。

2. 划分领域时综合考虑业务和技术的不同约束条件。争论领域到底是业务的、还是技术的是毫无意义的，我们产出的系统或平台领域划分是综合考虑企业经营情况的结果，这里面既有我们对业务相关性的考虑，也有我们对于底层运算平台特性的利用。

基于以上两点，我们认为一个良好的领域建模过程首先要让大家明确使用的语言体系，即不论是业务还是技术，都需要学会普通话。然后是一套行之有效的协作流程和实践，能够保证大家在正向约束的条件下进行领域建模，产出系统和平台架构。

最后，在这个阶段不少组织存在对于产出物的纠结。业务侧认为需要看到具体的 UI 才踏实，技术侧觉得没有代码框架都是虚幻。我们并不否定一些界面视图或技术原型可能在确认共识方面的必要性，但重要的是达成共识的协作过程。即使这些细节的文档材料对于不同的个体来说也是有不同理解的，而过于细节的材料反而容易造成未参与研讨过程的文档读者迷失在不必要的细节关注里。

三、组织建模：面向团队演进

长久以来，在具体的软件架构上，我们更多还是从技术范式和框架的视角在设计，从简单的 MVC 架构 web 应用，到时下 SaaS、PaaS、IaaS 的分层模型。被忽略的一个客观事实是：软件开发仍然是强依赖于人的行业，流程、架构和工具某种意义上都必须围绕如何让软件开发个体和团队更高效作为出发点。

在软件行业里，我们也逐步形成了对于康威定律的共识—— 组织形态决定产品形态。

Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

- Melvin Conway (1967)

简要翻译：组织设计的产品/服务等价于这个组织的沟通结构。这个定律对于持续变化的市场和客户需求来说是非常不利的，即我们目前的组织结构会随着未来的变化而变得不合时宜。这种不合时宜会反映出组织交付的产品和服务不能够满足市场和客户的需求。

在这个时代，运营超过三年的研发组织或多或少都经历了这样的痛苦，很多的“遗留系统”实际上就是这样产生的。这背后的核心原因是我们的组织结构并没有随着外界的变化而变化，大家过多地期望仅仅是从技术的角度去调整架构，让各个组件更为灵活，但却忽略了组织结构才是长期的制约因素。每次识别出的技术架构问题，往往在最后落地时没有了组织支撑，成为了空中楼阁。

由此，我们希望直接从组织结构视角去建模，通过组织的划分及交流沟通结构的确立来表达对应的服务和技术架构。从这个视角出发，团队拓扑 Team Topologies 已经给我们提供了非常好的方法，弥补了过去我们在组织视角的两大盲点：

1. 组织内部团队的划分没有明确的目的驱动。针对技术本身的复杂度，组织划分成小团队是一种常态，这不仅仅是开发效率上的考量，也是出于不同目的性的考虑。比如在功能开发团队之上，我们往往会有跨功能的平台团队存在，解决一些共性的能力封装问题；

2. 团队和团队之间的沟通互动没有明确的设计。多个团队的协同问题在各个研发组织里十分普遍，经常有不同的角色抱怨“会多”。大家并没有刻意去规划团队和团队之间合理的互动模式，在具体协作过程中自然也无法明确哪些会议是合理的，哪些是由于某个团队工作不到位造成的。

（团队拓扑方法下的组织结构和交互模式示例：Team Topologies at PureGym）

通过团队拓扑来完成组织建模对于我们“逆康威定律”的帮助是巨大的，业务和系统架构的变化直接就会映射到团队结构的变化上，而团队的变化自然会驱动技术架构的改变。当一个简单 MVC 架构的 web 应用随着市场拓展而越来越复杂的时候，这种变化展现在组织建模上很可能的结果是前、后端团队的分离，这种团队的分离自然而然牵引了架构上的前后端分离。

值得一提的是，在云原生和微服务为主导的技术架构时代，大家更容易忽视组织结构的问题。由于单个微服务对比传统架构的代码量少很多，对应的开发团队自然小很多，无形中给了大家组织已经是灵活小团队的假象。然而，不能忽视的是业务的复杂度依旧，多个微服务的集群才能真正实现业务，小团队组织结构下可能增加我们的沟通互动成本，并且组织结构可能形成“静态小团队膨胀”，即当一个新需求出现时，团队不是去考虑是否应该改变现在的微服务，而是默认增加新服务。长此以往，微服务的个数越来越多，小团队之间的沟通越来越繁琐，开发的效率越来越低。所以考虑团队划分的演进是我们保持高效组织生态的必然。

两大运营闭环

面对持续的变化，我们拥抱敏捷的工作方式，由此也产生了在保证数字化业务持续经营的两大运营闭环，分别是：“顺时针”的市场驱动，和“逆时针”的创新驱动。

我们认为在企业架构中明确这样的持续运营闭环是保证大家采用“动态”视角来看待持续建模工作的关键。这正如任何成功的数字化产品和服务，上线面客仅仅是开端，真正的客户价值创造关键是后续的持续运营和迭代演进。这也是为什么我们在企业架构设计过程中，需要从“建模”活动视角来强调这种可持续性。

第一环：“顺时针”市场驱动科学应变

不论是业务架构还是最后落地的微服务，都是服务于我们在价值建模过程中认定的商业机会。根据企业经营的情况，初始的价值认定会得到验证，而根据验证结果我们就有必要进行业务架构、系统架构的调整，最终驱动技术落地上的迭代。

这样的市场驱动也适用于持续的新机会发现，包括一些新技术驱动下的业务可能性的探索。需要强调这并不意味着我们只有一套大而全的业务模型涵盖所有可能业务，相反由于这些新产品和服务的持续探索，一家企业很可能在这些新领域采用独立的、更为轻量级的架构模型，从而能够保持在投资上的灵活性。

（EDGE 框架中轻量级价值驱动的战略决策机制可作为市场驱动运营闭环的参考。）

在落实这样的运营闭环时，我们应该有相关的管理部门或赋能团队来保证闭环的持续运作，特别是在一些拥有上千人研发队伍的大型组织里。EDGE 里首次提出的“价值实现团队”（Value Realization Team，VRT）就可以做为一个很好的参考，帮助组织推动这个顺时针运营闭环的持续落地。

第二环：“逆时针”创新驱动主动求变

在这个充满挑战和机遇的市场环境下，创新正成为一家企业的生存必备能力，但大部分组织在如何有效进行创新上却存在很大困惑，更不要说建立支持持续创新的架构。

虽然商业创新很多时候可以从商业模式的打造上切入，很多企业的高管也在强化自身的战略投资能力。但不可否认让企业内部的团队，甚至个体，发挥自身的创新能力，已经成为一家企业是否建立数字化基因的基本衡量之一。

由此我们需要在建模活动中支持团队主动发起变化，不少的企业都在利用虚拟团队进行跨产品和服务的整合创新，而过去数年全球在学习型组织方面的研究，也为我们提供了基于实践社区 Community of Practice，CoP 的持续运营方式。CoP 围绕着一群有共同关注或热情的人，定期展开互动学习和创新尝试，比如基于自动化技术 RPA 的 CoP，或者人工智能方面的算法 CoP。这种机制的重要性在于保持团队对于市场和技术发展的开放性，通过持续多点尝试来主动发起改变。

（基于实践社区 CoP 的虚拟社区组织结构示意，通过 CoP 的机制建立持续学习和创新的组织基因。）

不少企业在激发自身产品和服务一线创新的组织机制上，采取了成立内部或联合外部的孵化器模式，允许来自于不同团队的员工自由组队，提出基于企业赛道或能力平台的创新想法，并提供必要的落地支撑。这种模式短期可能取得不错的效果，但需要持续推进长效机制的建立，避免成为赶时髦的昙花一现。

甄别借鉴，与时俱进

开篇对比了 TOGAF 和 Zachman 这样的经典企业架构方法，帮助大家明确我们为什么从“建模”的视角来切入现代数字化企业架构。但这些经典方法仍然是值得肯定的，它们的提出也是源自于一些先进企业之前数十年推进信息化工作的提炼和总结。

对于很多企业来说，信息化仍然是数字化的重要支撑，没有良好的信息化系统，数字化业务就无从谈起。从这点出发，我们需要对这些方法的思路和实践进行甄别和借鉴，比如 TOGAF 针对组织架构能力建立的框架 Architecture Capability Framework，就是比较好的帮助组织建立架构治理能力全局视野的可行方法。当然在一些领域，如架构变更管理 Architecture Change Management，和我们这里提出的敏捷建模，就是截然不同的思考。

（TOGAF v9,2 建立的知识库：https://www.opengroup.org/togaf）

很多研发组织在实践敏捷开发方法时经常会陷入一个“非标准化”误区，即认为敏捷开发都是提倡个人匠艺，团队层面则不存在什么约束。事实上敏捷开发方法面向的是规模化的软件工程，对比传统强流程管控的方法（如 CMMi），在轻量化流程的基础上，实质是增强了对于个人工艺纪律性方面的要求，比如经典的测试驱动开发 TDD，就要求开发者遵循先设计自动化验收测试、再进行功能实现编码的纪律。

同样的思路应用到企业架构设计上，我们认可一些主流方法在“流程和工具”方面的积累，我们希望从轻量化的视角去选择性采用。而我们的敏捷建模方法更关注的是协作和工艺上的实践，强调在企业架构设计中“人和互动”带来的组织级认知的持续提升。

改变的道路从来都是充满挑战的，在企业架构重要性日益凸显的数字化时代，我们希望通过这个敏捷建模方法 DEAM 的提炼，帮助更多的人意识到软件研发的本质，并能够更多从组织持续成长的动态视角来构建企业架构的能力，从而奠定数字化时代高质量可持续发展的核心组织支撑。

作者简介：

肖然，ThoughtWorks 中国区创新总经理及 ThoughtWorks 全球 Open ROADS 数字化转型社区咨询委员会成员。计算机算法博士研究生，著作及翻译有《代码管理核心技术及实践》、《人件》、《增强人类》等。

肖然作为大型企业数字化转型专家，10 多年来深耕大型 IT 组织精益治理，领导并参与了华为、中兴、招行、中行等诸多国内外客户的数字化转型项目，帮助金融、通讯、零售、物流等众多领域领先企业加速现代数字化业务转型。依托 ThoughtWorks 全球科技视野和本地化服务洞察，通过敏捷、设计思维、DevOps、数据驱动等一系列方法帮助企业拥抱技术带来的行业颠覆，实现企业内部无缝协作，充分运用先进技术快速识别并抓住新商机。

在科技快速迭代的今天，肖然希望从更广阔的跨行业视角审视新兴趋势，为各行业呈现数字化经济深刻洞见。肖然目前关注于科技驱动的产业生态未来，如开放银行(Open Banking)和 5G 等科技浪潮下各领域机遇和挑战。