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