|
|
# 03 | 架构思维：数字化转型如何落地？
|
|
|
|
|
|
你好！我是付晓岩。
|
|
|
|
|
|
前面两节课，我们学习了历史思维，弄清楚了数字时代的特征和要注意的发展趋势，同时，我们还学习了生态思维，找到了建立核心能力和生态关系的思路，那么，我们怎么把这些认知和思路落地呢？这就要用到架构思维了。可以说，架构思维是这门课里最核心的、起到方法论与实践连接作用的思维模式。
|
|
|
|
|
|
所谓的架构思维，就是采用架构的视角去思考问题。简单来说，架构就是结构和关系，包括一个事物由几部分构成，各部分之间是什么关系，设计这些关系和演进的原则是什么。那架构视角，也就是从结构和发展的角度看待事物，不仅要看到当前的结构，也要看到未来的结构，并搞清楚怎么从当前的结构走向未来的结构。能这么看问题呢，就是架构思维了。
|
|
|
|
|
|
数字化转型其实也是企业从当前状态走向目标的过程，也需要在一定的指导原则下进行演进，所以，架构思维是做数字化转型必不可少的一环。
|
|
|
|
|
|
那怎么把架构思维应用到转型上呢？具体点说，就是关注两个层面，一个层面是架构设计，要关注全面和结构这两点，架构设计要具备全局视角，结构要清晰；另一个层面是架构管控，要关注灵活和演进这两点，要注意短期的应变与长期的求变。数字化转型是企业整体的马拉松式转型，架构思维的全面、结构、灵活和演进这四个关键点给我们提供了方向。
|
|
|
|
|
|
接下来，咱们就先聊聊第一个特征，全面。
|
|
|
|
|
|
## 全面
|
|
|
|
|
|
所谓的全面，就是你要努力从全局视角看问题，以充分识别会对设计产生影响的东西，避免遗漏掉关键环节。我们来重点聊聊全面的重要性，以及如何做到全面。
|
|
|
|
|
|
### 为什么要全面：范围决定设计
|
|
|
|
|
|
一提到架构，很多人会想到在网上搜出来的那些画得很牛的架构图，别管多大的企业、多少信息，都能浓缩在一张图里，所以，人们经常会觉得抽象能力是架构首先关注的。但实际上，全面才是最重要的，因为**你看到的范围，决定了你的设计会是什么样子**。
|
|
|
|
|
|
举个通俗的例子。这就像你梳理手边工作的优先级一样，当你有5件事要做时，你会给它们排个序，如果这时候，你突然有了10件事，你还会保持原来的5件事的排序吗？估计会变。如果很不幸，塞给你20件事儿，那排序又得变了。你看，范围不同，事情之间的权重，也就是它们在整体中的位置就不一样了。
|
|
|
|
|
|
在设计企业架构时，你梳理一个环节和多个环节，所对应的设计目标也注定是不一样的。
|
|
|
|
|
|
就拿汽车生产企业来说，如果你只梳理轿车的生产线，会得到一个设计结果；如果你再梳理越野车的生产线，并尝试进行整合设计，你会得到另外一个设计结果；如果同时梳理了汽车的设计过程、生产过程、销售过程、售后客户信息的持续采集，并尝试进行打通的设计，你又会得到一个设计结果。
|
|
|
|
|
|
这些结果会分别对应不同的设计目标，比如，单一生产线的优化、多生产线的协同优化、企业生态视角的全局优化，显然，最后一个目标才是数字化希望达成的，同时也是企业架构最有价值的目标。
|
|
|
|
|
|
架构思维的全面性，简单来讲就是一句话，“不谋全局者，不足谋一域”。每个企业的价值创造都是一个完整的过程，比如从客户分析到产品设计到销售，再到售后服务，这就是企业的价值链，任何一个环节的缺失都可能导致客户服务能力的欠缺。只有在价值链的引导下，对每个环节进行充分分析，才是真正做到了全面。
|
|
|
|
|
|
### 如何做到全面？
|
|
|
|
|
|
看到这里，你可能会问，这么多东西，怎么可能一次就想全呢？
|
|
|
|
|
|
其实，这个问题正是对做企业架构设计的一个严重的认知误区。很多人都把企业架构设计当成了请咨询公司搞一次企业架构项目的交付物，但实际上，这种最初的集中性设计只是起点，**企业架构需要持续的积累和完善**。
|
|
|
|
|
|
人的能力总是有限的，哪怕把很多人加起来，也不可能把能力放大到无限，所以，每一次的架构设计都有可能是不完整的。
|
|
|
|
|
|
有的时候，是“**看不到**”导致的不完整。比如，有个业务环节或者规则被“集体遗忘”了，直到新的业务人员做测试时才发现，甚至有可能上线了之后才发现。这种事情对任何一种设计模式而言，都是有可能出现的，什么模式也解决不了“看不到”的东西。
|
|
|
|
|
|
有的时候，是“**看到了但做不到**”导致的不完整，尤其是在处理跨部门需求时，比如银行中常见的信贷类客户限额的集中管理，如果找不好牵头部门，或者各部门对原有管理模式的改变意见不统一，那首次架构设计中集中的限额管理就会成为一个空缺，只能等以后再填补了。毕竟，每次做项目都有时间限制，谁也不能一直等下去。
|
|
|
|
|
|
这样的情况会有很多，所以，要持续对首次设计达成的企业架构进行迭代，形成无限接近完整的企业架构。依靠这样持续完善的企业架构，整个企业对架构师都是可视的，这能够更好地保证架构师每次设计的合理性。而每次的合理设计，也会对企业架构的完整性形成有益的补充，形成良性循环。
|
|
|
|
|
|
所以，要做到全面，一是要靠价值链搭建起完整的分析框架，二是靠架构自身的持续完善来保证。
|
|
|
|
|
|
但是光把东西看全了还不行，还得理出关系来，下面咱们聊聊第二个关键点，结构。
|
|
|
|
|
|
## 结构
|
|
|
|
|
|
架构这个词是来自于建筑行业的，原本指的就是房子的结构，所以，一谈架构就离不开结构。关于结构，有两点你应该记住，结构分析的目标是为了更好地实现业务的想法，而做好结构分析，靠的是有目标地拆解。
|
|
|
|
|
|
### 没有结构就没有实现
|
|
|
|
|
|
我们不仅要全面地看一个企业，更重要的是，看到企业准确或者合理的结构，这是由架构的目的决定的。毕竟，我们不是为了画架构图而去研究架构的，是要通过架构设计准确地理解企业的内部结构和构成部分之间的关系，这样才能确保我们的需求实现是准确的。
|
|
|
|
|
|
这么说可能有点儿抽象，我拿买房子这个事情来解释下。假如你买了一所房子，那怎么让房子的具体使用符合你的美好设想呢？这就开始进入架构设计阶段了。
|
|
|
|
|
|
首先，你要考虑，哪个房间是主卧、哪个是次卧、哪个是书房，这算是粗粒度的架构设计。在粗粒度设计之后，你还得考虑更细节的架构设计，比如，沙发怎么摆、电视怎么摆、放不放鱼缸，等等，这些问题可能是关联的。假如你希望客厅放个大鱼缸，那冰箱可能就未必放得下了，得换个地方安排冰箱。
|
|
|
|
|
|
企业架构也一样，价值链的基本活动上有企业的核心生产过程，比如产品设计、产品制造、质量控制，支持活动上有客户管理、财务核算、营销管理等内容，可能都需要设计不同的业务系统进行支持，系统与系统之间也会有相互关系，比如数据的共享、业务的协同等，就跟你设计房间一样，需要给不同的需求安排个位置。
|
|
|
|
|
|
做好结构设计，就是确保你的想法会落实到各个组成部分上，通过考虑它们之间的相互关系和搭配，确保实现你的预期目标。
|
|
|
|
|
|
### 一定要有目标地拆结构
|
|
|
|
|
|
说到这儿，问题就来了，企业的结构一般很复杂，规模也不小，怎么才能实现对结构的清晰梳理呢？这就要提到结构化的核心了：有目标地拆解。
|
|
|
|
|
|
结构化是我们应对复杂事物的有效办法，太复杂、规模太大的东西，要想搞明白，就要拆碎了看，大事化小才行。
|
|
|
|
|
|
咱们继续来设计房子。如果让你一下子说出你要买多少家具，你能说出来吗？估计挺难，但是，你可以通过定义好每个房间的设计，再统计出你最终要买的家具，这就是通过结构化把复杂问题分解开来处理的思路。
|
|
|
|
|
|
结构化能同时降低你想法的复杂度和企业的复杂度，因为你把它们都拆碎了，但是也保证了你不会因为拆得太碎而忘记了最初的、最顶层的设计目标。因为**架构思维的拆不是乱拆，而是逐层分解、由粗到细、有结构地拆，最终会把理想的目标落到具体的细节上**。
|
|
|
|
|
|
比如，想提高企业的生产效率是不是一件很复杂的事情？对某些行业来讲，复杂度甚至有可能超乎你的想象，你只有把企业所有业务环节都梳理出来，一环一环地去拆解，去奔着提高效率的目标进行改进，才有可能最终实现这个目标。比如丰田的精益生产，那是细致到一个操作动作的级别的拆解，没有同样的付出，就别指望同样的效果。
|
|
|
|
|
|
回到数字化转型这件事上，我们的转型战略、企业的结构，都是挺复杂的东西，如果不尽可能完整地分析我们的企业，那数字化转型可能就会有盲点。比如说像安全保障、远程办公之类的事情，你之前可能觉得影响不大，但是在疫情防控时期，它们就非常重要了。如果不结构化地分解我们的企业，那就很难形成具体的、可落实的设计。
|
|
|
|
|
|
全面和结构，是做架构设计的核心。可以说，做到了这两点，你的架构就考虑到了大多数相关方的利益，能够为技术侧提供良好的指导了。
|
|
|
|
|
|
但是，环境一直在变，任何架构都不会是一成不变的，从短期来看，好的架构必须具备灵活性，从长期来看，必须是不断演进的。下面我们就先来聊聊什么是架构思维的灵活性。
|
|
|
|
|
|
## 灵活
|
|
|
|
|
|
传统架构的管理有严格的变更控制，这经常会让人觉得架构很死板，一旦做出来轻易就不能变更。这其实是误解。管理严格是希望变更不要过于随意导致整体设计混乱，但不是不允许变，尤其是在思维层面，架构的灵活指的就是要及时接纳变化。因此，对架构思维的灵活性，你要注意两点，一是架构需要经常调整，二是别把架构搞成呆板的管理。
|
|
|
|
|
|
### 架构是需要经常调整的
|
|
|
|
|
|
架构思维要考虑全面、要关注结构，从实操上来讲，这要求挺高的。你想想房间设计这个事儿，夫妻俩都有可能在装修上存在巨大分歧，更何况一个复杂的企业呢？设计本身要覆盖的范围越大，考虑得越多，引起变化的因素也会越多，所以，灵活就很重要了。
|
|
|
|
|
|
我来举个例子说明一下这个事情。假如B部门的一些需求可以与A部门进行业务整合，你提出了解决方案，评审也通过了，但是，在实际执行的时候，B部门却发现与C部门的部分业务活动做整合也可以，而且实施起来更方便，比如这两个项目团队之间更熟悉，沟通更方便，A部门在具体做的时候也出现不太愿意配合的苗头，等等。
|
|
|
|
|
|
这个时候，怎么做呢？那就调整一下呗。这种等效的变更应该是随时允许的。
|
|
|
|
|
|
另外，有时也会出现一些与设计目标不符的情况。比如说要替换一个遗留系统，大家都挺用心，但是，无论是业务分析，还是逆向工程都搞不定。如果不是迫在眉睫，这种也可以停掉。
|
|
|
|
|
|
当然，在现实的架构工作中，设计目标与实现条件有严重冲突的事情相对比较少，架构师对自家的实现能力不至于心里没数。往往是架构设计完成后，实现过程中发现了更多的细节需求、新需求而产生的架构调整，只要经过适当的评估，这都是可以灵活接受的。
|
|
|
|
|
|
不能总想着架构是不能轻易调整的，灵活对架构思维而言非常重要，甚至可以说是架构思维的生命之源。这么说并不夸张，谁愿意花大价钱搞个做出来就不能动的东西呢？这也是我做企业架构越久，体会越深的东西。
|
|
|
|
|
|
### 不要把架构搞成刻板的管理
|
|
|
|
|
|
很多人都把架构看成是一种管控，甚至抱怨架构的约束、限制、死板，这其实是把架构的执行问题当成了架构的缺陷，这是非常不正确的架构观。
|
|
|
|
|
|
曾经我也以为架构离不开严格的管控，不然，搞具体实现的人想怎么干怎么干，那我还做整体设计干嘛呢？架构考虑了全面和局部的关系，具体实现的人往往只考虑局部，不是应该听架构的吗？就像打仗，前线的小分队确实更了解自己的战况，但是都让小分队说了算，还要总参谋部干什么？还有人能对整个战场负责吗？局部胜利未必会赢得全局胜利，有时候还需要让出局部利益才能达成全局胜利。
|
|
|
|
|
|
但事实是，这么想的话可能就搞错了路径，架构要保证落地，不是单靠对大家的严格管理做到的，是因为架构设计本身适应了环境和目标的要求才做到的，也就是说，是因为设计正确而做到的。可以用企业管理再类比下，企业经营的得好，不是因为所有人对总经理都唯命是从，而是因为决策本身是正确的，大家顺着正确的方向才把事情做对了，单纯的严格管理并不能保证方向的正确。
|
|
|
|
|
|
所以，架构不是为了控制，更不是为了追求所谓的稳定，而是为了适应，这就是架构思维强调灵活的原因。管理上经常讲弹性、柔性，其实架构思维也一样，也是很需要弹性的。
|
|
|
|
|
|
但是，这种灵活性总体来讲还是一种“应变”，是架构为了实现当前目标而需要具备的弹性，属于局部的微调。灵活可以看成是处理当前困难的原则，但是处理长期问题，就要讲求演进了。
|
|
|
|
|
|
## 演进
|
|
|
|
|
|
就算你灵活处理完了当前问题，架构也不是可以躺在那里高枕无忧了，世界每天都在变化，你肯定不能停留在原地。
|
|
|
|
|
|
举个例子。互联网公司的架构管理能力还是很强的，他们很善于灵活应对当前的变化，但是即便如此，还是会5年左右出现一次大的整体架构层面的调整，这种调整经常被称为“架构演进”。这种调整都是以满足快速增长的业务目标为导向的，毕竟，支持1万用户与支持100万用户、1亿用户，所需要的架构有天壤之别。
|
|
|
|
|
|
以前，这种调整经常被解读为技术层面的，比如从单体架构转进到微服务架构，从使用主机到使用X86，从集群到云，但是随着“中台”的出现，渐渐把业务、组织结构和技术架构的变化也放在一起解读了，还扩展到了企业文化。
|
|
|
|
|
|
所以，这些互联网公司的演进，其实也可以看成是企业架构的整体演进，而不只是技术架构的演进。
|
|
|
|
|
|
这个道理也可以用于解读传统企业的架构演进。传统企业之所以演进没有互联网公司快，其实也是因为业务增长速度没有互联网那么快。
|
|
|
|
|
|
那么，这几年为什么又纷纷提出要更新架构，搞数字化转型呢？其实也是因为互联网公司带动了社会环境的变化，太多的人和企业都在网上活动了，这种环境的变化必然导致业务的变化，进而催生架构的演进，这也可以算是一种主动和被动交织的“求变”演进。
|
|
|
|
|
|
数字化转型不正是这样吗？有些行业有比较成熟的信息化建设，就像银行业、制造业、通信行业等等，也有常年耕耘在这片领域上的技术服务商，但是，信息化还没有达到全行业都过剩的时候，数字化就已经悄然启动、加速快跑了，原有的系统我们会因为建好了就不再动了吗？
|
|
|
|
|
|
你不敢，因为只有努力提供最好的服务，你才能在生态中保持合适的位置，才会在历史中延续下去，这是运用架构思维时必须掌握的点。
|
|
|
|
|
|
架构思维不是追求一次设计任务的完成，而是考虑持续的适应和生存，演进的方向就是持续满足业务或者说战略的目标，而能够为此主动发起变化，才是最好的演进方式。这里我给你提供3个方向。
|
|
|
|
|
|
* **关注未来**：无论分析结果对错，都要结合历史思维，始终关注对未来方向的研判，这一点没有大小企业的差别，时代淘汰谁是不设门槛的。看不到未来，其实也就找不到战略和演进方向。
|
|
|
* **主动求变**：预测未来最好的方式，就是你自己要主动寻求理想的变化，并且朝着这个目标靠近，这才是最保险的。亚马逊和阿里巴巴对云的执著，分别造就了世界第一和我国第一的公有云服务供应商。虽然你的企业未必有这么大的目标，但是，任何一个企业的目标实现都不能指望别人白送。
|
|
|
* **打牢基础**：架构演进可不是灵机一动，需要很好的知行合一能力，把理论和实践结合起来，才能推动自己的架构演进。很多企业只看实践，不注重理论，所以经常把对标分析摆在前边，总指望拷贝成功经验，而不是创造成功经验，这是没法持续推动创新的。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
架构思维是帮助数字化转型落地的重要一步。这节课，我们主要学习了架构思维的四个关键点，现在我总结下。
|
|
|
|
|
|
* 全面：运用架构思维，首先要求你全面地看待企业，只有尽可能完整地看待企业，才有可能准确地进行分析。
|
|
|
* 结构：在尽可能掌握全貌的基础上，要结构化地分析事物的内部组成，确定好组成部分之间的关系，这样我们才能在逻辑上准确把握事物的结构。无论是要做软件设计，还是学习其他东西，这样做都是最科学的方法，结构化有助于降低事物的复杂性，更容易实现目标。
|
|
|
* 灵活：做很多事情都未必能一蹴而就，架构更是这样。在架构实施过程中，我们要接纳变化，因此架构思维要保持灵活而不要僵化、官僚化。
|
|
|
* 演进：面向长期来看，再好的架构都有一定的适用时间，早晚还得再调整，所以架构思维要注重演进，而且应该是有方向性的演进。
|
|
|
|
|
|
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
你能不能结合今天学习的架构思维，全面地分析一下你的工作，分析下你的工作涉及多少相关方，并且对照着企业的组织结构图，看看有没有平时遗漏的关联关系。
|
|
|
|
|
|
欢迎你畅所欲言，和我一起交流讨论。如果你觉得今天的内容对你有所帮助，也欢迎你分享给你的朋友或同事。
|
|
|
|