當組織規模達到一定量級，就會不可避免的陷入到技術選型困境中：新技術是否值得被采用、如何判斷可行性、替換成本有多高、隱藏陷阱有哪些等等。本文將從技術管理的角度出發，介紹ThoughtWorks技術雷達何以成為技術管理者的案頭手冊。
大型企業通常會按不同的部門、區域、駐地和其他獨出心裁的維度進行劃分，以方便組織業務。這些部門區劃往往源自兼并和其他重組，它們帶來的遺留問題是：技術、架構和許多其他重要技術決策信息分散無序。而企業架構師必須直面這種技術多樣性，并制定出一致性戰略。
為了使戰略行之有效，企業架構師會審視組織中的各種方案，確定哪種方案最為有效，從而鼓勵團隊采用最佳方案。但是，在決策的“受益人”心目中，企業架構師的角色往往帶有負面色彩，這是他們對治理模式的選擇所致。不過，開明的組織最近已開始重新思考治理的作用。
三種治理模式
企業架構師的職責是圍繞技術選擇進行治理，很遺憾，技術選擇卻是一個模棱兩可的術語。目前，有三種現行的治理模式。
控制式治理
遺憾的是，許多組織采用的都是這種控制式治理。在這種傳統的命令與控制治理模式中，企業架構師通過重量級治理模式將其選擇強加給團隊，例如：
“所有新的 Web 開發都應使用 Angular 的最新版本。”
這種情況還算是溫和的。我曾見識過一個大型組織中對每個項目強制執行一個真正的拜占庭式軟件棧（包括應用程序服務器、發布框架和工業級數據庫），直到他們發現一切都被過度設計了方才醒悟。采用這種治理方法的動機通常來自于企業對軟件的更深層次的態度：軟件是戰略方面的還是運營方面的？如果答案是運營，則企業架構師就能利用治理模式來加強一致性，從而節約運營成本。例如，如果人人都在 Java 或 ReactJS 上實現標準化，那么開發人員就能在不同項目中相互替代，培訓和工具就會簡化，而成本通常也會降低。
但是，命令與控制治理模式的缺點在于對構建軟件的態度千篇一律。
針對不同問題使用相同的軟件棧不可避免地會導致需求和價值的不匹配。
我曾在一家超大型企業工作，這家企業要求由企業架構團隊決定強制執行的標準技術棧，包括 Oracle 數據庫、發布框架、若干 XML 庫，重量級 J2EE 分布式對象模式以及許多其他復雜的移動部件。當時，我的任務是幫助他們的開發人員調試系統，解決導致應用程序服務器崩潰的問題。
在對話過程中，一名開發人員承認，有7個用戶不太喜歡他們的系統。“7個用戶！！！”我驚叫。“好吧，最終將多達 25 個，”他羞怯地承認。雪上加霜的是，這個應用程序僅向用戶詢問若干形式的信息，還會發布一個項目代碼，它們可能是幾個高中生用 PHP 語言花幾個小時編的，而這個超大型企業為此已經花費了幾十萬美元…而且系統還無法正常工作。“節省成本式治理”模式一個普遍存在的問題是過度設計。
無意中的過度設計是控制式治理模式一個固有的副作用。假設企業架構師的任務是為企業標準確定一個關系數據庫。為了進行盡職調查，企業架構師應該拜訪各個團隊，確定最具挑戰性的數據問題，然后再選擇一個他們適用的關系數據庫。
企業架構師還必須找出報告最具挑戰性的團隊，選擇能夠滿足其需求的報告解決方案。整合架構、消息傳遞、NoSQL 數據庫以及企業中的所有其他技術也是如此。但是，其副作用是，每個團隊都必須面對針對不同類別的最復雜的解決方案。例如，對于關系數據庫，能解決最具挑戰性的問題的工具會給具有普通數據存儲和檢索需求（這種情況可能更常見）的團隊帶來不必要的復雜性。通過強制各團隊對不同類別的單個工具進行標準化，企業架構師就會將每個類別中的最大復雜性強加給各團隊。
雖然節省成本通常是節省成本式治理模式的主要目標，但遺憾又有諷刺意味的是，由于過度設計了簡單的問題，開發和維護成本卻成倍增長。
許多現代架構，包括許多微服務項目，都采用另一種模式，指導式治理。
指導式治理
治理的另一個定義對現代軟件項目有更好的闡釋：
作為先例或決策原則
我們看到，更多的開明的企業架構師選擇指導式治理，而不會采用傳統的治理模式，對每個團隊強加相同的技術棧。這種模式通常用于許多微服務架構中，其中每個服務都可以利用唯一的技術棧。這些項目的架構師完全專注于特定服務可能需要的功能，而不是遵循某種標準。例如，與系統的事務部分相比，應用程序的管理部分可能需要適度的擴展功能。
但是，即使是完全不同的技術棧也需要圍繞具體操作問題（例如部署、監控、日志記錄以及許多其他合適的耦合點）進行通用化。為此，微服務社區已經普及了服務模板和服務網格，以處理運行軟件所引起的操作耦合。
微服務模式和命令與控制的整合模式相反。盡管它在隔離架構問題方面具有優勢，但也要直面傳統方法。許多公司都將金發姑娘治理采取折衷的態度。
金發姑娘式治理
在《演進式架構》一書中，我們以童話故事《金發姑娘和三只熊》里的金發姑娘命名一種治理模式，因為遵循這種模式的架構師力求與童話故事金發姑娘達到相同的結果：找到“恰當”的指導與控制水平。
每個開發團隊都擁有唯一的技術棧會產生大量運營成本，并且也幾乎不可能讓團隊成員的技能、運營支持成為復用資產，還會產生一系列其他棘手問題。因此，許多大型企業的企業架構師已采用更細致的方法，在先前的“一招鮮”模式和“荒野西部”微服務模式之間進行細分。
在金發姑娘原則治理模式中，企業架構師選擇若干合適的技術棧，評估哪種棧最適合新項目開發。例如，某公司可能會確定適用于大中小不同項目的技術棧，相應地為項目提供指導。這就能使團隊和技術與項目之間實現一些互換，同時還所能設法避免強加過度設計。
當然，金發姑娘原則治理模式并不能阻止意志堅定的企業架構師繼續施加過于嚴格的控制。但是，它有望鼓勵他們在從更多本地項目層面上考慮技術的價值，抑制在企業層面上過度要求同質化的沖動。
無論企業架構師使用哪種治理模式，大多數公司都面臨著如何傳播其調查結果的挑戰。 這就是 ThoughtWorks 技術雷達的用武之地。
廣播式治理
公司規模與溝通詳細信息的難度之間存在關聯。大型公司的企業架構師面臨的困難是：如何使開發人員知道采用什么技術有效，什么未經試用以及應該避免什么。
技術雷達提供了一種在公司內廣播這種信息的強大機制。在使用 ThoughtWorks 構建自己的技術雷達工具時，它將創建一個網站，每個條目都是一個超鏈接，這樣就為獲取該技術的更多背景信息提供了方便。我們已經看到，應用技術雷達構建技術圖譜的團隊已經在這些鏈接背后建立了豐富的資源。
例如，假設一家公司正在試驗使用一種 Bob 的 Web 框架。企業架構師需要驗證此框架是否能處理他們所需的各種常見應用程序，是否支持操作限制，是否與現有技術選擇（例如安全性）以及其他許多注意事項完美配合。他們讓三個團隊使用新框架來構建應用程序，并在其治理雷達上的相關提示下記錄其進度。當開發人員詢問 Bob 的 Web 框架時，他們可以指向正在進行的實驗，并通過雷達廣播初步結果。
在ThoughtWorks官方的技術雷達設計中，我們將技術條目放在不同的環中，以表示團隊對這一技術的采納程度。企業架構師可以輕松地將其重新用于表示治理層級。例如，我們有幾個客戶用現有類別表示以下內容，構建了治理雷達：
采納：經證明可在企業中使用、并得到良好支持的技術
試驗：我們正在一個或多個項目上試用的、有前途的工具或技術。我們幾個客戶在實驗中納入了項目的鏈接，方便讀者深入探究更多細節。
評估：企業架構師正在評估的、可能試用的新工具或新技術，其中包括正在積極研究的對象
暫緩：就像在 ThoughtWorks 雷達中一樣，暫緩并不意味著“立即放棄”，而是“啟動新項目時不要使用”。“暫緩”表示企業已棄用此工具或技術，并且提供了更好的替代方法
我們已經看到，企業架構師使用“試驗”環為各團隊的新試驗設置 WIP（在制品）限制。這樣，他們就能在團隊層面進行有序的試驗，同時對其他團隊也有清晰的了解，并為“采納”環獲得成功的試驗。
使用雷達，企業架構師和其他選擇該技術的人員就能向他人展示他們當前的想法。在這種情況下，創建自己的技術雷達并不在于向外界展示自己的技術圖譜，而只是作為內部趨勢的動態文檔。使用這種方法的客戶會定期重發布其治理雷達，以確保自己的團隊獲得最新信息。
盡管在長久以來的工作中，企業架構師一直在進行這種評估，但受其決策影響的開發人員最終卻發現，傳統的流程并不透明。通過使用雷達創建簡便的廣播機制，企業架構師就能提供透明度，享受到隨之而來的好處。例如，具備某種技術經驗的開發人員可以將其經驗（無論好壞）插入對話中。使用雷達突出顯示試驗，可以將架構師以前的象牙塔練習變成任何有關各方之間的社交協作，從而改善意見的多樣性。我們鼓勵企業架構師將雷達作為治理手段，促進其決策過程的討論，增強透明度。
原創：Neal Ford
第三十四屆CIO班招生
北達軟EXIN網絡空間與IT安全基礎認證培訓
北達軟EXIN DevOps Professional認證培訓
責編：yangjun
免責聲明：本網站（http://www.wuxizhouchengzuo.com.cn/）內容主要來自原創、合作媒體供稿和第三方投稿，凡在本網站出現的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
本網站刊載的所有內容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權歸原作者所有。任何單位或個人認為本網站中的內容可能涉嫌侵犯其知識產權或存在不實內容時，請及時通知本站，予以刪除。
搶沙發
