郭东白的架构课_49_38能力维度三如何提升解决跨领域冲突的能力
你好，我是郭东白。
今天我们来讨论架构师核心能力的第三个层次，解决跨领域冲突。
上节课呢我们讲了程序员到兼职架构师的过渡，也就是怎么搭建解决横向问题的能力。
不过在这个角色上呢，架构能力是一个加分项，因为主要工作呢还是写代码实现需求。
那么我们今天要介绍的能力就不再是一个加分项了，而是作为架构师的主要争执。
这是架构师职业成长的又一个重要的能力跃迁。
在跨领域的架构师或者是全职架构师的角色中，代码产出不再是主要的价值所在，反倒变成了加分项。
这个角色的反差如此之大，以至于很多人虽然多年来顶着架构师这个头衔，但是从来没有完成这个角色的转变，为什么呢？我们先从跨领域架构师这个职能的缘起来分析一下。
我们先区分一下跨域架构师和兼职架构师这两个角色在概念上的差异。
我在文稿里放了一张实体关系图。
这张图表示，在软件企业或者企业的研发部门不同职能在软件架构这件事情上是怎么协作的？我这里特别要对跨域架构师和兼职架构师这两个角色做了拆分。
一个业务中也就是一个大公司的BU,或者是一个小公司。
其实呢会有多个产品线，每个产品线呢有各自对应的产品经理，一个产品经理也往往对应着一个或者是多个研发经理。
一般来说呢，每个研发经理在负责一个研发领域的同时，还会带领一个团队团队中有多名程序员。
每个程序员各自负责一个或者是多个软件模块。
跨域架构师和研发经理呢形成一对多的关系。
也就是说呢，跨域架构师和研发领域是一对多的关系，这就是为什么呢？我们把这个角色命名为跨领域，架构师也简称呢跨域架构师。
程序员和研发经理呢跟研发领域呢形成的是一对一的关系。
如果一个程序员和研发经理同时具备兼职架构师身份的话，那么这名兼职架构师就会和研发领域呢也形成一对一的关系。
这张图表示呢从兼职架构师成为跨越架构师，需要完成的呢，是从一对一关系到一对多关系的跨越。
或许你会问了，假设某个研发总监和兼职架构师有多个呢研发经理向他汇报，意味着他负责的领域也很多。
那么他在软件架构这个上下文里不也是一对多关系吗？这里呢有一个巨大的差异，虽然他也是兼职架构师，但是所有领域的需求分析过程、研发设计过程和研发团队都由他管理，并且呢可以直接干预。
也就是说呢，他对所有领域有直接的话语权。
在兼职架构师这个身份上呢，他还是在处理一对一的关系。
只不过呢他负责的大领域包含了多个独立词域，到这里呢我们就能找到跨域架构师这个角色的真正特殊性了。
跨域架构师对多个领域的软件架构直接负责，也只能通过各领域的软件研发者来间接影响自己所负责的领域架构。
你可以要问了，跟一个领域相比，多几个领域有什么了不起呢？请结合第三十六课中软件架构师的定义来思考这个问题。
软件架构师呢就是为相对复杂的业务定义，并且引导实施一个结构化软件方案的能力。
其中结构化代表这个软件在设计范围内的设计理念、代码结构实现方式上是同质的。
问题呢就在这里了。
假设你负责多个领域的软件架构，而每个领域都有对应的研发经理，甚至领域内呢还有对应的兼职架构师。
那么问题就来了，为什么这些领域的设计理念、代码结构和实现方式是处处一致的？现实世界里，这些领域的设计理念肯定不一致。
这些领域域各自各自的领领目目领领域挑战需求优先和和相对独立的工作环境。
要是一致反倒就不合理了。
现在你应该明白，跨域架构师的核心挑战了，现要抵抵天然的商增增多，多个子领域中不同的领计理代对结构和领先方式往同质的方向进行整合。
这个分析呢对由多个独立决策的团队构成的大型组织都是适用的这就意味着跨域架构师的存在是大型组织的需要。
也就是说，呢子领域的目标和挑战不同，因此各自设计的理念、代码结构和实现方式也存在不在不小的差异，进而破坏全局的结构性。
这种局部和整体的冲突，需要在全局层面优化解决。
因此，一个组织才需要跨域架构师对比一下兼职架构师。
这个角色呢只需要关注自己领域的或者自己模块的架构问题就行了。
解决的还是呢内部技术在的问题，比如说性能安全、可维护性之类的问题。
如果发现问题呢自己动手解决就行了，不需要化解多个团队之间的冲突思考。
这里呢你就接近跨域架构师和兼职架构师的本质性差异了。
跨域架构师的价值呢在于解决一个复杂组织中必然存在的局部和整体的冲突，最终呢要从全局层面寻找到最优解。
跨域架构师对这些领域呢没有管控权。
每个领域的大佬呢都有各自的理念和形式方法，不但互相之间有矛盾，甚至呢每个人都有自己的小算盘，这就是跨域架构师所面临的巨大的挑战。
想想你看啊，你从第一天写程序开始，你所有的成就感都来自自己的亲身实践，哪怕是解决横向问题，也完全靠自己查bug,做优化重构代码。
在成为跨域架构师之前，动手能力就完全定义了。
你如果你写代码比喻成武力的话，那你就是一个百分之一百靠武力生存的人。
但现在不一样了，外交能力突然间取代武力，变成你最需要的核心能力，哪怕代码写的再好，也不能把别人推开自己改代码。
你现在只能靠驱动他人来做正确的判断，才能让想法变成现实。
这样一来呢，在程序员和兼职架构师阶段，持续成功的那种崇尚武力的信念。
现在呢反倒变成你在跨域架构师角色上的最大障碍，有没有观察到这么的一个现象。
在大厂里呢那些工作多年的跨域架构师，他们口中经常有个词儿叫背锅。
有没有想过，为什么呢？我先给你模拟一个工作场景吧。
假设呢你是交易域的会域架构师，一周前呢刚刚接手这个汤山域。
背景呢是有三个独立的团队，分别负责交易资金和资支付领域的开发。
昨天公司出现了资金损失问题，直接的原因呢是交易团队调整了交易模式，并且通知了支付团队，支付团队完成了自己的改造。
支付成功后，支付模块呢通过调用资金的接口来做结算。
但是呢，资金团队呢没有收到交易模式调整的通知，所以呢，就没有做相应的账户配置变更，导致呢资金计算错误。
公司呢遭受了不少的损失。
故障追责的时候呢，三个团队互相加价，资金团队呢不承认问题是自己的，因为认为自己都没有发布做变更，凭什么承担这个责任？交易团队呢也认为问题跟自己没关系，因为他们不直接调用出现资损的代码，要怪也只能怪支付支付团队做变更的。
同时没有通知到资金团队，支付团队呢同样不认账，支付代码没问题。
问题根因呢也和支付没关系，毕竟项目是交易团队发起的，你金团队沟通不到位，那也是交易团队的问题。
这样怪来怪去谁都不担故障。
同时呢讨论中还有人提起架构师，也有责任。
前任架构师没规划没规划好，他们交接不畅导致沟通不到位，你有更大的责任。
那么这个资损的故障呢肯定由你来担责任。
言外之下呢就是让架构师来背锅。
当然呢你也可以选择不背锅，那你就要以中立方的身份来建议由哪个团队来背锅。
我仔细想想，哪个团队都得罪不起，最后只好认命，自己来背这个锅，类似的场景也就不免会再次发生了。
想想看，如果一个有结解决跨领域冲突的跨域架构师会怎么处理这个问题呢？我们先暂时抛开具体的问题，先来分析一下跨领域问题的本质。
我们可以从这四个角度来分析一下。
第先呢是决域割裂。
一个本来属于一个大领域的交易支付和资金被分割成多个子领域。
各个子域呢都有独立的团队数据模型和实体状态，而这些子域之间互相影响，各个子域之间的数据和状态之间有一定的关系。
所以子子域之间呢就需要同步变更，才能保障整个大域处于一个自洽的状态中。
第二呢是决策割裂。
每个领子域呢都有各自的决策者，没有一个能够为三个子域做统一决策的人。
首先呢是执行割裂，每个子域呢都有各自独立执行，缺乏执行过程中的同步。
最后呢是沟通割裂，每个子域内部的沟通都没办法全部同步给其他的子域。
我在文稿中放了的图，展示了刚才描述的跨领域问题。
我来讲解一下这张图。
这张图里呢左侧的大图的三个虚线圆圈代表了三个领域的实际关系。
在理想状态下呢，这三个子域呢应该只有一个决策者和一个执行团队。
决策者呢能够感知到每个子域的状态变化，同时呢还能指挥执行者的协调。
执行各个领域之间呢也不存在沟通障碍。
因为他们同属于一个决策者和一个执行团队。
右侧呢有三个实现圆圈，代表着三个子域完全切割之后的状态。
这三个领域本来应该跟左侧圆圈一样，是互相关联的。
但这时候呢每个领域独立决策，并且独立执行内部的信息和状态变化也对外不可见。
所以呢跨域架构师只能在三个子域之外干着急。
如果你是这个跨域架构师，该怎么突破这个困境呢？答案呢是以全局视角做架构干预，我们来详细分析一下这个问题。
换个角度思考呢，背锅呢其实也是跨域架构师这个岗位价值的另外一种体现方式。
你应该理解左边的团队布局相比的话，呃，右边的团队布局的是有它的优势的。
因为右边的团队更大，每个子域呢能够专业的更深，执行的更快。
公司呢成长到一定的体量呢，这么做呢是必然。
每个独立的子域呢不可能每天都和其他的子域做信息同步。
每个的区域的决策者呢也要自己的决策自由度，这样呢才能快速迭代，子域的分化呢也能做的更彻底。
每这个子域的目标挑战和需求不同，所以执行上呢也不可能一致。
也就是说呢，前面提到的领域决策、执行和沟通的割裂是为最大化子域增速而必然付出的代价。
也就是说呢背过这种呢只是一个必然代价的一个体现方式。
既然是一个必然代价呢，那你作为一个架构师的增值也就很清晰了。
你的存在呢其实是为其域之重，重新建设、决策、执行、沟通的桥梁，让三个子域组成的整体比在割裂状态下更高效。
同样呢，我在文稿里放了一张图，描述了这个关系。
我也再讲一下这张图，在这张图里面呢，我们把每个子域的边界改成虚线，并且在子域之间建设了决策信息和状态浏转的通道。
那么跨域架构师呢就是在其中协调子域的决策和执行，让新的沟通结构和图中上图中右侧的沟通结构更加接近。
沟通机制呢，其实我们日常就有微信群、邮件组VIKIY、会议架构会等等，都是比较有效的办法。
我们在模块二中介绍的架构环境搭建的方法，在这里呢同样也适用到这里呢。
我来总结一下一个跨域架构时的存在，这这保调整域之间的决策执行和沟通，从而平衡全局结构化和全局部个性化之间的冲突，最大化全局目标的实现。
你可能会会问了，他们间间互相全局交交流，那留我这个架构师干什么？是不是我要面临兔子狗喷的命运呢？不会的，你的技术能力依然是制胜法宝。
你需要判断什么信息和状态，必须在子域之间流转，就些信息要维持在什么样的颗粒度和频次，才能保障在整个大域状态自下的同时最大化。
每个子域的独立迭代速度，就像我们在模块二里给出的答案一样，不是把所有的人关在一个屋子里面，两个小之后自动孵化化出一个全局优优的架构了。
这架构呢需要要人能在考虑虑全的同同时能理解局局部引导，导家发现那个个优的架构。
这时候呢你的专业性就能让大家少走的技术弯路，也就是说呢你的武力同样存在价值。
你的价值呢在于带领大家寻找价值，而而是直接修修复一个大bug.从某种角度来说呢，这时候呢你的武力其实更重要。
因为你要靠真实考，靠技术术论和完美的逻辑来说服大家采取正确的判断。
我们刚才讲的呢这个架构设计的案例，在高速发展的企业里呢，往往还有其他维度的问题。
比如说呢合规、审计、分控、安全等等的问题呢，很容易被各个团队忽视了。
还有呢在不同的发展阶段，都新分配不同子域之间的研发投入等等。
这类问题呢的共性是之前局部最优的架构决策，在全局视角下不再最优。
这类问题所谓的决策都是跨域架构师的核心争执所在。
分析到这里呢，你应该能够想到一个局域架构呢，该怎么突破局部视角的障碍了。
有这么呢五个方面。
第一呢是要理解整个全局领域的目标。
第二是最大程度熟悉每一个子域，理解每一个子域的目标，挑战和需求的差异性。
第三呢是围绕一个统一的目标呢去分析局部视角上的差异性，然后引导各个决策者和执行团队呃，在右边的团队对布局和全局视角上看问题，最终呢引导多个子域的目标跟全局目标对齐。
第四呢设计公开的沟通机制，促进子域之间的信息对称，让每个决策者和执行者能够看到全局的优化目标，以及其他团队的重大决策、执行方式和当前状态。
第五呢逐步解决具体的设计理念、代码结构和实现方式的冲突达到全局制最优。
具体怎么设置公开的决策机制机制呢和解决跨领域的冲突的机制呢？我们在模块二的每个环节里都有深度的讨论和案例。
这里呢我就不多解释了。
如果你能持续不断的重复，刚才讲的整个过程不断的提升你在子域的知识和全局的视角，那么最终达到的架构设计必然是全局结构化的。
如果你能持续做好这些戏，那么就成功的跨越了从兼职架构师到跨域架构师的最大障碍了。
最后呢回到开头说的背锅问题上，如果呢你理解我们刚才的分析，看透了跨域架构师这个职能的本质，你可能对背锅这件事情呢就没有那么多的负面情绪和不解了。
不过呢我还是要认真分析一下之前的案例。
其实具体这个案例呢没那么重要。
也希望你从接下来的析析呢学学会思思想实验的方法。
也就是呢这是我以架构实施的身份，在几个团队争论不休的情况下，做故障裁决时常用的思考方法。
在开头的案例呢，三个团队各自有自己的局部视角，但是每个团队都缺乏完整的全局视角。
我们站在各自的局部视角中呢，其实是很难判断谁对谁错的。
类似的对多个团队之间的判责呢，你可以引入这么一个思考实验。
也就是说呢如果没有三个团队，只有一个具备超级大脑的人实现了整个系统。
那么是在什么阶段引入了这个故障呢？这种思考方式呢会把所有的讨论者带入全局视角。
虽然呢交易团队不直接调用资金团队的接口，但是呢交易团队对资金团队形成了一种隐含依赖。
交易的变更必须跟相关的资金变更同步，才能保证全局业务语义的一致性。
呃，也就是说呢，交易团队事实上呢发起了一个开始原子事物的语句begin transaction,但是呢没有实现结束原子事物的and transaction以及失败回滚的逻辑。
所以根据这个思想实验，我会判定故障的责任人是交易团队。
因为他们呢发起了具有原子事物属性的变更，但是呢没有保障相关的支付，还有资金变更的完整性。
也就是说呢，这个故障在交易发起一个没有保障的原子事物那一刻就产生了。
所以呢交易团队应该负全部责任。
举到这个案例呢，如果团队足够大，线下交流没法保障，那么一个跨域架构师就要在未来系统的设计上通过机制来保障类似变更的原则性。
你可以对交易模式设置版本号，要求相关的资金逻辑必须引用对应的版本号才能实施操作。
如果一个订单的版本号交易不通过，就不允许这个订单做资金流转操作。
我特别呢呃想强调一下，跨域架构师呢千万不能充当核时劳。
也就是说呢，你明知道交易团队应该负责任，但是这个锅呢还是你来背。
这种态度呢会影响你发现根因最终无法为你负责的领域引入正确的架构。
这是我们之前在模块一法则六提到的架构师所必须应该具备的勇气。
如果你跨越不了这种障碍呢，最后呢你只能成为一个化事背锅下，你这样一次一次又一次的背锅，害了自己的同时，其实也害了团队。
因为你的懦弱会导致本来应该被负有责任的团队就地解决的问题，变成了一个跨领域无人认领的顽疾。
从我的观察来看呢，这就是很多非常优秀的横向架构。
专家不能成功跨越障碍，成为跨越架构师的主要原因。
也就是说呢，他们缺乏解决跨领域冲突的能力和勇气，而且往往是后者，也就是勇气。
其实成为主要的原因，因为能力还可以通过训练甚至失败，后者修正来补齐。
或许你会想，为什么我要做跨域架构师呢？我做个兼职架构师不是挺好的吗？我钻研技术有什么问题，自己动手解决，也不去求别人解决好了，都是加分项解决不好也没人责怪我。
我在最初的十年职业发展中也是这个思维。
不过呢我认为现在时代不同了，两千年我进入软件行业的时候呢，互联网的竞争远远没有今天几点。
团队之间的协作复杂性呢也没有今天这么大好是现在公司越来越大协作呢，也从公司内部跨越到公司外部。
所以今天企业对跨域架构师岗位的需求数量远远大于以前，我认为这是个趋势。
也相信呢这或许是你来学习这门课程的原因之一。
好了，今天的内容呢就这么多跨域架构师在为多个子域的软件结构的合理性。
负责。
跨域架构师呢是为了解决冲突而生的，负责处理一个组织，内在的，也就是局部和全局之间的冲突。
跨域架构师的存在呢是易构组织的需要。
因为呢某个领域内部的短期目标跟更大领域或者更长期的目标不一致。
而这个冲突必须从更高层面看清楚，并且结构化的解决掉。
一个跨域架构师的存在呢，就是让跨领域的结构性风险呢降到最低。
你通过设立跨领域的沟通和冲突解决机制，让不同子域的决策者和执行者能够预见避免并且最小化子域和全职之间的冲突。
你要通过统一的全局目标，引导所有子域的整体的结构性。
当然呢你还要有足够的勇气去发现。
面对和解决这些冲突。
解决冲突的过程中呢，也就是你这个兼职架构师创造增值的过程。
如果你能持续做好这件事情，你也就跨越了。
从兼职架构师到跨域架构师最大障碍了。
关于背锅呢，我的抖音账号古董百丽呢有一个趣谈，我欢迎呢你去看一下这期视频的名字呢，叫做架构师的宿命。
这次呢倒真不是为了做广告，因为呢我经常发现了很多人学习呢学的非常苦兮兮的，然后用各种角度给自己励志。
我其实很不理解啊，那我认为学习过程中呢，找不到任何乐趣的人，其实也学不到任何的知识。
虽然我也没有任何科学证据，我总是呢认为如果学习过程中给了你，多把爱你，才能真正拥抱你的知识。
我写文章，做抖音，做视频的时候经常废寝忘食，其实也是因为我很喜欢做这个事情过程中就是很开心。
我也希望你学这门课呢，能学的开心。
好的，最后呢是我们的思考题环节。
今天呢我们改变一下作业形式，只留一道必做题。
学完这节课呢，我相信呢你已经比较清楚跨域架构师和兼职架构师的差异了。
那么你可以为未来的你一个跨域架构师设计一个小工，去帮助你更好的跨越。
从兼职架构师到跨域架构师的障碍，这个工具呢能让你更好的发现预见或者结构化的解决团队之间的冲突。
注意呢不需要讲怎么设计这个工具，只需要简单描述一下它应该具备的功能就行了。
我建议你用这个格式呢在评论区回复一下。
也就是说呢我要设计一下某某工具，这个工具呢可以做什么？因为有了这个工具，我可以更好的发现预见和解决某某类型的团队冲突了。
对这个作业呢最后还有两个小建议。
第一呢，你千万不要重新设计一遍jroa confiluence这样的常见写作工具。
第二呢，在你评论之前，如果别人呢已经发表了跟你类似的想法，我建议呢你给类似的想法点个赞，或者呢是在已有的想法上呢做个改进。
好了，今天我们的内容就这么多，我们下节课再见。