建築師電梯 — 造訪上層樓

建築師電梯

為了說明架構師除了指導軟體開發人員之外還有更多事情要做，我使用了「架構師電梯」的比喻。這部電梯從公司的引擎室一直延伸到高層管理人員定義策略的頂樓。儘管數位公司利用技術來解鎖新的商機，但傳統組織通常仍將其 IT 視為一個單純的成本因素，遠離商業策略：無數層管理階層將上層與下層分開。資訊是透過逐層爬樓梯傳遞的，導致了眾所周知的「傳話遊戲」效應：當訊息經過許多站時，不僅需要時間，而且其含義也可能完全改變。

對於架構師和開發人員來說，這說明了兩個主要問題：首先，由於上層人員看不到投資的必要性，因此可能難以獲得創新專案的支持或資金。但即使推出新技術，現有的流程和政策也可能阻止它們實現預期的效益。在兩種情況下，架構師都必須拜訪上層以解除或觸發組織變革。

由於組織不太可能在短期內縮減其管理層級——太多週末住宅和孩子的教育岌岌可危——因此架構師需要在各樓層之間快速移動，以將業務策略與 IT 架構和技術實作保持一致。從引擎室到頂樓的電梯之旅突顯了現代架構師在每一層樓等待著什麼！

雲端就緒應用程式需要執行時期架構

鑑於現代應用程式例行地對架構提出要求，引擎室仍需要架構師：我們過去認為分散式系統是不尋常且相當複雜的事物，若能避免最好。如今，建立非分散式的應用程式已屬罕見：幾乎所有有意義的應用程式都會公開服務 API、呼叫其他服務，並在雲端中以全球分散的方式執行。除此之外，它們預期會在零停機時間下更新、橫向擴充，並能抵抗硬體和軟體故障，加上Chaos Monkey為了好玩而終止其流程。要達成所有這些目標，需要相當好的架構！

幾年前，看來大多數主要的架構決策已在應用程式架構中做出，例如 Java EE 或 Spring，讓開發人員專注於編碼功能和使用者介面。雖然這個承諾在設計階段的決策上部分成真，例如是否使用 MVC，但現代應用程式通常會帶來與其執行時間相關的重大架構需求。這種趨勢也反映在開源社群中：不論是 Docker、Kubernetes、Mesos、CloudFoundry、Prometheus、Hystrix、Vizceral 或 Kibana，專案名稱不僅變得更難拼寫，也越來越注重應用程式的執行時間管理和監控。

因此，現代架構師必須精通執行時間架構考量，包括部署和組態自動化、可擴充性、監控等。他們可能會用部署圖取代類別圖！

自動化軟體製造以縮短價值實現時間

長期以來，人們一直認為軟體開發產業化將降低專案成本和風險。這項努力最初大部分都集中在軟體的設計層面，例如如何撰寫穩固的要求，以及像組裝線一樣管理專案團隊。這大部分都只能算是小有成就。傑克·李維斯早在四分之一世紀前就已得出結論，編碼實際上是設計工作，而非生產工作。因此，嘗試產業化設計（本質上是一項創意工作）是一項有疑問的努力。應該產業化的是軟體生產：組裝和分發軟體成品以形成一個執行中的系統。

製造業在半個世紀前開始大幅自動化生產，讓大多數工廠幾乎沒有人。具有諷刺意味的是，許多軟體專案的最終目的可能是自動化繁瑣的手動工作，但仍以「工匠風格」提供軟體：手動複製檔案、在這裡套用小修補程式、在那裡變更另一個設定檔，以及僅為美觀而更新一些權限。喔，還有忘記複製的另一個檔案。就像鞋匠的孩子赤腳一樣，軟體交付流程諷刺地缺乏軟體帶給企業的那種自動化。

幸運的是，持續整合 (CI) 和持續交付 (CD) 已透過雲端運算和軟體定義基礎架構支援的不間斷自動化，大幅改善軟體交付的產業化。它們讓伺服器可以視為一次性項目：如果伺服器有任何問題，您不會修復它，而是會實例化一個新的伺服器（請參閱 牲畜與寵物類比）。自動化軟體交付的主要驅動力並非經濟，即節省執行部署任務的人員。相反地，這是對速度和可重複性的需求 - 人類不夠快速且不可靠。

因此，現代架構師不應只關注設計，還應關注軟體的「製造」。改善機房的這個面向對頂層套房有重大影響：快速且可重複的交付縮短軟體提供商業價值所需的時間。這是參觀上層樓的絕佳理由。

將前期決策降到最低

許多建築師自認，而且也預期自己會是做出「難以逆轉」決策的人。這種建築師的原型可能會讓人想起電影「駭客任務」中的白髮紳士：一位非常有經驗、無所不知的人，做出所有決策。這種願景有一個主要的缺點：駭客任務的建築師是一個電腦程式，而不是人類。

在專案開始時做出關鍵決策實際上是最糟糕的時機，因為這是所知最少的時候。隨著專案進展，會獲得更多資訊，可以做出更明智且更好的決策。因此，與其將所有關鍵決策託付給一個人，可以透過將不可逆的決策數量減至最少來降低專案風險。例如，透過選擇靈活的設計或使用模組化來將後續變更的範圍局部化，可以達成此目的。

通常，做出預先決策的慾望是由既有的結構和流程驅動，而不是技術需求。例如，團隊被迫在開發甚至開始之前就做出產品決策，以滿足耗時的預算核准流程。因此，也可以透過抵禦那些通常抱持善意，但要求預先決策的官僚體系來避免或減少不可逆的決策。

供應商也傾向於推動早期工具決策，承諾管理層將獲得驚人的成果，包括減少或消除對昂貴程式設計師的需求，只要選擇他們的工具即可。你不能責怪他們這樣做——這是他們的工作。但你需要平衡——一輛更快的車並不能造就更好的駕駛員。更糟糕的是，在某些情況下，汽車甚至可能不會更快，只是更貴，或者由於太難操縱而最終陷入困境。

這些範例強調，若要提高 IT 引擎室的效率，你可能必須改變組織運作的方式。這就是為什麼架構師必須搭乘電梯到樓上。

銷售架構選項

向高階主管解釋什麼是架構，可能是一項挑戰。在最近的高階主管會議中，一位架構師在這個主題上兜兜轉轉幾分鐘，導致與會者眼神呆滯、搔頭。我決定插話：「架構就是銷售選擇權。」這句話立即引起了高階主管的注意：金融選擇權賦予選擇權所有者權利，可以在未來以已知條件購買或出售金融工具：選擇權賦予權利，但並非義務，可以在某個未來日期以設定價格（例如 100 美元）購買股票。當那天到來時，很容易決定是否行使選擇權：如果股價高於 100 美元，我將使用我的選擇權以 100 美元購買並賺錢。如果不是，我就讓選擇權失效。

選擇權是一種將決策延後到稍後時間的方法，同時鎖定關鍵參數，例如價格。金融業非常清楚這個選擇權有價值，因此有價格。將架構呈現為銷售選擇權對於精通財務術語的高階主管來說立即有意義：你投資於架構，以便你可以在稍後以已知成本改變主意。例如，如果你的應用程式具有可擴充性和自動部署功能，則不必預先承諾購買硬體，而可以在需要時在未來新增硬體。能夠這樣做會產生具體的節省，並證明對架構的投資是合理的。

就像財務選擇權一樣，架構選擇權也允許我們對賭注進行避險：我們預期某個結果，但如果結果未實現，我們希望限制下行風險，降低風險情境的影響。

讓架構適於目的

我們通常希望架構師提供「良好」的架構。問題在於架構很少是好或壞的，它不是適合目的，就是不適合目的。目的通常取決於系統運作的環境，而不是特定的使用者需求。因此，架構師的工作是在更廣泛的環境中考量架構選擇權，這可能涉及商業和法律協議、技能可用性或已安裝的基礎等不同的因素。

要找出適當的環境，架構師必須拜訪組織的許多樓層。特別是需要廣泛協調的決策，通常是由管理團隊做出，這些團隊與軟體交付團隊相距甚遠，根據財務、流程合規或簡報投影片做出決策。架構師的工作包括建立透明度，說明後果，並讓所有層級參與架構權衡。Luke Hohmann 的 超越軟體架構 很好的說明了架構考量的廣度。

即使經過所有考量，做出架構決策仍然很困難，而且有一定程度的風險會出錯。因此，最好讓必須承擔後果的人做出決策。這個想法將我們帶到下一層樓...

透過回饋迴路驗證決策

一個著名的架構部門反模式是「象牙塔」：架構師坐在頂樓，定義開發人員應如何設計和建置軟體，而他們自己卻不開發任何軟體。這種設置有一個主要的缺點：它無法向架構師提供有關其決策的有效性或成本的回饋。更糟的是：有些架構師很享受不必處理這些後果。

大多數複雜系統只能透過回饋迴路運作：無論是你的手臂伸展直到你的手指感受到鍵盤、你的暖氣恆溫器在室溫達到後關閉暖氣，或駕駛持續調整方向盤以維持汽車在車道上。在 IT 中，回饋迴路適用於專案導向和架構：一旦團隊速度已知，預測專案成本和時程便容易許多，並允許在過程中進行必要的調整。架構師應找出「可重複使用的」API 是否真正促進重複使用、常見架構是否加速開發，或監控架構是否減少非預期的停機時間。了解回饋需要找出明確的指標和目標，這本身就是一個有用的練習。

架構師取得回饋的絕佳方式是直接參與專案交付並對其負責。回饋週期在短且立即時最有效，因此讓開發團隊在既定的通用原則或已發布的 IT 策略範圍內做出架構決策會很有吸引力。

與技術演進並行設計組織

許多最近的軟體創新，例如 DevOps、雲端或大數據，只有在組織結構與技術一同演進時，才能發揮其全部價值。如果你必須經過長達 3 個月的紙本核准流程才能獲准執行，那麼即使你的全自動化工具鏈可以在幾秒鐘內部署軟體，對你來說也沒有幫助。因此，在加速軟體交付時，不可避免地不只關注技術面。現代架構師還必須考慮組織的設定，而這必須在較高層級執行。

例如，許多 IT 組織將「變更」（開發軟體）與「執行」（操作軟體）分開。這在數位世界中已不再有太大意義，因為來自執行軟體的回饋是公司在所謂的建構-衡量-學習週期中改良其產品的主要機制。

有趣的是，組織系統的行為通常受到與影響技術系統相同力量的影響。例如，分散式系統中最大的吞吐量殺手之一是同步點，這也是我們偏好非同步訊息傳遞的原因之一。同步點的組織等價物是會議，它也以降低吞吐量而聞名！

分層是另一個眾所周知的概念，它有助於管理複雜性並獲得靈活性，但由於層與層之間的許多轉換，也可能增加延遲。這種邏輯適用於技術，也適用於組織系統結構：分層組織能將層外包出去，因為相依性定義得很清楚。然而，每個層面都會帶來轉換工作，無論是在「設計時間」——合約和服務等級協議必須協商——還是「執行時間」——冗長的規格文件必須撰寫，並舉行許多「協調會議」。

許多架構師害怕觸碰組織層面，因為它們充滿了「人事」和政治。但複雜系統行為的相似性，讓架構師具備了在高層參與並移除組織系統瓶頸的條件。

在正確的「樓層」移除阻礙

許多開發人員、架構師和專案經理可能會感到沮喪，因為他們從組織獲得的支援不足：很難為創新、重要專案或重構等關鍵任務取得人力或資金。這種阻力通常是因為組織與開發團隊抱持不同的信念系統。例如，許多傳統公司重視可預測性甚於速度。因此，他們實施了一連串冗長的「檢查點」和「品質閘門」，導致繁瑣且耗時的流程。在這樣的組織中，很難實施敏捷或 DevOps 工作方式。

要改變這種組織的行為，就必須改變他們的信念。否則，你將持續撞上文化之牆。例如，著迷於可預測性的組織通常專注於透過規模經濟和一致性來最佳化現有流程。為了在數位世界中競爭，他們需要了解速度經濟，亦即透過收割新的市場機會來產生價值。這種態度上的轉變必須發生在接近頂層的高層——你必須搭乘電梯到正確的樓層才能取得進展。

報告線可以是 IT 組織信念系統的有用指標。例如，如果 CIO 向 CFO（首席財務官）報告，IT 可能只被視為成本因素，而不是創新者和市場機會的推手。在這樣的組織中，任何嘗試銷售技術創新的行為，都會在管理階層的腦海中迅速轉化為「我對客戶端伺服器、網路等聽過同樣的話。這些東西只會花掉我的錢。」改變頂層對這些項目的看法，是啟動成功的 IT 創新必要的先決條件。

ArchOps：建立垂直架構團隊

從機房搭乘電梯到頂層的短暫旅程，突顯了建築師在樓層間移動的必要性。這個見解也應該反映在架構團隊的設置中。通常，一個中央架構團隊由「高級」建築師組成，他們的位置接近頂層，但與技術創新和專案交付脫節。

由於單一建築師不太可能涵蓋所有樓層，因此建立一個「垂直」架構團隊是有道理的，這個團隊由來自許多不同層級的建築師組成：企業架構師、策略架構師、解決方案架構師和技術專家。這就像在現有的只有樓梯的摩天大樓上加裝電梯：突然間，事情開始移動得更快。

管理這樣的團隊並不容易，但它確保單一團隊可以涵蓋組織的所有樓層，而且建築師有必要的回饋迴路。它也讓建築師團隊具備執行能力，如果組織缺乏技能或設置來執行的話。

持續搭乘電梯

我將我在轉型大型 IT 組織的經驗彙編成一本書，書名很俏皮，叫做《一位建築師對 IT 轉型知道的 37 件事》。這本書透過 37 個有趣但發人深省的軼事，探討參與上層樓層所需的技能。這本書以 Leanpub 上無 DRM 的電子書 或 亞馬遜上的印刷書 提供。

由於上層樓層發生了這麼多事情，一些建築師可能會想，他們是否應該成為組織設計師，而不是技術建築師。不過，那會連同洗澡水把孩子也倒掉。設計和影響組織取決於對軟體交付和技術創新的透徹了解。技術敏銳度和組織技能的結合，讓現代建築師變得有價值，並讓 IT 轉型成功。

你可能看過建築師搭乘電梯上樓，只是為了享受頂層的美景，以致於他們從來沒有再下來過。在技術快速演進的世界中，這樣的態度保證會讓自己的技術技能很快變得無關緊要。因此，重點是要持續搭乘電梯上下樓——這是讓頂層和機房保持連接的唯一方法。

在相反的情況下，許多建築師覺得上層樓層對他們來說是無法接近的。執行長或副總裁真的會想和他們談話嗎？令人驚訝的是，他們通常會。許多頂層樓層的居民覺得與組織中的現實脫節，而且對技術的快速進步感到困惑。因此，如果有人向他們伸出援手，說他們的語言，但腳也穩穩地踏在機房裡，他們會很感激。

所以，繼續搭乘建築師電梯，更常拜訪上層樓層，別忘了再下來喔！