傳說中和現實中的雙模開發
“天下武功唯快不破”。電影《功夫》中火雲邪神這句臺詞可謂深得互聯網時代競爭的要旨，也不乏業內人士常常感嘆，一個產品的成功可能只是領先對手一週甚至兩三天的上市時間，產品創新速度、市場響應速度越來越被企業重視，但這兩個指標似乎都是大型企業，特別是傳統行業中大型企業的弱項。所以，不少人都致力於教大象跳舞，不斷有關於軟件過程、項目管理的概念應運而生。比如，Gartner在2014年提出了“雙模開發”，敏態加穩態，可預見性的業務使用傳統瀑布式開發，也就是穩態；探索性業務使用敏捷開發，也就是敏態。
2015年，Gartner對全球2800多位CIO進行了一次調研，結果顯示：38%的企業已經實施了雙模IT，26%的企業將在未來3年內實施雙模IT，只有13%的企業不會實施雙模IT，另外還有23%的企業則不確定。雖然沒有找到近期的數字，但是按照Gartner的說法“雙模開發”少說也佔據了半壁江山。我無意在這裏去質疑或者爭論這種統計，但是，顯然這些CIO們口中的敏捷開發未必是“敏捷宣言”所提到的敏捷開發，更多的還是應對特殊需求時，打破常規的“快速”開發，省略了通常的管理環節，組個小分隊，快速上線。這種劇情相信大家都經常遇到，市場着急、領導着急，大筆一揮，桌子一拍，下月上線。當然，對互聯網科技公司而言，可能就是下週上線。所以，大家都經常在穩態和敏態，也就是按部就班和大幹快上中做來回切換。
無論是符合敏捷開發定義的敏捷，還是特事特辦的敏捷，都意味着忽略既有流程中的一些環節，壓縮週期，快速實現目標，那麼，相比之下，經過業務架構設計、應用業務模型驅動的開發是不是顯得有些笨重，是否與敏態不兼容？是否在敏捷過程中應該被省去？要回答這些問題，我們還是從符合敏捷開發定義的敏捷和特事特辦的敏捷這兩個角度分別看看吧。
跟正宗的敏捷比比
說到正宗的敏捷開發，自然要說到“敏捷宣言”中提出的四個核心價值：個體和互動優於流程和工具、工作的軟件優於詳盡的文檔、客戶合作優於合同談判、響應變化優於遵循計劃。最直接的衝突莫過於第二項，敏捷開發素來以“不重視”文檔聞名，但其實敏捷開發並非不要文檔，而是不要那麼詳盡的文檔，過於詳盡的文檔會消耗大量不必要的精力，而用途又非常有限。對於開發人員而言，在軟件維護方面，高質量的需求文檔遠不如整潔的代碼加上詳盡的註釋會更讓人清楚軟件的結構，所以敏捷開發在這方面做了大膽的改變。但是，敏捷開發也還是要求有一份恰當的概括性文檔作爲項目的總體目標，而不是什麼都沒有就甩開膀子幹。如此，業務模型這套方法要想與敏捷開發融合起來，自身也必須具備一定的簡潔性。
從之前的介紹來看，首次企業級轉型肯定不適合這麼幹，而且企業級轉型需要深思熟慮，也不是應該去“敏捷”完成的事情。一旦轉型結束，具備了企業級架構之後，就是如何快速應用架構工具的問題了。我之前提到過，業務模型不應該承載太多的業務細節，要保持適當的抽象度，否則不利於對企業級的描述，至於細節要描述到什麼程度，不同的企業可能會有不同的要求，大的原則是，可以基本解釋清楚任務對數據實體的創建和變更，以便劃分任務以及組件的邊界。因此，模型本身具備快速應用的潛質。而且，模型本就是一張“作戰地圖”，通過模型也可以更快摸清項目範圍、涉及的組件和團隊以及潛在影響。敏捷並不是不顧一切的敏捷、更不是犧牲企業級架構一致性的敏捷，否則，敏捷項目就成了爲短期利益而有意忽視長期影響的盲目行爲。無論多着急，不看看地圖就衝向戰場，都是危險行爲。不過話說回來，模型分析和調整需要一定的過程，企業級這類龐大的模型體系也需要工具來支持，否則真的談不上快。
這似乎跟第一項核心價值也有衝突。其實不然，敏捷開發的速度來自於節省不必要的步驟和提高協作的效率，所以“個體和互動”才“優於流程和工具”，注重面對面直接交流，減少分歧。這就要求業務架構師必須參加敏捷項目，在項目中快速完成架構分析，把控項目引起的架構調整，而不能在項目之外等着按“流程”操作。敏捷開發團隊在要在業務架構師的直接參與下，在項目一開始就根據需求描述快速使用模型工具澄清項目範圍，列出對架構的改變事項，這其實也是對企業“統一語言”構建效果的檢驗。在項目期間，業務架構師則可以根據項目的具體情況完成對模型的詳細調整，實現並行作業。所以，應用業務架構和業務模型驅動的開發過程，可以轉變爲敏捷過程，併爲敏捷過程提供更好的分析依據。
跟“特事特辦”論論
再說到特事特辦的敏捷。這種敏捷其本質就是“臨時事項”，因事而立，事過則廢，這種方式其實對企業整體的架構管理帶有一定的破壞性，往往會直接要求一些違反“架構”整體安排的改動。而事後也經常無人對此負責，做了就做了，然後交給運維團隊去維護。有些真有長期價值的系統可能會持續使用，還好些，但是做了之後就再無人問津，半死不活地躺在哪裏的系統也屢見不鮮。
與上文提到的“真”敏捷不同，“真”敏捷是軟件過程的差異，並不意味着要去違反企業級，可以與企業級很好地融合；但是有些特事特辦的敏捷確實有不管不顧的意思，上線是唯一目標，手段可以不問。這種情況就很棘手了，因爲它超出了業務架構師的控制能力之外，是對企業文化的考驗，是對企業維護其企業級架構決心的考驗。
不過我們還是堅持下具體問題具體分析，別一概而論地扣大帽子。
首先，有些項目確實形勢逼人、速度第一，不上線毋寧死，這種要舉全局之力搏一隅的情況不支持也不行，但是業務架構師要切實參與到項目中，不但要給出當時的架構設計建議，也要儘快給出影響分析和事後的重構方案，如果成本允許，儘可能要在企業“搏命”之後，迴歸正途，避免架構遭到破壞，如果成本不允許，那這塊架構“飛地”也要標識清楚，儘可能讓它成爲以後架構設計可以利用的“輪子”而不是會踩的“坑”。
其次，對於不具備上述價值的“特事特辦”，架構師應該從業務架構的角度申明其立場，給出認真的分析意見，這是架構師自身的職業操守，而能否容忍架構師的意見則是企業文化的真實體現了。如同會議表決中的“保留意見”一樣，如果架構師真的反對項目的設計和實現方式，那企業就必須在項目文檔中保留其分析意見，這倒不是非要“立貼爲證”，而是在未來真的需要調整時，作爲參考意見使用，同時也供所有架構師進行檢驗和學習。這是對企業級的一種警醒，但並不是業務架構師工作中的常態，也不應是其工作追求的目標，架構師不是以參倒了宰相爲榮的“言官”，要有原則但也不要讓自己孤立，更不能變成言必稱企業級、處處拿大帽子壓人的“反對派”，架構師的宗旨是解決問題，而不是讓自己變成問題。雖然跑了點兒題，聊了下架構師的素養，但這是“特事特辦”牽出來的，足見這種事的麻煩，它超越了正常工作的範疇，帶有點兒其他色彩，需要架構師謹慎對待。
綜上，無論是否企業有意識地推行過“雙模開發”，大家也總是忙碌在一般流程和“特事特辦”之中；無論是否建立了敏捷開發體制，也總有項目必須要快上。大型企業中，企業級體制建立不易，打破卻很容易，不要爲了“快”而犧牲企業級。管理大企業開發就像指揮大兵團作戰，既有擔當主力、要穩紮穩打的方陣部隊，也有要處理特殊任務的遊騎兵，多兵種之間的有序協作是克敵制勝的關鍵，這就離不開有序的架構管理，通過業務架構方法、應用業務模型驅動開發本身與敏捷並不矛盾，敏捷可以是、也應該是一個有序架構體系下的敏捷，而不是“叫囂乎東西、隳突乎南北”的亂闖，好像有句格言，“捷徑是迷路的最快方法”。所以，一定要有效利用業務模型這個“作戰地圖”，培養好業務架構師這個“領航員”。
說到這裏，朋友們也不妨想一下，僅憑中臺模式就能很好地解決敏捷問題嗎？其實，這應該還是一個更大範圍的企業管理或者企業文化要去解決的問題，它並非一個單純的開發模式或者技術架構問題，之前我也提到過，企業級業務架構設計是希望實現企業整體的聯動、文化的轉型，而不是僅僅建立一套系統，實際上，阿里的中臺背後支撐其運作的也是阿里的企業文化。沒有敏捷起來的往往不單純是工具，而是人和人所在的環境。
相關文章：
中臺之上（一）：重視業務架構，不要讓“業務的歸業務、技術的歸技術”
中臺之上（二）：爲什麼業務架構存在 20 多年，技術人員還覺得它有點虛？
中臺之上（三）：戰略和組織結構，業務架構設計中不應被忽視的關鍵因素
中臺之上（四）：面對複雜的流程和數據，我們總結出了一個分析套路
中臺之上（五）：業務架構和中臺的難點，都是需要反覆錘鍊出標準模型
中臺之上（六）：如何爲一個商業銀行設計業務架構？
中臺之上（七）：不神祕但很麻煩的業務架構落地過程
中臺之上（八）：企業級業務架構的實現需要不斷溝通和調整
中臺之上（九）：如何基於企業級業務架構管理業務需求？
作者介紹：付曉巖，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計。公衆號：曉談巖說。