怎么学架构方法论会好点儿

今天是二月二，俗称“龙抬头”，原本在忙其他事情，没有打算写文章，但是这两天技术琐话、程序员大咖两个公众号陆续重发了一些我以前写的文章，自己看了后也略有些感慨，少写些文字，想点儿东西，也许后边会再发展下，先记下来。

最近的交流中，也不断反思该如何理解方法论，先后写了《2021年，中台的瓜你还吃吗？》、《企业架构方法论可以简化吗？》两篇文章，希望跟大家共同探讨对企业架构的理解和对方法论的学习，反思中，发现自己忽然越来越理解TOGAF中为什么没有直接的案例。

其实对于方法论的学习，尽管我主张“知行合一”，但是，这个“知行合一”其实指的是在自己企业中的“知行合一”，也就是在自己企业中的方法论研究指导自己企业的实践，实践再反哺和推动方法论前进，做到自家的“知行合一”，而不是成天解释别人家的“知行合一”。

这就要想到另一件事，在一个企业开始实施方法论之前，在学习阶段要偏重思维层面而非实例层面，方法论在学习期间应当“起于思维，止于思维”，在自己对方法论的逻辑理解的较为融通之前，不要急着看实践案例，因为没有一个企业是一五一十照着某个方法论做的，都有自己的改动，对自己环境的适配，所以，当你急着从实例出发时，学到的其实是“经验”，而非“方法”本身，这个“经验”对你而言，可能适配，那你是幸运的；也可能不适配，会导致你对方法的误解。

很多时候对方法论的误解其实来自于对方法论的执行问题，而不是方法论本身，比如，经常认为TOGAF这种过程比较偏向严格管理，不欢迎变更，但实际上，这可能是为了能够执行下去而产生的“误解”，就像对瀑布过程的各种批评一样，可能是把执行的缺陷推给方法。TOGAF自己认为“需求管理圆圈表示的并非一组静态需求，而是一个动态流程”，“架构在本质上是处理不确定性和变革的一项活动”，所以架构从来不是以找确定不变的东西为目标，架构的稳定经常是一种执行上的误解，架构也不是以不变应万变，是通过结构，知道如何吸收变化。

方法论是有点儿形而上学，但这是为了提炼通用经验而需要的折中，因此，学习时如果再代入特定的经验，那就把本来做出的折中又给特化的还原了，要带入，我也建议你用自家企业的情况带入，再去判断从实践层面按照方法论的要求做不做得通，对不对，再跟实践过的人去讨论经验，比较应该做的调整，而不是跟着别人的经验直接调整。

方法论是个种子，最终要在你家的土地上生根发芽，开枝散叶，修剪，也是要按照你自己的需要修剪。