譯者序
本文翻譯自 2019 年的一篇英文博客 Are You A Software Architect? 。
由於譯者水平有限，本文不免存在遺漏或錯誤之處。如有疑問，請查閱原文。
以下是譯文。
軟件開發（software development）和軟件架構（software architecture）之間有一條微妙的線。有人會說，這條線根本不存在，架構只是開發者設計 過程的簡單延伸（an extension of the design process）。另外一部分人則說，這是一條 巨大的鴻溝（a massive gaping chasm），只有少數出類拔萃的開發者才能跨越，這些開發 者都認為你必須不斷地向上抽象（always abstract your abstractions），而避免陷入令 人生厭的實現細節的泥沼。如果以務實的（pragmatic）眼光看，那這兩者之間必定存在某 個平衡點，但這接着也提出了問題：你如何從開發者變成架構師？
將軟件架構從軟件設計和開發中區分開來的關鍵因素包括：規模的上升、抽象層次的上升， 以及做出正確的設計決策帶來的影響的上升等等。軟件架構就在於能有一個全局視角（ holistic view）、能看到更大的圖，以理解軟件系統作為一個整體是如何工作的。 這些因素對區分軟件開發和軟件架構也許有幫助，但還是無法解釋一些人如何從開發轉到了 架構。進一步地，它無助於識別哪些人將會成為出色的架構師、如果你是 HR 你如何尋找這 些人，以及你是否是一個架構師。
經驗（Experience）
經驗是一個很好的衡量指標，但你應該看地更深（Experience is a good gauge but you need to look deeper）。
沒有人是在一夜之間或一次升職就成為軟件架構師的。架構師是一個角色（role），而非 級別（rank）。它是一個演進的過程，在這個過程中你會不斷增長承擔這個角色所需的經 驗與自信。
架構師身上有許多不同的品質，而他們過去的經驗通常是他們承擔這個角色所需能力的一種 很好的度量（gauge）。架構師的角色包括很多方面，因此你需要在更深層次地去看，理解他們 在不同方面展現出來的參與度、影響力、領導力和責任。
寬泛地說，大部分項目的軟件架構過程可以分成兩個階段：定義階段和交付階段（ the architecture is defined and then it’s delivered）。
軟件架構的定義（definition）
架構的定義過程似乎相當直接：確定需求，然后設計一個滿足這些需求的系統。但實際 中並沒有這樣簡單，隨着你的參與程度（how engaged you are）和你對待自己角色的認真程 度（how seriously you view your role）的不同，軟件架構的角色也有很大變化。如下圖 所示，角色的架構定義部分可以進一步分解為幾個子部分。
1 非功能（non-functional）需求的管理
軟件項目經常將注意力放在用戶的功能需求（features）上，而很少問用戶有什么 非功能需求（或系統性能）。有時需求方會告訴我們說“系統必須足夠快”，但這種 表述太主觀了。要滿足非功能需求，那這些需要必須是具體的、可測量的、可實現 的以及可測試的（specific，measurable，achievable and testable）。
大部分非功能需求本質上是技術性的，而且通常對軟件架構有很大影響。理解非功能需求 是架構師角色的核心能力之一，但是，試圖理解這些需求和質疑這些需求（是否 合理）還是有區別的。畢竟，你見過多少真正需要 7x24 小時運行的系統？
2 架構定義（architecture definition）
弄清了非功能需求后，下一步就要思考如何定義架構，解決需求方提出的問題。 我們可以說每個軟件系統都有架構，但是，不是每個軟件系統都有定義出來的架構（ defined architecture）。這才是關鍵點。
軟件定義過程需要思考如何在給定的限制下滿足提出的需求，進而解決問題。架構定義過 程是在項目的技術方面引入結構、規范、原則和領導力的過程。定義架構是你作為軟件架 構師的工作，但是，從頭設計一個軟件系統和擴展一個已有系統還是有很大差別的。
3 技術選擇（technology selection）
技術選擇通常是一個愉快的過程，但是，當考慮到成本、授權、供應商關系、技術策略 、兼容性、互操作性、支持、部署、升級策略、終端用戶環境等等問題時，挑戰也是很大的。 這些因素綜合起來，經常把一個簡單的選擇某些東西（例如一個功能豐富的客戶端）的任 務變成一個十足的噩夢。
接下來還有另一個問題：這些技術能否工作。
技術選擇是管理風險的過程（technology selection is all about managing risk）；在高復雜度或不確定性的地方減少風險，在可能帶來收益的地方允許引進風險。技 術決策需要考慮所有的因素，並需要評審和評估。這包括軟件項目的主要組成模塊，以及開 發過程會用到的庫和框架。如果你在定義架構，那你需要確信自己的技術選擇是正確的。同 樣地，為一個新系統評估技術和向現有系統添加技術是有很大區別的。
4 架構評估（architecture evaluation）
如果是你設計軟件，你需要問自己：我的架構能否工作？
對於我來說，如下的架構就算是工作的：滿足非功能需求；為其他部分的代碼提供了必要的 基礎（provides the necessary foundation for the rest of the code）；為解決底層的 業務問題提供了一個平台。
軟件最大的問題之一就是它的復雜和抽象，這使得很難從UML 圖或代碼去聯想出（visualize） 軟件的運行時特點。在軟件開發的過程中，我們會采用多種測試技術，以確保交付的系統在 上線之后能正常工作。為什么不對架構設計采用同樣的方式呢？如果你可以測試你的架構， 那你就可以證明它能工作。這項工作做的越早，就越可以減少項目失敗的風險，而不用簡單 的寄希望於它能正常工作。
5 架構合作（architecture collaboration）
與世隔絕的軟件系統很少見，大部分軟件系統都是需要人去理解它的。開發人員需要理解它 ，並按照架構實現它；需求方出於安全、數據庫、運維、支持等角度，也可能對它的實現感 興趣。要使軟件成功，你需要與這些需求方緊密合作，保證架構能夠和環境成功集成。不幸 的是，架構合作在開發組內都很少發生，更遑論外部的需求方了。
軟件架構的交付（delivery）
架構交付的部分也是類似，軟件架構的角色會隨着參與度（level of engagement）的不同 而不同。
1 把控更大的圖（ownership of the bigger picture）
要確保架構成功落地，必須得有人在軟件開發的整個生命周期內把握整張大圖、向大家描繪 前景（sells the vision）。如有必要，要跟隨項目一起演進，承擔將它成功交付的責任 。如果你定義了一個架構，那始終保持對架構的參與和演進是很有意義的，而不是將它交給 “實現團隊”（implementation team）。
2 領導力（leadership）
把控大圖是技術領導力的一部分，但軟件項目的交付期間，還有其它一些事情要做。包括： 向大家介紹責任（的重要性）、提供技術規范、做技術決策，以及具備做這種決策的權威。
作為架構師，你需要承擔技術領導力，以保證所有的事情都考慮到了，而且團隊走在正確的 道路上。軟件架構師的位置天然就是關於領導力的，這雖然聽起來顯而易見，但很多團隊中 架構師可能認為成功的交付並不是一個他們需要考慮的問題，因而並不具備所需的技術領導 力。
3 培訓團隊和指導下屬（coaching and mentoring）
培訓團隊和指導下屬是大部分軟件開發項目中容易被忽視的一項活動，導致的后果就是，一 些團隊成員並沒有得到他們應該得到的幫助。雖然技術領導力是關於對項目整體進行掌舵（ steering），但也有一些時候個人需要幫助。而且，培訓團隊和指導下屬提供了一種增強隊 員技能和提升他們職業生涯的方式。
這是架構師職責的一部分（this is something that should fall squarely within the remit of the software architect），而且很顯然，給你的團隊培訓架構和設計技能與 助他們解決代碼問題之間還是有明顯區別的。
4 質量保障（quality assurance）
如果交付工作做的太差的話，那即使有世界上最好的架構和最強的領導力，項目仍然會失敗。
質量保障是架構師角色中的很大一部分，但它遠非僅僅是 code review。例如，你需要有基准的性能指標，這意味着需要引入標准和工作慣例（standards and working practices）。從軟件開發的角度講，這包括：編碼標准、設計原則，以及源代碼分析工具 等等。我們可以肯定地說，大部分項目的質量保障做的並不夠，因此你需要辨別出哪些是重 要的，並優先保證這些部分被執行。對於我來說，一切對架構有重要影響的，或對業務非常 關鍵的，或復雜的，或高度可視化的東西都是重要的。你需要務實，意識到你無法保障所有 方面，但是做一部分總是比什么都不做好。
5 設計、開發和測試（design，development and testing）
軟件架構師角色的最后任務就是設計、開發和測試。作為一名工作在一線的架構師並不意味 着你必須參與每天的寫代碼任務，而是說你要持續的參與到項目中，積極主動地去幫助打造 和交付它。話已至此，那我們不禁要說，為什么每天寫代碼不應該成為架構師角色的一部分 呢？大部分架構師都是經驗豐富的程序員，因此保持這項技能的狀態是有意義的。除此之外 ，架構師還能經歷團隊成員都會經歷的痛苦，在此過程中可以幫助他們從開發的角度理解他 們設計出來的架構。一些公司明令禁止他們的架構師參與編碼工作，因為覺得他們的架構 師太寶貴了，不應該從事編碼這樣普通的工作。顯然，這種態度是錯誤的，如果你不讓他 們參與成功交付的過程，那又為什么讓他花精力設計架構呢？
當然，有些情況下讓架構師參與到寫代碼的程度確實不太可行。例如，一個大型項目通常意 味着需要考慮很大一張圖，因而不一定有時間參與到實現過程。但通常來說，寫代碼的 架構師比只是旁觀的架構師更加高效和快樂。
你是一名軟件架構師嗎？
不管將軟件開發和軟件架構之間的那條線看作是神話還是鴻溝，本文討論的內容都說明：軟 件架構師在這個角色上的經驗都隨着他們參與到項目的程度和他們對待自己角色的認真程度 而異。大部分開發者都不會周一早上醒來就宣稱自己是一名軟件架構師了。我自己當然不是 這樣，我成為架構師的過程是一個演進的過程。其實，一部分開發者可能已經在承擔部分軟 件架構師的角色了，雖然他們的 title 並沒有顯示這一點。
參與一個軟件系統的架構（contributing to the architecture of a software system） 和親自設計一個軟件的架構之間有很大不同。持續精進的技能、知識和跨多領域的經驗成 就了軟件架構師的角色。
跨越軟件工程師和軟件架構師的主動性在你自己，而首先要做的，就是了解你目前的經驗所 處的層次。