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