作者 ｜ 鈺湚
策劃 ｜ Tina
在與很多讀者朋友的溝通中，經常會遇到對方法論的各種思考和提問，這都是為了推動方法論的進步，今天跟大家聊下問的最多的一個，也許筆者自己說的也是誤解，大家共同討論吧。
1
方法論能簡化嗎？
這個問題估計是對企業架構方法論的各類提問中最“網紅”的選手，幾乎所有人在學習、談論企業架構的過程中都問過這件事，很多人也都嘗試過各種改良，但是，從方法論的角度來講，筆者覺得，能簡化的并不是它的過程，而是深度。
首先，打個不恰當的比方，要求簡化方法論，其實有點兒像跟大夫說，您能不看病直接給筆者開藥嗎？吃了藥不休息直接出去玩行嗎？都行，前邊那個是大夫不想干了，后邊那個是你自己膽子大。開玩笑地講，你的身體你清楚，你自己負責吧。
企業架構方法論也類似，想想大名鼎鼎的 TOGAF，自從 2002 年第八版以來，確實總體變化有限，而且更新頻率差不多“十年磨一劍”的感覺。第八版以前可是“一年磨一劍”，為啥能那么快？因為不完善唄，從 1995 年搞到 2002 年，總算比較完善了，所以速度也明顯降下來了。Open Group 的年度大會一直在開，每年都有很好的經驗出來分享，但是再更新方法論顯然不像以前那么容易了。
一些必要的基本環節確實省不下去，比如戰略設計，不知道戰略，就只能研究企業現狀做些改良，畢竟，誰都不知道企業要往什么方向走。也有人會用“摸著石頭過河”解釋企業方向變化快很難找，需要不斷地試，但這其實也些誤解成分，因為筆者總覺得這是“頭部企業”才會更多面對的問題，除了“頭部企業”還有多少企業是真的走在“無人區”的？不是都走在“生態圈”里嗎？很多企業面對的“無人區”可能是找不到合適人做、自己也缺乏人才培養方式的“無人區”，并非業務方向上的“無人區”。戰略之后的組織設計和業務設計也一樣，互聯網企業搞出個新花樣之后，馬上就是組織調整和業務調整，它是“快速思考”，但并非“不假思索”。數據設計更是，互聯網企業的數據功力還是很深厚的，從大數據到數據湖到數據中臺不都是從那邊過來的，數據管理方面花的功夫一點都不少。很多傳統企業數據功力也是很強的，畢竟，省了對數據的設計也就不用搞數字化了。上面這些東西很多都跟業務側關系緊密，也很難省，那之后的技術部分也就更難省了，要省的話，技術自己可能都過不了自己這關吧。
方法論如果不完整會咋樣？會誤解唄。一奶同胞的孿生兄弟，“數據中臺”就沒多少人真的會搞不懂他要干啥，畢竟，從數據倉庫，到大數據平臺、數據湖，再到強調“數據資產”和“數據服務”的中臺，這條有點兒像宗族譜系的內在邏輯還是讓大家不太犯暈的，這都是在數據的采集、存儲、計算、分析上做文章，就算把“湖倉一體”、“存算分離”之類的概念都堆上，也不會真的把誰繞進去，數據向來自己有一套的。上個世紀 70、80 年代沒網也紅的大咖們早就說過，看數據就知道系統是怎么跑的。
但是另一個兄弟就讓人“犯暈”了。“業務中臺”一開始就是這樣，沒指明好的構建過程（也可能只是沒說），直接跳到結果了，激動的讓一些 CIO 直接從技術側就操刀去搞企業架構。現在聽人家吼“拆中臺”，說到底這還是架構治理吧？架構治理都是基于企業自己需要的，不太關注別人的感受。最近看到技術瑣話的右軍老師轉了一篇談組件化的文章，標題上加了個“中臺之前”，挺有意思，不過組件化也確實是“中臺之前”，先有的組件化，后來才有的“中臺”說法；筆者以前的連載叫“中臺之上“，其實意思也差不多，畢竟，企業架構看的范圍最大，大家也都覺得它最“高階”。
方法論本身很難簡化，簡化太過就容易出問題，因為方法論并不是讓你去遵守的規矩，它反映的是人們認識事物的過程，有多少人能跳過必要的過程去認識事物？沒有過程又怎么組織大家去做事情？即便你不用企業架構方法論，也一樣要有個過程，那就得你自己去定義個過程了。不同的過程適用于不同的任務，敏捷有敏捷的用法，TOGAF 和瀑布模型也有他們的用法，無論哪個，都沒舍棄過全面、準確地認識事物，如果你自己想定義一個過程，那筆者建議你也不要忘記這一點，不然，“業務債”、“技術債”最終都會找上門來。
2
過程很難簡化，但速度有沒有可能提升呢？
門道兒有四個。
第一位的當然是對方法論的熟練掌握，但這個也許不是你想聽的，想想賣油翁的故事腦補下好了。
接著說第二個，深度。方法論沒變，但是如果做的不深，速度當然會快，因為不精準，省去了精準化的時間。企業架構本身就是在“畫地圖”，企業能力地圖。那么“畫地圖”的快慢在于什么呢？當然是精度，熟練的偵察員可以偵察一圈兒就很快繪出大致的地形圖，但是你搞個精準到厘米、連棵樹都不放過的地圖，那要的就是一個高精度的測繪結果了。不深也不意味著不好，因為深度是由時間和目標決定的，這是“以終為始”，如果只有一個月時間，那可以做到什么程度；如果只需要先達成“快照“，又可以做到什么程度。
如果企業自身資料齊全、進度協調順利，那做個“低精度”的企業架構未必須要很久，但是想要做用來給需求精準定位，支持業務和技術深度融合的企業架構，時間也自然會長。“低精度”的企業架構就像敏捷提出的 MVP，你需要繼續迭代，不然敏捷也沒法幫你把最初四個輪子的人力車過渡到漂亮的跑車，而且敏捷迭代到跑車的過程也未必真的很快。
第三個是借助預設架構。預設架構是對行業經驗的總結，是調整的基礎，行業內總有很多東西可以重復，借助預設架構也可以提升速度，畢竟大家更要關注的是針對差異化部分的設計，差異化的東西往往占比又沒那么大。但這個預設架構通常要借助外部力量獲得，并且企業要具備對預設架構調整能力。筆者去年初曾經寫過一篇關于行業級標準化的文章，那是關于這一點的另一個方向的討論。
第四個是優化執行方式。方法論都是博采眾長，敏捷的優勢是什么？Scrum 形容的很清楚，相關人第一時間集中在一起，對于大企業做企業架構，這種方式提升能力有限，因為坐到一起的人太多就不意味著決策會加快了，坐到一起的人太少，代表性又不足。預先建立定時拍板的機制才有可能保證速度，但未必保證質量，當然，如同前文所述，質量本身也需要靠迭代加持。中小企業采用這種方式應該會加快些，因為坐到一起的人可能沒那么多。這種方式最大的優點是信息傳遞是廣播式的，而不是容易衰減的逐級傳遞，可以節省的是傳遞和反復溝通的時間。
綜上，方法論簡化的難度其實不是來自于執行方式，不必總在環節上做文章，它是來自于人的認知過程，如果可以簡化人的認知過程，那方法論的簡化也就不難了。盡管簡化不容易，但是提升熟練度、控制設計深度、利用預設框架、優化執行方式還是能適當提升速度的。
作者簡介：
付曉巖，IBM 副合伙人，全球企業咨詢服務部大中華區金融核心銳變團隊業務發展和交付總監，機械工業出版社《銀行數字化轉型》和《企業級業務架構設計：方法論與實踐》作者。
