IDCF【冬哥有话说】第20期，圆桌论坛-畅聊，银行数字化转型圆桌嘉宾：付晓岩、姚冬、王立杰、许舟平、余晓蒨、刘威、陈浩、王君、李静
IDCF第5期DevOps案例深度研究，传统金融案例组成员于2020年7月23日，特邀《企业级业务架构设计》、《银行数字化转型》作者付晓岩老师，作客【冬哥有话说】。我们以圆桌论坛的形式共同探讨了Bank4.0、银行数字化转型、业务架构设计、人工智能、区块链以及物联网技术的应用现状及发展前景。非常感谢付老师的的指导，也非常感谢冬哥以及IDCF的各位指导老师，特意安排了此次与付老师的圆桌交流活动，这无疑是对我们案例研究工作最大的认可和最好的嘉奖，也是对我组传统金融案例研究结果的进一步升华（点击查看本次案例研究交付：金融江湖之传统银行风生水起 | IDCF第5期案例深度研究（附回放视频））。本着薪火相传的原则和传道分享的精神，现将圆桌内容梳理如下，希望能够惠及志同道合的你。
我认为数字化时代演进的过程是从农业、工业、到信息化、到数字化。数字化时代如果说跟以往的时代有一个很明显的不同的话，那就是它大部分的生产和生活的活动应该是在虚拟空间中来进行。这种虚拟空间的搭建，实际上是以计算机的三个核心为主的：算力要强，传输要快，存储能力要够，只有这三个核心能力提升上来，我们才能够通过孪生技术去真正搭建虚拟空间。Facebook、腾讯在虚拟现实和增强现实方面都有一些投入，而且 Facebook还很深入地做了一些底层的研究，所以这块其实本身就是我们未来的一个发展方向。通过这种孪生技术搭建虚拟空间，将来不光是银行，任何一个企业在为别人提供服务的时候，都不是唱独角戏的，因为大家都知道这个场景往往不是一个企业能够完整搭建的。一个完整的场景一定是各种合作方都连接起来的，在虚拟空间里把各种合作方式通过连接技术连接起来。这种连接技术代表的是什么？是我们企业架构将来的一个设计方向，它其实是一种开放式架构，就像我们今天谈企业架构的时候，你谈的都是内部一体化，不管是中台也好，还是说建行做了一种企业级也好，或者TOGAF主张的那种企业级也好，它做的其实都是以企业内部的这种业务能力的划分、内部能力的整合为主的。但将来我们架构能力肯定要再上升一步，面向整个生态圈去做这种能够合作的架构。这种能够合作的架构，从资源的角度来讲，大部分大概率都是部署在云上，然后合作方之间需要一种可信的连接，这种可信连接是我们降低商业摩擦，降低商业成本一个非常有效的方式。现在大家把希望寄托在区块链上，但我之所以不在这个位置上明确地写区块链，是因为我认为区块链方向本身是对的，它是要做一种可信的连接，但是未来的技术形态究竟是哪种，还有待进一步观察。也许区块链自己进化一下，也许是有别的继承了它的精神的技术出现，但总之是通过这种方式去保证连接的可靠性。那么大家合起来是为什么？是为了给客户提供服务。你要通过洞察技术去了解他的需求，然后通过送达技术去实现对他的服务。这种送达未来都是通过数字化产品、通过软件的方式来实现的。整个这一套逻辑就是建立在一个基于社会基础设施的协同化、定制化的服务。这些已经是现在新基建所主张的内容了，这对从技术视角看到的一个未来的数字化银行的愿景。- 第一，它是整个社会的一个转型，也就是说任何一个单独的企业，它自己没法把数字化的技术优势发挥到极致，因为无论是从数据的角度，还是从服务能力的角度，你只有连接起来才能发挥出巨大效应。所以它是一个全社会的转型；
- 第二，它是一个企业的整体转型，比如我们做数字化转型，对于任何一个企业来讲，不会把企业的一部分转型而另一部分抛在门外，因为企业管理本身我们追求的是什么？是企业的整体性和协同性。所以这种跨时代的转型，对于企业来讲一定是整体转型；
- 第三，是现在大家都谈的问题，都在说现在新技术发展很快，但是技术如何能够给业务提供价值？也就是业务和技术如何能实现深度融合？我们在谈数字化转型的时候，能看到那里边有大量的技术在，而这些技术最终的目的是为了让企业能够更好地服务客户，也就是为企业创造价值，这样我们要考虑的就是业务和技术如何能够深度融合到一起；
- 最后，转型不是明天的事，它是一个马拉松，是一个较长时间的过程，我书里给的时间段是20~30年，但是技术预测尤其是带了时间的技术预测，都是非常容易打脸的。但至少我们从时间的维度上来讲，它应该是一场马拉松，要有长期的思维，要有一种方式能够帮助你去不断的迭代和演进自己的企业，然后在长途的旅程中不至于迷路。
从实现的角度上来讲，我们经常会把敏捷也提上来，不断的迭代地去实现技术转型的目标，但是它应该有一个长期的导向。按理说你应该有一个超长期的思维加上一个快速的迭代两者的结合。以上4个特点决定了我们需要一种能看全景的工具，能了解企业整体结构的工具，能推动业务和技术深度融合的工具，并且能支持长期朝一个目标稳定迭代的工具。这个工具就是我们常说的企业架构，企业架构本身是能做这种事的，也非常适合在数字化转型里担当工具。刚才说了我们要看到企业的整体，我们能看到企业完整的任务活动就是整个的业务领域，我们也能看清楚一个长期的战略是如何落实到业务活动里的。因为战略只有落到业务活动里，有一个具体细化的任务去承接战略能力，这个战略才是能落地的，不然就是写了一段漂亮文章，或者是做了一堆PPT挂在墙上。必须找到具体的活动任务、角色去承担战略目标，这样才是战略落地的唯一途径。通过这种方式把战略和业务衔接起来，然后再把这种战略和业务之间衔接关系转化成能力需求，传导给IT，IT就知道用什么样的技术或者实践方式去支撑这个战略能力。当把这些全串起来的时候，我们就有了一个企业整体的能力地图，这里边有它的战略要求，有它的业务资产，也有它的技术资产。有了整体的地图，我们就可以像每天升级旅游地图一样，持续地朝一个方向去迭代、去升级！而且迭代的轨迹如果有合适的架构管理工具的话，是可以记录下来的。记录下来有什么好处呢？资产如果有一种很好的整理方式的话，我们就可以把这个能力赋予给一个架构师团队，而不是依靠某个个别的架构师，这就是如何把能力沉淀在企业里，沉淀在集体里，而不是仅仅沉淀在某个人身上。第二个它是一个企业的整体转型，比如说我们做数字化转型，对于任何一个企业来讲，都不会只把企业的一部分转型而另一部分抛在门外，因为企业管理本身我们追求的是什么？是企业的整体性和协同性。所以这种跨时代的转型，对于企业来讲一定是个整体转型。所以有“企业级”这三个字，这三个字表示的是我们这个架构设计的范围是企业横向拉通的，而不只是说某一个领域单独来看。在整个向数字化转型的过程中，从我们前面看到的这种发展过程上来看，一切产品都要通过数字化的方式送达，那就意味着将来数字化时代，是一个软件定义一切的时代。软件定义一切，软件覆盖一切，就要求我们核心的生产工具变成了软件，企业对软件的驾驭能力要很强。企业对软件的驾驭能力首先体现在什么？体现在大部分人员都能够理解这种基本生产工具。要想理解这种基本生产工具，就需要有一种结构化的思维能力。业务架构本身就是提升这种结构化思维用的，所以我把它称为需求侧的革命。因为以前我们的软件工程研究的都是这一侧怎么提高效率，敏捷开发也好，还是各种微服务架构也好，搞来搞去，其实业务人员在这一侧的参与度非常有限，仅仅限于提需求，所以我们搞了那么多年，好像也没搞得很好。核心的一个原因是业务人员一直就没能乐高积木化地去看过业务，技术人员一直在猜这边的乐高积木应该长什么样，但是业务侧的人员并没有把他的智慧和经验贡献到乐高积木的设计中去。将来在面对数字化这种时代，我们要大规模的软件批量生产的时候，就非常需要这种业务人员，用能够理解的软件设计，去支撑企业员工更好地理解业务如何被结构化，这样的话我们才能够更好更快地生产出更多软件去支撑数字化转型工作。启动企业架构设计之前，一个企业也需要考虑好这4方面的匹配性。- 第一，是深度匹配性，就是跟你的目标有关，像我们建行做的时候是一直做到5级，要花很大精力、很多时间。如果说你只是停留在架构升级设计上的话，也可以考虑做到4级，也就是说降低架构设计的深度，这样的话可能会节省一些时间和资源。
- 第二，是资源匹配性，就是做这种项目是一种企业级的转型，需要了解整个企业，为了帮架构师了解这个企业，就需要投入大量的业务人员，包括以前的技术人员，帮助架构师去梳理整个企业的结构。这个制约刚才提到了就是架构师，架构师也很重要。业务架构师其实是一个比较稀缺的行业，阿里也说了，业务架构师是非常难培养的，市场上你也找不到优秀的，最好的方式就只能是自己培养。自己培养是通过什么方式？实践，实践是理论之源。
- 第三，是时间的匹配性，跟前面这些目标匹配好之后，一个该干半年的事，你不能就给他三个月，一个该干一年的事你也不能就给他半年。那样的话做不好，结果你越想快，反倒做得越差。开发软件也没捷径，包括写代码也一样，代码都是一行一行写的，Bug也都是一个一个挑的。
- 第四，是耐力的匹配性，假如说我认为这件事对我企业来讲很重要，我愿意花一年的时间去做，愿发完了之后，是不是能坚持住？半年的时候又着急了，不能这样。要把这四者匹配好，然后再去做这件事。
刚才也说做这件事谁比较重要，就是企业及业务架构师，因为现在这个东西本身在市场上就没多少。要做业务架构的话，你可能在外边找，看看是不是能找一些做过企业级转型的人提供一些指导，但最重要的就像刚才说的，必须要培养自己的业务架构师，这个事没有捷径，也省不了。
- 第一，架构能力是核心。有人一看“业务”这词，说业务架构是不是偏业务的？其实不是，它既不是偏业务的，也不是偏技术的，它是偏架构的。所谓的架构就是结构和关系，他要擅长结构化思维，要能把复杂事物的结构和关系理清楚，把一个复杂业务的业务能力划分清楚、聚类清楚。做出一个好的结构，也是业务架构师的核心。
- 第二，流程优化是抓手。主要是因为业务架构的事比较漫长，也有人问怎么能短期见效，或者说如何能够让部门比较快速地信任业务架构师，其实这往往是一个突破点，因为没有哪个组织的流程特别完善，如果你愿意静下心来去想的话，它都有一定的改进空间。如果能够改进这些，就可以跟部门之间有一个比较好的开端。
- 第三，建模能力也很重要。企业架构是一组模型资产，不仅仅是那一张图，像我们做的全部的业务背景图、业务背景图之下的价值链的结构图、价值链再往下的业务领域的结构图、每个业务领域自己的背景关系图、然后流程图：流程图是从3级4级，像我们做得更多，一直到5级、然后再有数据，整个数据模型，包括建行还有大量的产品模型，然后还有聚类之后的业务组件图，所有这些加一起才是一套完整的模型支撑，这个才是完整的业务架构。建模能力很重要，可以多学一些建模，不仅是业务这一侧的，包括UML这种跟技术人员做沟通用的，各种模型都学一下，多了解各种模型的优缺点，形成自己能够改进建模能力的基础。
- 第四，了解技术实施过程。业务架构师本身是一个桥，连接业务和技术，所以业务侧流程优化这块业务你了解了，结构化的东西也做出来了，你也得对后边的软件实施过程有一定的了解，这样的话才能更好地去跟技术人员之间沟通。技术人员需要什么东西，知道技术人员生产过程是什么样，他们的困难在哪？这样的话更容易建立信任，一边是跟业务建立信任，一边是跟技术建立信任。
- 最后，很重要的就是整体思维。业务架构师不怕你的思维宏大，你越宏大越好，当然我们说这个宏大不是说你自己没有落地能力，因为这几项是保证你落地的，所以当你有落地能力之后，对于一个业务架构师来讲，你视野越宽越好，这样才能保证你的方案覆盖的完整度，才能减少在方案设计上的失误，一点一点地去扩展。业务架构并不仅仅服务于一个业务领域，很多时候像企业业务架构师，实际上是要把企业内外部综合起来看的，这种情况下，你的整体思维比这里边的一个单项的细节能力更重要，要记住自己的架构层面，不是具体细节上面，所以要求保持一种宏大视野。
李：我们在案例研究的时候做了一个刚刚如老师说的头号玩家——一个Bank4.0的侠客岛，畅想如何在Bank4.0的侠客岛上完成齐家、治国、平天下。我们第一个问题想问一下付老师，国内外实现这一目标，还有多长的路要走，需要哪些前置条件呢？
付：刚才也特意说了，预测时间在技术领域是最容易打脸的一件事，但至少从当时写书的时候梳理的那几个对于支持银行数字化转型比较关键的技术及它们自己的发展态势上来看，可能20多年左右的时间后会看到比较成型的东西了。至少比如说像虚拟化，现在你可能觉得虚拟化只是像增强现实这种，现在还不是非常理想，功能还比较弱，但再有20年左右的时间，因为它本身在基础的算力上也好，在传输上也好，在存储的存储处理上这块也好，只要这些基础能力的提升达到一定程度的时候，上层应用的技术就会很快。我看最近工行的手机银行上已经开始展示无人营业厅，也应该是在这方面开始逐渐有尝试，只不过进展速度应该还不会像想象的那么快。可以把它比喻成一个马拉松，只是这些关键技术都是现在已经有的了，不用基于一种不存在的技术去推断数字化银行会长什么样，要那样的话，我们就按照星际迷航去看就行了。它已经有现实意义了，这些技术在现实上都已经存在了。李：付老师也提到了一些相关技术，您公众号的文章我也都有看，包括我们在整个案例研究的过程中，也认为无论是为了支撑数字化转型，开放银行还是实现Bank4.0这样的目标，其实是需要依赖于技术的一个联动和整合的，所以我们当时也提提出了一个A（AI）B（Block Chain）C（Cloud）D（Data）I（IOT）I（IT Integration）框架。我们在案例研究的时候把最后的“I”定义为“It整合技术”，因为我们认为 IT基础设施的建设是一个基础保障，而IT整合技术是其进阶的基础，当时我们在 IT整合技术里，定义了敏捷DevOps、CMDB、虚拟化技术以及超融合架构，在交付之前也跟您有过一些请教和沟通，现在想听听您有没有什么建议，我们定义以上的这些技术为IT整合您觉得是否合适，它里面包含的这些技术内容您觉得是否全面？付：指导谈不上，共同探讨，大家会各有见解。金融科技的发展不单是金融科技了，整个数字化技术的发展方向应该也是每年都会有调整，像Gartner曲线也好或者什么也好，都是一年一变，每年都推出十大技术或者20大技术，每年都不太一样，都会有新的进去，有旧的出去，可能还会有前两年的又回来，像这种技术的来回变化其实是挺大的。你们那个想法我觉得非常好，也非常有游戏性，非常吸引人。ABCD其实是咱们常见的这几个技术了，一般我们会说ABCDMIX，加上移动、物联网，X代表还不确定，为还可能进来的新技术保持开放性，后边技术类型的出现，不定哪天又要蹦出一个新技术，就像区块链，区块链不就是在不经意之间突然蹦出来的一个东西。整合这一块，我个人这么看，软件设计里大家关注的主要问题是两类：一类问题叫过程，就是一个软件是怎么做出来的，软件过程里我们经常比较关注的是工序，做软件的过程顺序，工序里我们关注的是它的标准和质量，我们希望它能够提高产量；另外一个环节就是专门关注工序里、过程里的设计。过程里最重要的一个环节是设计，设计里主要关注的就是架构，架构关注的就是结构和关系。我个人会从这两个视角去看软件，一个是看过程怎么管，一个是看架构设计。我觉得整合里也包括了两类，一类是架构，就像你提了超融合；一类是过程，就像你说的 DevOps，其实是个过程。架构本身会跟设计关系比较密切，像你说ABCD的整合，是偏架构偏设计层面的，也跟我书里写的方式差不多，就是你会给架构分几个层，然后看哪个技术是作用在架构的哪一层里，架构之外再关注的就是软件开发用一种什么样的过程来实现。DevOps也好，敏捷也好，或者说二神山用瀑布来实现也很好，还有螺旋模型本身也有很多人认为它很好，所以分成这两部分来看，就是架构要怎么设计，过程要怎么实现，这是我个人的一点观点。刘：老师我想问一下，关于银行数字化转型，现在央行也在研究虚拟化货币，那么在区块链应用的落地，还有交付成果方面成功的经验，老师能给我们介绍一下吗？在这个过程中，银行数字化转型应用的阻碍有哪些？付：首先说央行数字货币，在我那本书里，对数字货币提的还是比较多的，包括我认为数字货币可能会影响很多业务形态，这属于个人观点，跟现在咱们做这个项目无关。首先从落地的角度来讲，目前各国都没落地，没有一个国家的法定数字货币是真正落地的，大家都在积极去做，尤其是Libra出现之后，大部分主要国家对数字货币都已经持开放态度了，都在积极研究，各有各的研究方式。方式上比较好的，我觉得是新加坡，他是用一种全开放的态度去跟大家一起搞研究。现在项目整个已经做了6期，每一期都换不同的成员，而且都是明星级的成员，摩根大通、淡马锡都跟他合作过，世界顶尖的区块链公司跟他们也都合作过，他的合作态度也非常实在，跨境支付，新加坡元，包括用数字货币在股票市场上做交割。第4期做的是境内的交割、第5期做的是跟现有金融制度的实验，第6期做的是跨境交割，他这种实验的方式非常好。银行里摩根大通做得比较远，他一开始是企业以太网联盟EEA的代表，联盟组织不小但是从来就没一个平台，他唯一的平台就是摩根大通做的Quorum，摩根大通后来在Quorum的基础上做了银行业信息网络IIN，实际上是奔着取代SWIFT去的，SWIFT是发报文来进行跨境客户汇款，IN本身也是传递汇款用的，只不过它联网的范围比SWIFT小得多。因为SWIFT的联网机构大概有1万多，IIN到现在可能也就几百个。在数据货币方面，本来去年2月份的时候推了摩根币JPM Coin，但势头没有Libra火，Libra出来之后根本就没人再谈它了。但它技术储备比较完善，既做了跟SWIFT相关的报文也做了数字货币，所以摩根大通在这块做的还算是不错的。区块链在银行落地了很多方面，但目前来看都是尝试型的：属于对这项技术的一个探索和实验，对平台性能的一个改进。在国内的话，因为我们不能做币，银行所有的区块链应用都不能做币的，在法定数字货币出来以后也许会有改善，但在这之前我们只能做信息网络，不能做价值网络。这种情况之下影响银行大规模应用区块链，其实跟区块链自身的性能还是有一定关系的。做联盟链的话，有一些对于公链特别热衷的人，也对联盟链持批评态度，联盟链用起来倒是挺好的，但它性能的改进还是要再进一步。现在还是比较适用于一些低频场景，像贸易融资平台，每年业务量都不是很大的，TBS要求不高，所以这种方面能落地，但如果说你要真正落到现有这种支付上，像双11那种支付，它马上也就崩溃了，一秒应该都挺不住。本身的性能、还有关于存储方面的问题，限制了一定的应用规模。这方面大家也都在持续改善，尤其是今年我们国家对于区块链尤其联盟链提了很多支持性的政策，我们都在努力，后边再看这个技术自己能改善到什么程度。付：智能合约肯定会用，因为只要做联盟链的话，提供这种可信执行环境，智能合约一定会用。但智能合约其实你可以认为它有两种类型，一种是相对复杂一点的智能合约，但有的时候我们比如说像Fabric上面，本身写账本的动作都是智能合约的，所以这块一定会用。但复杂的智能合约不那么容易做，而且本身在区块链领域其实也不提倡复杂智能合约，因为复杂智能合约需要在应用层做很多东西，智能合约里还是相对来讲规则越明确越好。王：银行和金融监管机构是如何合作去解决审批流程繁琐这个问题的？是成立了什么小组，还是运用了什么工具呢？付：具体情况我真不太了解，但可以从一个大的合作的方式上来讲，因为监管机构一般是不会下场的，不会非常明确地参加到一个具体业务的特别小组里，应该也不会完全没有，但是不多。它们跟银行间的合作方式主要是在政策探讨上，在一些规划的研究上，根据银行的一些建议，或者是来自实际业务的一些调研，来调整政策的松紧度。像你说信贷审批这块的合作，就是看有的时候一些监管政策上面的要求，比如进件的要求，有时候会释放校准这些东西，它是通过一些政策手段来配合，不会真正直接走入到业务这个层面上，还是会处在一个调控者的层面上。比如像疫情期间远程开户这个问题，可以稍微适当放宽一点，会根据实际环境去做政策面的调整，主要是这种合作方式。余：我想问一下老师，银行数字化转型肯定会要求银行在IT力量方面有一定的增强。过去银行大家都知道会有很多的外采、项目的外包，它的系统架构也是非常复杂的。未来，您认为银行在软件开发的人员组织，还有系统架构方面，会产生什么样的变化呢？付：这个问题非常好，也是现在很多银行头疼的问题，大银行有脑袋疼的地方，中小银行也有中小银行脑袋疼的地方，疼的点不太一样，但是都比较痛。大银行是因为它传统的竖井式开发系统太多，大家希望这个系统之间协同得更好，数据方面也希望质量能更好，这样就要求内部设计上要加强。哪怕说我不改业务系统，去做数据湖，数据湖到数仓到数据中台，还是绕不开数据模型统一和标准化定义。对于大银行来讲，要增加的主要是提升架构能力。因为这两年大银行项目开发越来越多，项目上比较提倡提高自研比例，哪怕这个项目不能完全做自研，要提高这个项目上自己人的占比。不是过去那种当甲方的模式，做一个项目，派几个行方的人像监工一样，拉起一个项目搞个外包就完事了。这种事现在在大行应该是越来越少了，我们会逐渐提高自研的占比，而且技术人员的扩张速度也非常快。大行在这一方面毕竟还是比较有钱，lOE都用得起，用人它也用得起，所以它在逐渐提高自己的架构能力和开发人员的数量，提高自己内部的设计能力。现在四大行逐渐都在向企业架构转型，提升自己一体化的设计能力。对于中小银行来讲，要提升技术人员的占比其实是挺困难的一件事，因为它的资源本身就有限，要招一些技术人员的话也不容易，当你真正想去市场上找好技术人员的时候，哪一个环节技术人员都挺缺乏的，要想雇个哪个行业的专家都不容易，都挺贵的。所以中小银行离不开外包开发，因为它必须得靠外边去弥补它人力上的不足。有一点跟大行一样，就是在雇外包之前，必须先提升自己的架构设计能力，你得自己能设计，自己能管理好架构，能管理好系统之间的关系，自己能够具备提出改良方向的能力，再去找人给你干活，才有方向。不然的话就是听着那个人，人家说怎么干你就怎么干，反正技术你也不懂，你自己管技术的人能力有限，你的领导对这方面就更不懂，这样的话完全是被外包左右，外包的质量都很难管。因为软件的质量有的时候你看不见摸不着，上线之后才知道，上线之后要不出生产事故都是好事了，到那个时候才知道就已经非常晚了。所以得有架构控制能力，软件质量方面的管理能力需求要相对弱一点，但最好也应该有，毕竟掏钱了，你自己怎么也得能验收，得知道别人做的行不行。架构设计能力对于小银行来讲绕不开，咱们说数字化转型，大家都认可将来企业都是科技企业，技术实力都得到一定程度，至少在设计能力到一定程度，你写代码可以缺人，你的设计不能真缺人，设计要缺人的话，将来就没法改进你自己的业务了。余：也就是说小银行也需要有他们的企业级的业务架构师，可以这么认为吗？付：我认为是这样，我们说的是一个时代的转型，过去小的手工作坊，今天都要变成小企业了，都要开始使用机械化设备了。余：我之前在微信群和B站看到，大家会比较关注像农村信用社这类规模特别小的银行，包括我之前也听到说蚂蚁金服也希望做到普惠金融，希望为这些小银行提供 IT服务。对于这样的银行，他们是不是就只能依赖于这些互金的公司为他们提供服务？还是像您说的，他们要自己去进行一些设计，然后再去用外部的那些服务来组合他们自己的一个整体的企业级业务架构？付：这得分两个阶段走，因为现在让它一步提升设计能力，它也提升不上来，招人也不好招，而整个企业的外采行为也是不会停的，一直在持续地通过外采的方式，这样的话就有实践机会，应该通过这种实践机会去锻炼自己的人。就像我们找咨询公司，如果咨询顾问走了留一堆PPT，你自己的人一点提升没有，这个钱相当于是白花的。外采也一样，在外采的过程中，要通过跟外采人员的接触，逐渐提升原来技术人员的实力，一点一点去培养，这需要时间，反正在市场上直接找也找不到，那你就通过这种方式逐渐去培养。企业级业务架构这种东西，它的理论能力，是可以通过培训获得的，TOGAF培训都已经非常成熟了，可以找一些有TOGAF证的人，或者送你的人去参加一些TOGAF的课程，让他掌握了这种理论之后，再配合上实践，逐步去把能力提升上来。但这个动作如果不做的话，这个能力你永远都没有，而且也浪费了一些时间。陈：老师是这样，我看您那两本书，《银行数字化转型》里，它落地的一种方式就是TOGAF，在另一本书里明确讲了TOGAF怎么具体地去落地，包括价值链，还有乐高积木这两种方式。TOGAF应该算是一个外来的和尚。国内的话，从阿里2015年提出来中台的概念，而且中台本身它并不只是一个软件，而是包含着整个业务设计到软件到最后运营的一整套的方式。从TOGAF和中台这两种方法论来说，您觉得它们有什么不同，在落地上有什么不一样的地方吗？付：这是一个非常好的问题，因为现在中台非常有热度，而且还没有完全减。陈：2015年阿里提出来“小前台大中台”，到2019年整个行业爆火，去年各个 VC投的好多公司都是中台的，从今年开始，应该是开始步入落地的一个阶段了。付：从讨论的角度来讲，今年中台进入了一个相对冷静期，像你刚才说的2015年马云提出战略，到2018年的时候，TMF2.0算是标志它完成了一个阶段性的中台建设，这一年钟华老师的书也出来了，那本书其实是整个中台宣传的一个起点，中台这俩字也是从那本书上来的。我去南京的时候碰到这本书的编辑，他说当时给书做宣传起名的时候，都没太关注那俩字，在书上你仔细看它是个小字的部分，后来不知道为什么这两个字火了，可能这两个字比较容易记住，比较容易理解。所以2018年的时候有落地的东西出来，接着舆论就开始一路把它往上推，今年年初的时候又开始各种翻车，开始往下来，我觉得是进入一个冷静客观的时候了。包括大家看来看去就是一方面说中台离不开组织，离不开组织建设，离不开企业文化，离不开业务梳理，所以又回到了企业架构范畴。有人说它是ERP的升级，这也是企业架构的范畴。阿里张建锋2018年的时候也说，其实在这里边最重要的是什么？是业务架构！但他们做业务架构那套方法跟我们不太一样，它比较偏重领域，有点类似于DDD但又不全是，它借用了DDD的一些概念，但没有完全一模一样的按照DDD方式去做。他们架构在画图的时候经常画各种域，不像我们画层，域的话就比较灵活，不像分层，层是相对固定的，域可以随便调的，需求比较灵活，那就是他们设计上的一个特点。中台如果跟TOGAF去比的话，TOGAF虽然也叫参考架构，但它其实并没有给出一条明确的技术路线或者是业务路线，它只是给了一堆交付的标准和交付物应该涵盖的内容，所以它相对来讲是一个抽象性、普适性的东西。中台的诞生，大家先关注的是中台的技术部分，它先给了一个完整的技术栈，包括像钟华老师的书，我觉得很多人看完这本书之后，第一印象是完整的一套中台技术实践，反倒是钟华老师说的业务那部分大家可能有点感受但先放一边了，因为那部分你找不到参考，但技术栈很明确，我要有钱的话就直接包一套阿里技术栈下来就完事了，或者是用阿里的云服务，整个这一套技术栈就有了。所以单从落地实现的角度来讲，技术这一侧肯定是中台相对更容易，因为它有一个非常明确的参考的技术架构，有一个成熟的技术栈，只要你愿意用，你就可以用。但它的问题在哪？拿到了技术栈之后，这个技术上面放什么，业务中台里面到底什么东西，放的是什么，每个企业都不一样，所以一开始就有一些实践效果不是很理想的，后面都卡在这了，自己的业务的梳理方法没有完全给出来。因为阿里做这个跟别的企业不一样，阿里它是一个电商企业，它是在探索自己的领域。今天正好还跟别人讨论这个问题了，互联网企业可以用试错的方式，或者用那种不管历史包袱的方式，去搞一些自底向上的设计，因为本身企业就十几年历史，说没有过去都行，自己就可以随便去搞这个东西。但传统企业，过去的客户，过去的员工，过去的流程，过去的系统，包括以前欠的债全都在这，你能说我用休克疗法，就跟当年世界原来的超级大国之一似的，这一休克之后再没起来。对于很多传统企业来讲，如果要搞休克疗法的话，还真得想清楚，这里边的风险是不可预见的，所以你没法搞休克疗法，说搞一套新的技术栈就把业务直接装在里面了，这事没那么容易。数据迁移、业务结构调整、组织结构调整等等，所以后边很多项目都卡在这了。对这些企业来讲，在转中台之前、或者是做系统数字化转型也好、做架构重构也好，之前都得先把业务理清楚，业务不理清楚的话，技术做啥？需求都搞不清楚，你说你买了个吉普车，但人家本身是想拉货，这怎么往一块配？一定得把业务这一侧先理清楚了之后，找清楚业务方向，技术才能对上。刚才那个问题，我不愿仲裁谁好落地，单纯从技术角度来讲肯定中台好落，但如果从全面的角度来讲，它俩谁也不好落。因为理业务这块都很难，好多企业自己都不清楚自己业务到底怎么样。陈：您在书里其实也指出了一条路，有一条可能是：前面有一个咨询团队来帮忙把整个业务梳理清楚了。包括华为真正能把 IBM的那一套落地以后，也是一个这样的思路。请咨询团队把整个业务梳理清了，再请一批技术团队，首先在业务团队那边能把这些东西灌输进去。把自己的业务弄明白了，然后技术团队和业务团队去结合，最后把这个东西才能落地。落地以后还要有一个运营或者叫运维的阶段，把这个东西持续地走下去，这样才能最终达到闭环。付：对，这就跟我们做企业管理一样，因为架构在思维的最顶层，它跟管理其实是相通的。管理本身也是持续地去管企业的演进，没事老折腾组织结构，不也是为了适应外面的环境吗？组织结构其实就是业务层面的架构，也相当于架构的一部分。跟我们折腾系统架构也一样，一段时间技术更新了，或者是你对业务理解加深了，你就手痒了，先把过去的系统重做一下，把过去的代码重写一下。- 第一你有多少钱，有多少资金就用什么样的技术，资金跟技术之间绝对是匹配的。
- 第二个决定性的问题就是你自己技术团队的能力，你的技术团队能掌握什么样的技术，他掌握不了的技术栈你给了他那就是害他。
在业务这一侧，就是从上到下集中好精力把结构理清楚，因为没有哪个企业是真正能在没有结构的情况下去管的。一些互联网公司成天说敏捷，你看哪个公司组织结构不全，我们去年研究做风险合规体系建设的时候，就专门比较了一下互联网公司风险管理，人家也是三道防线，什么都有。而且安全团队比你还大，这种企业只要它长到一定规模，你说它不靠管理，那是不可能的。陈：现在有一种说法，中台其实是 ERP的下一个阶段。ERP之前在建的时候，它会把整个顶层设计要不要抓起来？好一点的ERP是有场景的，但对于中台来说，它没有场景，所以就需要中台本身有一些自身的能力，然后在快速的场景迭代的时候，发现一种场景，能够在这个时候把你中台的能力迅速的孵化出去，这样的话才能够达到一个比较能适应现在这个时代的程度。付：对，你说的非常对，中台如果说你从方法论的角度来看，方法论其实是没有场景的，有场景的是方法，方法是在具体的环境和条件下才能适用的。所以为什么说中台比较难以产品化？没有场景的时候，它就很难被产品化，你把它总结成一个理论容易，但把它变成一个产品，这就困难了。因为产品都跟场景有关系，你说我这块是要搭配的、那块是要搭配的，这个参数要配那个参数在什么时候发挥作用，功能在什么时候发挥作用，都有前提条件。李：想问一下付老师，无论是从公众号文章，还是您的企业级架构设计，包括《银行数字化转型》这两本书，我们都能感受到这些内容的输出您是进行了大量的提炼和调研工作的。因为在文章中我们不仅能看到内容的深度，更能看到丰富的案例以及完善的数据支撑。想跟您请教一下这大量的案例和数据，您是通过什么样的方式进行调研的呢？另外您是如何平衡工作、生活、学习、研究以及写作工作的呢？付：首先写第一本书的时候，其实材料倒是不用刻意去收集了，因为它是我那6年办的工作总结，相当于是把工作思路提炼出来了，所以这本书其实我只需要参考一下我以前做过的工作，然后包括我跟别人讨论的一些问题，然后把这些东西回想起来就行。因为最开始那本书本来是想做微课，微课就是10分钟左右一节，10分钟的话大概2000~3000字，这也是按照微课的结构去写。然后后来变成书了之后就重新调整结构，里边还改了很多东西，然后就变成了书的结构。但是第二本书写的时候就比较累，第二本书因为它确实需要收集数据，第一章和第二章需要收集大量的信息，所以后边有人问我说这书里边对你来讲最难写的是哪章？我说第1章和第2章对我来讲最难写，因为我要找太多的东西了，3456其实是我的推理，我可以按照我的结构去推理了，我不需要太多的佐证了。那里边关于一些技术的东西，其实是我比较长时间阅读累积起来，其实是碎片化阅读，现在大量的人都是在碎片化阅读，就是今儿看点公众号，明儿看点公众号，然后收藏一些文章，然后收藏这些文章的时候，它在后边我需要的时候，这些文章基本上也能用上，其实写第二本书，尤其是一二章的时候，资料阅读量相当大。然后平衡，其实没有人能真正把这些事都平衡了，这时间一天就那么24小时，你干这事就不能干别的，所以你总是会说这个事干多了，肯定就牺牲别的事的时间，尤其是生活这方面的事情。之前有人问过我说你写的挺快，我说写的挺快，你觉睡的少就行，是吧？每天上班的时间你又不能写，下班能喘口气，可能到七八点钟以后了。我真正写第二本书的时候，都是每天晚上9点以后才写，早的时候写到12点，晚的时候可能写到两点到三点，然后你如果能够强制自己集中一段时间去写的话会更好，因为思维本身也需要连续，如果中间一打断思维也会断，再重新想也费劲，所以有专题的时候我会强制自己一段时间之内专攻这一个专题。像这两本书我都是集中了一段时间去专攻，平衡是很难的，谁也做不到真平衡。
如果您看到了这里，真的非常感谢，坦白说这是我整理的最长的一篇文章，但来回推敲也舍不得删掉任何一句，感谢付老师满满的干货，也感谢一直吸收到这里的每一位读者，让我们一起朝着Bank4.0的目标努力，一起在Bank4.0侠客岛上笑傲江湖！
八月，乘风破浪。IDCF【冬哥有话说】8月特别邀请到四位美女，带来四个主题分享，分别从组织建设、绩效考核、品牌营销，以及技术卓越等不同角度，围绕“数字化”展开，这也体现了IDCF一直秉承的理念“培养端到端的人才”，我们希望可以通过本系列的分享，给你不同的视角去看待一个企业，从单纯的技术视角跳出来，去尽可能的看到一个更加完整的全貌。本周四晚8点，易保网络配置管理资深架构陈茜分享《研发跨6国7城8/9朵云-多云、异地开发协同的挑战之下的生存之道》，识别下图二维码，回复“乘风破浪”即可获取直播地址。
