建築師

當人們使用「軟體架構師」這個術語時，他們使用建築施工的比喻來幫助人們了解架構師的角色。具有諷刺意味的是，在這樣做的過程中，他們誤解了建築架構師的實際角色。

軟體架構師被視為首席設計師，負責將專案中的所有內容彙整在一起。但這並非建築架構師所做的事。建築架構師專注於與想要這棟建築的客戶互動。他專注於對客戶來說重要的問題，例如建築物的佈局和外觀。但建築物不只這些。

特別是，建築師不負責建築物的結構完整性。那是結構工程師的角色，例如我的妻子辛蒂。建築師會請結構工程師讓他的建築物屹立不搖，通常到了這個時候，要做出能讓結構更有效率的變更已經太遲了。建築物也需要電氣和機械工程師，而這些工程師也會有與建築師最初角色相同的後果。

然而，儘管建築師是團隊中眾多專業人士之一，但他卻是負責與客戶進行所有對話的人。建築師從大學獲得概觀訓練，並從所有需要設計建築物的學科中汲取經驗，然而，他不可能在沒有這些學科的投入下代表所有學科發言。

由於專注於客戶互動，我認為軟體開發中最接近的等價物是使用者介面設計師。儘管我不信任這些比喻，但這個比喻確實有一個有用的推論：讓建築師負責工作的危險性。在最近的一個例子中，辛蒂被請去為一家飯店做結構工程。當她開始這項工作時，她意識到建築師的佈局需要一種特定的框架形式。稍微不同的佈局可以採用不同的框架方法，這可以將建造結構部分的成本降低 30%。建築師抵制了這個變更，因為他的建築設計已經獲得客戶簽名核准。

這件事的教訓是，如果我們讓一位建築師或使用者介面設計師負責客戶關係，該建築師必須與其他專業人員有效溝通。我發現，優秀的使用者介面人員所面臨的問題之一，就是他們沒有考慮不同使用者介面方案的成本。當這些成本是由更深入的技術問題所造成時，情況尤其如此。Dave Rice 喜歡指出，應用程式的並行性和鎖定策略無法與使用者介面體驗分開。然而，很少有使用者介面人員了解這些問題。只要他們能與了解這些問題的人有效合作，就不需要了解這些問題，這與典型的建築師不同。

關於建築師比喻的最後一個想法。Michael Pollan 的 A Place of My Own 持續的主題之一，就是建築師與木工之間的衝突。Pollan 描述了建築師如何整體上贏得負責建築設計的這場戰役。他遺憾地指出，他們通常是工作中報酬最低的技術工人。軟體架構師：小心你所許的願望！