在与很多读者朋友的沟通中，经常会遇到对方法论的各种思考和提问，这都是为了推动方法论的进步，今天跟大家聊下问的最多的一个，也许笔者自己说的也是误解，大家共同讨论吧。
方法论能简化吗？
这个问题估计是对企业架构方法论的各类提问中最“网红”的选手，几乎所有人在学习、谈论企业架构的过程中都问过这件事，很多人也都尝试过各种改良，但是，从方法论的角度来讲，笔者觉得，能简化的并不是它的过程，而是深度。
首先，打个不恰当的比方，要求简化方法论，其实有点儿像跟大夫说，您能不看病直接给笔者开药吗？吃了药不休息直接出去玩行吗？都行，前边那个是大夫不想干了，后边那个是你自己胆子大。开玩笑地讲，你的身体你清楚，你自己负责吧。
企业架构方法论也类似，想想大名鼎鼎的 TOGAF，自从 2002 年第八版以来，确实总体变化有限，而且更新频率差不多“十年磨一剑”的感觉。第八版以前可是“一年磨一剑”，为啥能那么快？因为不完善呗，从 1995 年搞到 2002 年，总算比较完善了，所以速度也明显降下来了。Open Group 的年度大会一直在开，每年都有很好的经验出来分享，但是再更新方法论显然不像以前那么容易了。
一些必要的基本环节确实省不下去，比如战略设计，不知道战略，就只能研究企业现状做些改良，毕竟，谁都不知道企业要往什么方向走。也有人会用“摸着石头过河”解释企业方向变化快很难找，需要不断地试，但这其实也些误解成分，因为笔者总觉得这是“头部企业”才会更多面对的问题，除了“头部企业”还有多少企业是真的走在“无人区”的？不是都走在“生态圈”里吗？很多企业面对的“无人区”可能是找不到合适人做、自己也缺乏人才培养方式的“无人区”，并非业务方向上的“无人区”。战略之后的组织设计和业务设计也一样，互联网企业搞出个新花样之后，马上就是组织调整和业务调整，它是“快速思考”，但并非“不假思索”。数据设计更是，互联网企业的数据功力还是很深厚的，从大数据到数据湖到数据中台不都是从那边过来的，数据管理方面花的功夫一点都不少。很多传统企业数据功力也是很强的，毕竟，省了对数据的设计也就不用搞数字化了。上面这些东西很多都跟业务侧关系紧密，也很难省，那之后的技术部分也就更难省了，要省的话，技术自己可能都过不了自己这关吧。
方法论如果不完整会咋样？会误解呗。一奶同胞的孪生兄弟，“数据中台”就没多少人真的会搞不懂他要干啥，毕竟，从数据仓库，到大数据平台、数据湖，再到强调“数据资产”和“数据服务”的中台，这条有点儿像宗族谱系的内在逻辑还是让大家不太犯晕的，这都是在数据的采集、存储、计算、分析上做文章，就算把“湖仓一体”、“存算分离”之类的概念都堆上，也不会真的把谁绕进去，数据向来自己有一套的。上个世纪 70、80 年代没网也红的大咖们早就说过，看数据就知道系统是怎么跑的。
但是另一个兄弟就让人“犯晕”了。“业务中台”一开始就是这样，没指明好的构建过程（也可能只是没说），直接跳到结果了，激动的让一些 CIO 直接从技术侧就操刀去搞企业架构。现在听人家吼“拆中台”，说到底这还是架构治理吧？架构治理都是基于企业自己需要的，不太关注别人的感受。最近看到技术琐话的右军老师转了一篇谈组件化的文章，标题上加了个“中台之前”，挺有意思，不过组件化也确实是“中台之前”，先有的组件化，后来才有的“中台”说法；笔者以前的连载叫“中台之上“，其实意思也差不多，毕竟，企业架构看的范围最大，大家也都觉得它最“高阶”。
方法论本身很难简化，简化太过就容易出问题，因为方法论并不是让你去遵守的规矩，它反映的是人们认识事物的过程，有多少人能跳过必要的过程去认识事物？没有过程又怎么组织大家去做事情？即便你不用企业架构方法论，也一样要有个过程，那就得你自己去定义个过程了。不同的过程适用于不同的任务，敏捷有敏捷的用法，TOGAF 和瀑布模型也有他们的用法，无论哪个，都没舍弃过全面、准确地认识事物，如果你自己想定义一个过程，那笔者建议你也不要忘记这一点，不然，“业务债”、“技术债”最终都会找上门来。
过程很难简化，但速度有没有可能提升呢？
门道儿有四个。
第一位的当然是对方法论的熟练掌握，但这个也许不是你想听的，想想卖油翁的故事脑补下好了。
接着说第二个，深度。方法论没变，但是如果做的不深，速度当然会快，因为不精准，省去了精准化的时间。企业架构本身就是在“画地图”，企业能力地图。那么“画地图”的快慢在于什么呢？当然是精度，熟练的侦察员可以侦察一圈儿就很快绘出大致的地形图，但是你搞个精准到厘米、连棵树都不放过的地图，那要的就是一个高精度的测绘结果了。不深也不意味着不好，因为深度是由时间和目标决定的，这是“以终为始”，如果只有一个月时间，那可以做到什么程度；如果只需要先达成“快照“，又可以做到什么程度。
如果企业自身资料齐全、进度协调顺利，那做个“低精度”的企业架构未必须要很久，但是想要做用来给需求精准定位，支持业务和技术深度融合的企业架构，时间也自然会长。“低精度”的企业架构就像敏捷提出的 MVP，你需要继续迭代，不然敏捷也没法帮你把最初四个轮子的人力车过渡到漂亮的跑车，而且敏捷迭代到跑车的过程也未必真的很快。
第三个是借助预设架构。预设架构是对行业经验的总结，是调整的基础，行业内总有很多东西可以重复，借助预设架构也可以提升速度，毕竟大家更要关注的是针对差异化部分的设计，差异化的东西往往占比又没那么大。但这个预设架构通常要借助外部力量获得，并且企业要具备对预设架构调整能力。笔者去年初曾经写过一篇关于行业级标准化的文章，那是关于这一点的另一个方向的讨论。
第四个是优化执行方式。方法论都是博采众长，敏捷的优势是什么？Scrum 形容的很清楚，相关人第一时间集中在一起，对于大企业做企业架构，这种方式提升能力有限，因为坐到一起的人太多就不意味着决策会加快了，坐到一起的人太少，代表性又不足。预先建立定时拍板的机制才有可能保证速度，但未必保证质量，当然，如同前文所述，质量本身也需要靠迭代加持。中小企业采用这种方式应该会加快些，因为坐到一起的人可能没那么多。这种方式最大的优点是信息传递是广播式的，而不是容易衰减的逐级传递，可以节省的是传递和反复沟通的时间。
综上，方法论简化的难度其实不是来自于执行方式，不必总在环节上做文章，它是来自于人的认知过程，如果可以简化人的认知过程，那方法论的简化也就不难了。尽管简化不容易，但是提升熟练度、控制设计深度、利用预设框架、优化执行方式还是能适当提升速度的。
